The Interplay Between Mathematical and Computational Thinking in Primary School Students’ Mathematical Problem-Solving Within a Programming Environment

Preparing Problems

While some problems naturally lend themselves to computational solutions, more often, they must be reframed so that existing computational tools – such as physical devices or software packages – can be utilised. Strategies for doing this include decomposing problems into sub-problems, reframing new problems into known problems for which computational tools already exist and simplifying complex problems to make mapping the problem features onto computational solutions more accessible. In a mathematical problem-solving environment, these strategies may become useful as early as in primary school education.

Programming

Programming entails the ability to encode instructions in such a way that a computer can execute them. On the one hand, it serves as a tool to solve mathematical problems, and on the other hand, it deepens mathematical disciplinary knowledge whilst improving one’s CT skills (Pei et al., 2018). In other words, during K–6 programming activities, children learn concepts that can be useful for both their mathematics learning and developing their CT. Rich et al. (2020) summarises these concepts as sequence, repetition and conditionals.

Creating Computational Abstractions

Creating an abstraction requires the ability to conceptualise and then represent an idea or a process in more general terms by foregrounding the important aspects of the idea while backgrounding the less important features (Weintrop et al., 2016). The concept of a variable is an example of creating computational abstractions. By definition, a variable can be changed or adapted in ways that shift the outcome of a process. Creating a usable variable in a computational problem-solving environment requires that students not only understand the problem, but that they also be able to conceptualise and abstract the target elements and create a mental representation. Variables are also applicable in mathematics; however, in the K–6 stage, they are vaguely understood as numbers that take on many values.

Troubleshooting and Debugging

Troubleshooting broadly refers to the process of determining why something is not working or behaving as expected. There are a number of strategies one can employ while troubleshooting a problem, such as clearly identifying the issue, systematically testing the solution to isolate the source of the error or reproducing the problem to reliably test potential solutions. However, it is uncommon to explicitly teach such strategies in a K–6 mathematics setting. For example, the ‘check and interpret’ step of Polya’s (1945) influential problem-solving cycle is often conceived of as checking the answer and calculations to see ‘if they make sense’, but not in the sense of testing the answer with a different configuration.

Research Design, Participants and Procedures

We conducted design-based research with qualitative data collection to investigate the aforementioned RQs. We recruited four Primary 5 and four Primary 6 students belonging to the same classes, respectively, in a Hong Kong primary school to participate in a three-day summer ‘digital making (DM) camp’. The 3-day camp entailed teaching the participants to write programs in Arduino (connected to physical programmable electronics such as LEDs, push buttons and number displays) in the context of solving some mathematical problems. The group consisted of four males and four females (pseudonyms: Adam, Ben, Cecilia, Dana, Edward, Faye, Gordon and Hannah) and was divided into four pairs by the same age (hereafter: AB, CD, EF and GH). In each camp session, the camp instructor (second author) encouraged the students to work cooperatively whilst engaging in the assigned tasks. In addition, the instructor led whole-class discussions at the beginning and end of each session to debrief about the DM activities and introduce relevant CT and/or mathematical knowledge. During the sessions, the instructor and two research assistants circulated the computer lab to interact with students, observing their working solutions and any challenges they encountered. The instructor set up four cameras in the classroom where the pairs worked on the solutions to capture the participants’ hands and the hardware devices’ responses. Built-in cameras on each student-pairs’ laptop recorded the participants’ facial expressions and their conversations during the problem-solving processes.

Design-Based Lessons and Tasks

We used a problem-based or task-based learning setting that revolved around DM with real-life applications. The tasks for Day 1 were to construct a thermometer and a room capacity detector. At the beginning, the instructor gave the students time to familiarise themselves with the block-based programming environment as well as the Arduino hardware. After that, the students designed a thermometer given the Arduino in connection with a temperature sensor – a set of LED displays. During this process, the instructor guided the students to ‘think like a computer’, adding that ‘the computer needs to know what temperature to display’. In this task, the concept of a variable and its implementations was new to students. In the second task, students designed a room capacity detector, which functioned as a counter (displaying the attendance number and utilising the LEDs to monitor three levels of attendance: under-capacity, moderate, and overcapacity). The students had to apply the condition of ‘if … then’ along with inequality signs.

On Day 2, the instructor asked the pairs to create a machine that calculated a bank deposit and balance for a designated scenario. In this problem, the instructor gave the students the chance to consolidate their DM skills by solving three tasks concerning modelling and calculation with increasing levels of difficulty. The instructor taught several programming functions before and while the students were actively solving the problem. For example, the code ‘set variable to’ served as the core function, allowing the desired variable to be operated by the four fundamental operations of arithmetic. Further, the three tasks were closely connected to real-life situations – that is, it required that the students model balance in the bank account after n days. Two different saving offers were given: (1) deposit a constant amount of $222 every day with an initial balance of $3 (i.e. $3, $225, $448, …); (2) make an initial deposit of $3, then deposit twice the amount of the previous deposit (i.e. $3, $3 + 6, $3 + 6 + 12, …) only every Saturday and Sunday. In the last 10 minutes, the instructor invited two pairs of students to present their DM to the other groups, explaining how they used their programs to determine which offer would yield the greater balance after a given day (i.e. 10 weeks).

On Day 3, the instructor asked the students to make a prime and composite number detector. The instructor first raised the question of whether 7,081 was a prime or a composite number as a motivation. The students were able to demonstrate a basic understanding of the characteristics of a prime number, suggesting that 7,081 was a composite number only if it was divisible by a number between 2 and 7,080. However, without the use of a computer, this calculation could take a long time due to the number of divisions required. As such, the instructor introduced a new code ‘remainder of’ – as in, ‘[remainder of] [7,081 ÷ 2]’ yields a non-zero remainder. The students explored how to apply this code along with the ‘repeat x times’ function to indicate whether the number was prime or composite with LED lights.

Method of Analysis

We collated the collected video data, which captured the processes of students’ problem-solving from four different angles, into one video file for each pair of students. We also screenshotted and analysed every set of codes that the students downloaded onto the Arduino devices during the three days according to whether they yielded the solution to the given problem. From this, we identified any potential challenges during the students’ problem-solving processes through closely examining the codes they used in the incorrectly downloaded programs. We also analysed the data from the video sources to triangulate our analyses into students’ difficulties by examining students’ verbal discourse and hardware responses beyond the presence of codes. Firstly, we identified all the instances in which the students expressed their difficulties or were stuck on a problem. This analysis was facilitated by employing constant comparative strategies (Strauss & Corbin, 1990) according to the chosen conceptual framework, which consisted of three categories and three sub-categories. We reviewed the data a second time to explore the degree to which the analyses matched the data. Finally, we selected representative transcript segments that answered the RQs.

Preparing Tasks

For the task in which the students had to set up a room capacity monitor (Day 1), the instructor asked the students to prompt a green, yellow and red LED light signal once given a capacity range. The instructor phrased the problem such that it could be easily translated from everyday language to computational language (‘if … then’). As such, the students spent a relatively short time preparing the problem for its computational solution. On Day 2, the problem regarding bank deposits and balances focused on the mathematics; it was also relatively straightforward to translate into computational language (i.e. performing calculations on the deposit or balance and then displaying it). However, the instructor presented a problem with a greater challenge on Day 3. When making a prime number director, the instructor did not give any explicit instruction on how to display the results. More broadly, the task required the students to use LED lights as indicators – that is, translating the problem into ‘if the number is a prime, then the green light goes on. Otherwise, the red light goes on’. We observed that all of the students were able to comprehend and tried to achieve this goal.

For example, Students EF made significant progress by putting the conditions ‘if remainder = 0, red light on’ and ‘if remainder > 0, green light on’ in the ‘repeat’ loop. As a result, they observed that when a prime number was tested, only a green light would turn on, but when a composite number was tested, both the green and red lights would turn on. Originally, this program could adequately detect whether a number, n, was a prime number (which had no remainder = 0; hence, the red LED would not turn on because the condition was not fulfilled) or a composite number (which had one or more remainders = 0 as well as remainder > 0; thus, the fulfilment of both conditions caused two LEDs to light up). However, Students EF did not realise that the two LEDs in this situation could be interpreted as a solution. Conversely, they were fixated on their preliminary goal of assigning a green light to a prime and assigning a red light to a composite – they believed their program had failed.

From the instructor’s point of view, there were many programming solutions that could function as a prime and composite detector (see Table 2). These different solutions ranged in their levels of complexity, with some using additional functions such as displaying the number of factors of a composite. By contrast, the analysed episode suggests that when the students faced a relatively open question containing multiple representations and interpretations, they encountered difficulties in reframing the problem or could only recognise the most intuitive form of the problem (e.g. green light for prime, red light for composite). In other words, in preparing the problem, they failed to recognise that the solution space was greater than the one they had initially designed.

OPEN IN VIEWER

Table 2.

A Range of Possible Solutions for the Prime and Composite Detector Problem.

	Solution	Prime		Composite			Key execution of codes
		Red	Green	Red	Green	Number display
1	Only display if composite			On			If remainder = 0, Red light on
2	Display prime and composite with two lights		On	On	On		If remainder = 0, Red light onIf remainder > 0, Green light on
3	Only display if prime		Off				Set green light initially on If remainder = 0, Green light off
4	Display prime and composite with different lights		Off	On			Set green light initially on If remainder = 0. Green light off, Red light on
5	Display the first factor of a composite					The first divisor that makes remainder = 0	Repeat until a divisor is found, then display divisor
6	Display the number of factors of a composite					The amount of factors	Create a variable, “counter” which is increased by 1 when a divisor is found.

Programming

Programming constituted the major component of the students’ mathematical problem-solving during the camp, as they needed to solve all of the problems within the block-based programming environment. It was clear that the students’ programming-related challenges evolved throughout the camp, some of which were worthy of further scrutiny. In this section, we analyse these challenges according to Rich et al.’s (2020) categories of sequence, repetition and conditional.

Sequence

In a CT sense, an important element of sequence is including all of the steps to be executed with precise directions, even those that most people could infer on their own. In the room capacity monitor problem, one of the most common mistakes the students made was in the sequence of the code they had to use to initiate the LED lights. When designing a program that controlled the LED lights based on the RC value, one of the typical ways in which they coded was if RC < 20, set green light on; if RC > 20, set red light on (Figure 1). With such codes, the first condition could be executed smoothly, whereby the green light did turn on at the desired RC value of less than 20. However, when it came to the second condition, the students struggled to grasp why both the green and red lights were on once the RC value reached 21. After checking their work and discussing it with the instructor, they finally realised that if they did not instruct the computer to turn the light off, it would keep the light on until the condition was not met.

OPEN IN VIEWER

Figure 1.

The Incorrect Codes Used by Student A and B Regarding the LED Indicators.

As all four groups came up with similar mistaken codes, this reflects the students’ misconception of sequence as well as the state of the device when programming. The statements, ‘if RC < 20, set green light on; if RC > 20, set red light on,’ are conceptually correct; however, the students had incorrectly inferred that when executing the second condition, the first condition automatically became invalid. It reveals that the students had overlooked the fact that the computer would only execute exactly what the programmer coded – in this case, until they had instructed the computer to turn the light off. On top of this, the students demonstrated their lack of recognition that there is some prior state of the device that needs to be taken into account when a certain command is executed.

Another common programming mistake the students made early on Day 2 was that they forgot to tell the program to display their expected output. When solving for the bank deposit and balance problem, many of them checked their codes several times, suspecting that they had done something wrong mathematically, even though they had actually forgot to display the value (Figure 2). Though it was easy to program this step, the students failed to realise that they had to instruct the computer to complete this step. Perhaps the students had thought that the computer would automatically process displaying the outcome (similar to that of the latter condition automatically overriding the former condition as shown in the first analysed scene); therefore, they merely needed to set up the input. This finding reveals that the students’ understanding of sequence, from a CT perspective, was extremely rigid and largely procedural.

OPEN IN VIEWER

Figure 2.

The Codes Used by Students G and H Who Failed to Display the Results.

Repetition

Loops, or repetitions, appeared in all the problems the students were given during the camp. For example, the program contained the language ‘forever’, which caused the codes to repeat running once the computer reached the bottom of the code list. Different from Day 1 and Day 2, the prime and composite detector problem called for the use of ‘repeat’ loops, which the students found to be challenging. To this end, they were aware that it was essential to examine every remainder of the division; however, we observed that on their first attempt, all of the students approached the program with two sets of conditional statements for checking whether ‘remainder = 0’ or ‘remainder ≠ 0’ upon setting up the variable ‘remainder’ as the remainder of 7,081 divided by the ‘divisor’ (Figure 3). The program did not work because the students did not use repetition to cause the divisor to change by one to perform a series of divisions.

OPEN IN VIEWER

Figure 3.

The First Set of Codes Downloaded by Students A and B in the Prime Detector Problem.

Even upon setting an increment of the ‘divisor’ to ‘divisor + 1’, the program failed again (the program detected every number as a composite number). The following transcript illustrates a conversation between Student A and the instructor (‘R’ for researcher).

A: I don’t understand! Why does it always show the green light! Should we try a different number? (Students AB check the program and try to solve it for over ten minutes.)

R: Let me explain to you. You set the divisor to increase by 1. But you have not told the program to stop, so it will increase to over a hundred thousand, to over a million. So, if a number is divided by an infinite number, the result will always be 0. Do you understand what I have said?

A: Oh, I see. I have to tell it to stop!

After resolving the problems as shown above, we observed that the students continued to struggle with placing codes correctly inside or outside the ‘repeat’ loop during the rest of Day 3. Indeed, the idea of stopping a certain procedure is not an obstacle for upper primary students; however, in the current CT environment, breaking loops requires that the coder translate these everyday actions into different kinds of loops: ‘forever’, ‘repeat X times’, ‘repeat until …’, which could make the problem difficult for students in this age group to overcome.

Creating Computational Abstractions

The instructor stated all the tasks used in this study in relatively concrete terms. However, there were a few elements that required more abstract thinking – namely, to create a variable that took on different values throughout the problems. This posed many challenges for the participants. Creating a usable variable in the computational problem-solving environment requires that a student not only understand the problem but also conceptualise the abstract target elements and create a mental representation. The initiation and application of variables were the main sources of difficulty for the students on Day 2, as the task required students to utilise more than one variable. For example, when solving the bank deposit and balance problem, Students GH wrote the codes that can be seen in Figure 4. The following transcript further illustrates their work.

R: Let’s look at it from the beginning. Would you try to explain it from this line?

H: Should we use value (instead of the button state)?

R: Why?

H: Because we are calculating something regarding an amount.

R: But why have you set the button state to 3? What’s the meaning of this line?

G: Shall we rename the button state?

R: No, wait. We need to find out what the variable is. Now we know that ‘button state’ is one variable, should there be some other variables?

G: 222 was the variable.

R: Yes, 222, but what’s the name? What does it represent?

H: The income we got every day.

R: Yes. So, it represents some money, or the income. Only one variable of button state is not enough. We need to set up a new variable.

OPEN IN VIEWER

Figure 4.

A Set of Codes Used by Student G and H for the Bank Balance Problem.

Troubleshooting and Debugging

In the first part of the prime number detector task, the instructor asked the students to test one particular number, 7,081; they did not know whether it was a prime or composite number. Here, testing and debugging were necessary to determine whether they had successfully solved the task. For example, they had to use a smaller number to test their program – they had to match the program output with the known result to test whether the computer had correctly executed the program. This was demonstrated by Students EF who used a series of steps to check if their programs had worked. First, they used 15, a known composite number, and they set the program to repeat the division ‘until’ the divisor = 14 (hence checking the remainder of 15 ÷ 2, 15 ÷ 3, . . 15 ÷ 14). Their second choice was 7, a known prime number, repeating ‘until divisor = 6’. This continued, and they used 14, 16, 7 and 110 in their subsequent tests, repeating the divisions ‘until’ the divisor = 7, 8, 4 and 55, respectively. Interestingly, with the exception of the first trial of testing with the number 15, which yielded an undesirable result, the program responded desirably to the other numbers they tested. From this, Students EF claimed they had successfully created the program.

This pair had made altogether two testing and debugging mistakes. Their first mistake surfaced when the ‘test of 15’ suggested an error in the program; instead of debugging what had gone wrong, the students ignored the error and continued to test other numbers. The second mistake was the numbers the students used. After carefully examining the codes, the researchers found a bug in the program that the students had not discovered – the program had been doing all the divisions (e.g. 15 ÷ 2, 15 ÷ 3, … 15 ÷ 14), yet the condition for checking the remainder had depended only on the last of these divisors (14). In this regard, the students’ choice of numbers to test did not have enough variety to ensure that their testing would be comprehensive. Apart from the first choice in the trial, 15, which was an odd composite number, the students chose even composite numbers to test for the remainder of their trials. Thus, the program had inadvertently produced a desirable result (for example, when testing 14, they repeated the divisions 14 ÷ 2, 14 ÷ 3, … until the divisor was half of the dividend, or 14 ÷ 7). Thus, the students were unable to spot the bug in the program when checking 14, 16 and 110. More generally, this example suggests that the students lacked testing and debugging skills in the computational environment.

On Preparing Problems

As shown, the participants found it challenging to solve relatively open questions. In speculating on the sources of this challenge, we suggest that the participants’ previous mathematics schooling experience may play a role in this. At the primary school level, most mathematics problems in textbooks are explicitly defined, such as ‘determine’, ‘calculate’, and ‘solve’ (CCSSI, 2010). By contrast, the artefact construction dimension of problem-solving contextualised with physical inputs or outputs in this study (i.e. make a device that could detect prime numbers) is very rarely presented in mathematics classrooms (Ng & Chan, 2019; Ng & Ferrara, 2020). Without explicitly stating what to do with the LED lights, the students needed to prepare the problem by setting up scenarios for how to display their results upon checking whether a number was a prime or not. We found that in their first several trials, all of the students set up the scenario of ‘one light represents one result’. This reflects that when preparing their tasks, the students had not considered other possible scenarios that would also make the device work. Weintrop et al. (2016) suggested that mapping problems onto the capabilities of the computational tools was necessary in problem contexts such as these; however, the students had not demonstrated this mapping.

Kapur (2008, 2012) described tasks such as the prime number detector as being ill-structured. Numerous studies have revealed that divergent thinking and the ability to identify and represent problems are greatly improved when students transform a problem from ill-structured to well-structured (Brighouse, 2008; Kennedy-Clark, 2009; Reynolds & Caperton, 2011). In contrast, students must be trained to define an ill-structured task as a well-structured task. Instructional designs involving unplugged activities may help students learn to solve ill-structured tasks. With constructionist activities and problem-solving as a global competence (OECD, 2018), there is an increasing need for mathematics educators to teach students how to solve tasks with multiple entry and exit points (Mason, Burton, & Stacey, 1982). The ability to hypothesise different problem scenarios in constructionist activities remains an important goal and worthwhile pursuit in STEM education research and practice.

On Programming

We observed that the participants consistently forgot to include the code ‘To display the outcome’ throughout the tasks. One explanation for this could be that in real-life situations or in mathematics, displaying a result upon an operation is already inferred in the operation, as in 5 + 3 = 8. Conversely, in a programming environment, the process is divided into two steps: ‘5 + 3 = 8’ and ‘display 8’. The discussions amongst the students revealed that they focused on the mathematical aspects of the task even when there were none. This suggests that, initially, they had not considered displaying the results as a necessary step in their solution.

In terms of the concept of condition, its usage has a broader range in mathematics activities than in computational activities (Rich et al., 2020). We found that the students had mixed success in trying to use conditionals in the prime number detector task. That is, they were able to initiate the condition ‘if the remainder is non-zero, then the number is a prime’. However, their conception of this condition was interfered with by their use of repetition, as the condition must be met as many times as the number of divisions to be performed. In the case of a composite number, the set of remainders from these divisions would be a combination of zeros and non-zero values. We speculate that the students might have wanted to initiate a condition statement ‘if all remainders are non-zeros …’, which is mathematically correct but was not possible to program in the study’s programming environment. The inability to perform an action based on a series of conditions may have posed a challenge for the students, further demonstrating a key difference between CT and MT.

Based on our study results, we provide the following pedagogical suggestion for helping students learning programming. Namely, we suggest the use of ‘tinkering’ activities for students to explore and experience the precision of computer programming as well as conditions and repetitions. During these tinkering activities, the students can perform several different orders of executing a set of actions and then explore their results. Similarly, they may investigate the difference between looping within or outside of a condition.

On Creating Computational Abstractions

When the participants created and implemented variables in their solutions to the piggy bank balance task, their CT and MT contradicted one another. This was illustrated in Students CD’s working solution, in which they used the equation y = 2x to represent the deposit amount as a function of the previous day’s deposit amount (with an initial deposit of $3; i.e. $3, $6, $12, …). Although the equation was valid in that 6 = 2(3), and 12 = 2(6), its recursive structure made it impossible to find the deposit amount after n days without physically calculating all of the previous deposits. In addition, the students’ programming with variables was complicated by its syntax (‘Set [variable] to [variable] *2’). If the students were to treat the variables in a mathematics context, the model would become x = x*2, which would not make sense. We suggest that this is a case of the differences between the notion of variables in MT (i.e. focusing on two entities that are equal on both sides of the equation) and CT (i.e. performing some repetitive actions on a quantity). It seems that the notion of variables in CT is more intuitive, since it can be interpreted dynamically as a set of actions as opposed to statically as equating two entities. As such, we suggest that a relabelling of variables (in CT contexts) into more intuitive terms such as counters or containers may be helpful for learners to distinguish the meaning of variables in different contexts. Finally, we note that the students’ variable-naming improved over the course of the sessions, which reflected both their CT and MT development. From a CT perspective, the name of variable carried important information: a meaningful variable name would help simplify the programmer’s task as it could convey the variable’s function or role in the program (Spohrer & Soloway, 1986; Samurcay, 1989). In this way, the students also developed their MT in terms of defining a variable precisely and accurately. We conclude that for the students, a variable from a CT perspective shared certain synergies with MT in the sense of ‘a number that varies’. However, variable was more abstract in mathematical terms, while it is more intuitive in computational terms.

On Testing and Debugging

Our analysis showed synergies in computational and mathematical activities regarding students’ debugging abilities – they applied novice strategies such as checking step by step and reproducing the error. However, more advanced strategies such as backward reasoning to search from outputs, or using extra output statements in the program to produce outputs were seldom demonstrated by students (Gugerty & Olson, 1986). On the other hand, this study added insights into possible differences between MT and CT – particularly in terms of testing – that could hinder students’ mathematical problem-solving in a programming context. Primary school students are often instructed to check their answers but seldom to test their solution within a different configuration (e.g. ‘changing the data to X’). Perhaps this is because in a mathematical context, applying a new configuration requires that all the steps be redone, which is time- and effort-consuming. However, such issues do not exist in a computational environment, as the computer performs the calculation and procedures. Therefore, students can run as many as tests they wish to simulate even the most extreme situations.

An interesting pedagogical question relates to how we may improve students’ performance on debugging. Chiu and Huang (2015) put forward a scaffolding approach of guided debugging practices for novice programmers. Their study indicated that students’ programming concepts improved significantly after engaging in guided debugging practices; however, little effect was detected on students’ debugging self-efficacy. Indeed, some contrast can be made between the approaches of encouraging exploratory investigation or problem-based learning and of providing direct assistance to students’ debugging processes. On the one hand, exploratory investigation is advantageous in developing effective problem-solving skills, self-directed learning, and collaboration; on the other, such trial-and-error approach of allowing novice programmers to correct their errors and solve a problem by chance (Çakıroğlu & Mumcu, 2020) could become obstacles to their learning of important computational concepts.

In this regard, we consider the use of productive failure as a strategy for supporting students’ guided-debugging and problem-based learning in children’s programming activities. Productive failure typically involves designing tasks that students will fail (Kapur, 2008) but that cause them to acquire negative knowledge (Loibl & Leuders, 2018). Heemsoth and Heinze (2014) defined negative knowledge as the process by which learners reflect on errors, which ‘prevents the learner from committing similar errors again’ (p. 642). When integrating productive failure in computationally enhanced problem-solving, the teacher prompts the students to reflect on their incorrect solution to the problem, which is carefully designed. Besides targeting students’ failure, the teacher might also prepare a set of incorrect programming solutions for students to try to execute and guide them to reflect on any bugs and then fix them as a means of problem solving. In this way, students would not only experience exploratory investigation to the problem but also gain insights from their own mistake by elaborate instruction.