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

Abstract

In this paper, we explore the challenges experienced by a group of Primary 5 to 6 (age 12–14) students as they engaged in a series of problem-solving tasks through block-based programming. The challenges were analysed according to a taxonomy focusing on the presence of computational thinking (CT) elements in mathematics contexts: preparing problems, programming, create computational abstractions, as well as troubleshooting and debugging. Our results suggested that the challenges experienced by students were compounded by both having to learn the CT-based environment as well as to apply mathematical concepts and problem solving in that environment. Possible explanations for the observed challenges stemming from differences between CT and mathematical thinking are discussed in detail, along with suggestions towards improving the effectiveness of integrating CT into mathematics learning. This study provides evidence-based directions towards enriching mathematics education with computation.

Keywords

computational thinking challenges constructionism mathematics education programming

Computational thinking (CT) can be defined as a mode of thinking that involves formulating problems, deconstructing them, restructuring them and communicating their solutions such that humans can understand them and machines can process them (Waterman et al., 2020; Wing, 2006). In the past decades, stakeholders in K–12 education have shown a growing interest in cultivating CT as a 21st century competence to support mathematical literacy and problem-solving skills (Organisation for Economics and Co-operation Development [OECD], 2018). The rapid and ongoing development in coding alongside child-friendly unplugged activities have prompted questions regarding how to effectively implement CT throughout K–12 education. The importance of CT is reflected in many aspects of 21st century competencies such as creativity, critical thinking, and problem-solving (Ananiadou & Claro, 2009; Binkley et al., 2012; Ng & Cui, 2020). Complementary research in this area will enhance our understanding of how computers may – not only instrumentally but in more essential, conceptual ways – influence how people think and problem-solve both in and out of school contexts (Papert, 1980).

Programming is regarded as one of the most effective ways to develop CT for K-12 students; this can be achieved through engaging them in programming activities exhibiting CT via the construction of both screen-based and tangible artefacts (Kafai & Burke, 2013, Margolis et al., 2011, Resnick et al., 2009). In relation to guiding implementation in K–12 classrooms, researchers have made efforts to develop conceptual and methodological frameworks for learning and teaching CT concepts (Brennan & Resnick, 2012; Kong, 2019). In addition, researchers have explored the relationship between CT and thinking practices in several disciplines, particularly those related to mathematics. For example, Sneider et al. (2014) created a Venn diagram illustrating the overlap between mathematical thinking (MT) and CT, wherein common areas included problem-solving, modelling, analysing and interpreting data as well as skills in statistics and probability. They explained that outside the intersection of MT and CT, there exist more distinctly MT (e.g. counting, geometry) or CT (e.g. programming, data mining) practices. Similarly, Weintrop et al. (2016) formulated a taxonomy integrating mathematics and CT into four categories: data practices, modelling and simulation practices, computational problem-solving practices and systems-thinking practices. This mapping enabled them to produce framework statements that reflect how CT is applied – particularly in the context of mathematics and science – as a way to support integrated instruction that mutually enriches students’ learning in each discipline. Rich et al. (2020) compared the differences and synergies between MT and CT by analysing curricular documents. The authors integrated elements of MT with related elements of CT, incorporating these hybrids into the K–5 Common Core State Standards for Mathematics (Rich et al., 2020). They found that differences between the two thinking practices may present instances of potentially problematic or unproductive integration.

Despite the implications of promoting CT in K-12 school settings, empirical research documenting the students’ experiences when acquiring and applying CT in (mathematics) disciplinary learning situations remain underdeveloped. While Basu et al. (2016) examines middle school students’ challenges in CT-based science learning contexts, limited studies have addressed the possible challenges of doing mathematics in CT-based environments. To this end, Rich et al. (2020) provided insights into how researchers can interpret the concept of ‘condition’ differently in mathematical activities (i.e. the condition is assigned between a pattern and its reason for occurring: ‘if there are more pieces, then each piece is smaller’) versus programming activities (i.e. assigning an action based on a prerequisite). They illustrated how students can have trouble directly translating mathematical concepts into a programming language, outlining the potential challenges students face when solving mathematical problems in a computational environment.

In this study, we build on Rich et al.’s (2020) work by collecting empirical evidence to further investigate the challenges primary school students experience during a computationally enhanced mathematics activity. Whereas Rich et al. (2020) only examined three aspects of CT processes (sequence, repetition, conditionals), we adapted these aspects guided by Weintrop et al.’s (2016) overarching framework to facilitate a more thorough consideration of CT concepts and practices (e.g. modelling and using variables) during computationally enhanced mathematical problem-solving. According to Pei et al. (2018), CT and mathematics habits of mind can be instructionally linked; however, opportunities to teach these areas together rarely happen. In response, we aim to provide such opportunities and examine the challenges that arise in relation to different aspects of CT during mathematical problem-solving within these experiences. As a qualitative research, we strive not to generalize the programming-related challenges as common to all primary school students. Rather, we are interested in documenting the challenges as they arise within the context of problem-solving in CT-based environments, as well as to discuss the results in terms of how these challenges may be linked to the synergies/differences between MT and CT in order to make pedagogical implications for improving computationally enhanced mathematics tasks and instructions. Overall, our investigation is guided by the following research questions (RQs):

RQ1 What challenges do upper primary students face when solving mathematical problems in a programming environment?

RQ2 How might these challenges be linked to the synergies/differences between MT and CT in the context of solving mathematical problems in a programming environment?

Conceptual Framework

Weintrop et al. (2016) developed a taxonomy focusing on the presence of CT elements in mathematics and science contexts, making it appropriate for designing various constructionist experiences: unplugged, tinkering, making and remixing (Kotsopoulos et al., 2017). The taxonomy consists of four groups: data practices, modelling and simulation practices, computational problem-solving practices and systems thinking practices. The most pertinent to our RQs for examining students’ challenges when solving mathematical problems in the context of computer programming was ‘computational problem-solving practices’ (Weintrop et al., 2016, p.138). We adopted four of the seven computational problem-solving practices: preparing problems for computational solutions; programming; creating computational abstractions and troubleshooting and debugging. We excluded the other three (choosing effective computational tools, assessing different approaches/solutions to a problem and developing modular computational solutions) because they related to more advanced practices that were beyond the context and scope of the tasks we designed in this study (e.g. we did not give the students a choice of computational platform). Rich et al.’s (2020) work focused on K–5, which was a good match for our upper primary school level focus. Hence, we added Rich et al.’s (2020) classification of sequence, repetition and conditionals as sub-topics under programming, which the authors demonstrated to be programming concepts between MT and CT that could be synergised or be problematically different. We integrated the two frameworks, conceptually grounding the potential challenges primary students may experience during computationally enhanced mathematical problem-solving activities (Table 1).

Table 1.

Topics and Sub-Topics of the Challenges.

Topic	Sub-topic	Description
Preparing problems		Reframing problems so that students can use existing computational tools such as physical devices or software packages.
Programming	Sequence	The precision and completeness of computational or mathematical language
	Repetition	Implicit or explicit recognition of the fact that an act is being repeated and deciding to stop a repetitive action
	Conditionals	Discussion or identification of a connection between one happening and another
Creating computational abstractions		Generating visualisations of data to communicate an idea or finding, defining the scope or scale of a problem, creating models to further explore or understand a given phenomenon
Troubleshooting and debugging		The process of figuring out why something is not working or behaving as expected

In what follows, we provide a brief description of each component in our proposed conceptual framework and illustrate how they might be present in mathematical as well as computational thinking in the unplugged phases.

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.

Sequence

The concept of sequence not only describes the order of steps, but also involves being precise and complete when writing codes. This is because the computers will execute the code exactly as it is written – it will not perform any extra actions or perform them in a different order even if most people would infer these deviations. On the other hand, in a mathematical environment, sequence matters – precise mathematical language and representations are important. As in the meanings ascribed to ‘5 × 7’, one could precisely interpret as, ‘the total number of objects in five groups of seven objects each’. Another interpretation of the same multiplication is ‘the total number of objects in seven groups of five objects each (Common Core State Standards Initiative [CCSSI], 2010). That is, the sequence of the two multiplicands would determine the meaning of the product in different ways.

Repetition

Repetition involves the use of loops within an algorithm to reiterate a set of steps. Because programming depends on a core set of commands that are available within a programming language, coders often use the same commands repeatedly. This is similar in mathematics practice, where it is often necessary to repeat a core procedure – such as checking whether the solution works for a range of values – to accomplish a broader goal. Some differences might lie on determining when to end a loop or repeated procedure. In CT, the loop typically stops for one of two reasons: a predetermined number of iterations has been executed (‘repeat X times’), or a condition has been met (‘while’ or ‘until’). However, in mathematics, the cues to stop are sometimes spatial (filling space) or tactile (running out of things to count).

Conditionals

A conditional is the connection between one happening and another. Students must connect specific actions with the conditions that make the action necessary or desirable. However, there are mathematical contexts wherein the relevant connections are not between an action and its prerequisite conditions, such as between the application of category membership and its prerequisite conditions. For example, the statement ‘if the divisor becomes larger, then the quotient because smaller’ is common in mathematics, but it is difficult to translate into programming language.

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.

Methodology

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.

Results

In what follows, we present our results and categorise them into the corresponding categories/sub-categories to illustrate the challenges the students experienced during their mathematical problem-based DM activities.

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.

Table 2.

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

	Solution	Prime		Composite			Key execution of codes
	Solution	Red	Green	Red	Green	Number display	Key execution of codes
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.

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.

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.

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.

Conditionals

Besides working with repetition, the prime number detector also called for the students to determine the appropriate conditions in order to display whether a prime number was detected. Having reviewed that a prime number is defined as a number that is divisible only by one and itself, the students needed to examine the remainders upon repeatedly dividing a given number, n, by a range of divisors: 2, 3, … , n−1. The following transcript illustrates the students’ discussion about conditionals:

C: We could set, if remainder ≠ 0, then it was a prime number, we set the green lights on.

D: Yes, but we need all the remainder ≠ 0.

C: So, we have to check the remainder every time, but when do we set the green light on? If we set, if remainder ≠ 0, then the green light goes on … I don’t know, I feel like there’s something wrong with it.

D: What about the composite? If remainder = 0, then red light on?

C: I think this is good. Because if any number other than 1 and itself can divide it, it is a composite.

D: OK, let’s try it out.

In the above transcript, the students were aware that they ‘need all the remainder ≠ 0’ and could state the condition that, if all of the remainders ≠ 0, then the number was a prime. However, the students had difficulty translating this condition in a way that the program could execute, likely because in this block-based programming language, the program could not directly adopt ‘all remainders’ as a condition. That is, the program could only check one condition at a time unless the students used the Boolean operator ‘and’ to combine more than one condition. This was not possible in the current problem because the number of conditions could be as many as n−1.

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.

Figure 4.

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

The transcript reveals that the students had trouble dealing with multiple variables to solve the task. Although Student G could verbalise that 222 represented the ‘income’ to be added to the balance every day, he did not realise that he needed a variable to store the amount of the bank balance, which varied every day. Interestingly, Student H suggested renaming the variable as ‘value’ instead of ‘button state’, which could be taken as her addressing the need to initiate a variable for updating the bank balance. However, her suggestion to rename the variable was problematic because it would cause a malfunction with the codes that dealt with the push button (i.e. ‘button state’). As such, the pair failed to create a precise representation for the variables in question. The transcript also shows that the students had difficulty understanding the meaning of ‘setting a new variable’ in the program. Still, they did demonstrate their conception of variables in a mathematical sense – taking on different values.

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.

Discussion

In this section, we discuss the study’s results in terms of how these challenges may be linked to the differences between MT and CT. We also draw pedagogical implications for improving computationally enhanced mathematics tasks and instructions.

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.

Limitation

We point out that due to the small sample size, we strived not for generalisability but for meaningful coherence about the participants’ challenges in the context of engaging in mathematical problem-solving through block-based programming. We achieved this by pursing a worthy topic of qualitative inquiry, posing research questions to examine the participants’ in-moment challenges, triangulating data from different sources and making transparent the analysis of the participants’ discourse. Our qualitative results are in line with previous research investigating young children’s programming difficulties. For example, Tran (2019) studied over 200 elementary school students’ CT performance and found that despite improvements on sequence, the scores on utilising loops, debugging and using conditionals were relatively low after the 10-week lessons. By contrast, this study adds to the research literature by describing primary school students’ CT development, as well as challenges, over 6 hours of problem-based DM given little to no prior experience in programming. We think that these results are encouraging for future research, and we value the qualitative nature of this study for generating in-depth understanding of individual students’ challenges, as well as empirically demonstrating the difference between computational and mathematical concepts as understood by young children learning to program.

Conclusion

In conclusion, our study provides empirical evidence about the challenges that students experience when trying to solve mathematical tasks in a computational environment. While there is extensive research demonstrating the advantages of integrating CT into mathematics education (Benton et al., 2016; Pei et al., 2018; Yadav et al., 2014), limited studies have investigated the potential challenges when solving mathematical tasks in CT-based environments. In many ways, our findings concur with prior research regarding the difficulties or common mistakes of novice programmer (Grover & Basu, 2017; Kim et al., 2018; Tran, 2019). More importantly, our study analysed these challenges from the perspective of synergies and differences between CT and MT, which build on Rich et al.’s work and extend to a more comprehensive framework that includes both procedural and conceptual challenges (Rich et al. 2020; Weintrop et al., 2016). The current study extends the current knowledge about learning mathematics with computational tools. More broadly, it provides evidence-based directions for refining a computationally enhanced mathematics curriculum. Future investigations should explore how best to orient students’ learning trajectories in order to enrich their mathematics education with computation.

Footnotes

Declaration of Conflicting Interests

The authors declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The authors disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This paper is supported by the Research Grants Council, General Research Fund (Ref. No. 14603720).

ORCID iDs

Zhihao Cui

Oi-Lam Ng

Author Biographies

Zhihao Cui is a research assistant in the Department of Curriculum and Instruction at The Chinese University of Hong Kong. He holds an MPhil in Education from the Chinese University of Hong Kong. His research interests include cognitive psychology, mathematical learning and technology supported teaching and learning.

Oi‐Lam Ng is an assistant professor in the Department of Curriculum and Instruction at The Chinese University of Hong Kong. Her research interests include constructionism, 3D printing and STEM education, technology‐mediated and multimodal mathematics learning.

References

Ananiadou, K. and Claro, M. (2009). 21st Century Skills and Competences for New Millennium Learners in OECD Countries. OECD Education Working Papers, No. 41, OECD Publishing, Paris, https://doi.org/10.1787/218525261154

Basu

Biswas

Sengupta

Dickes

Kinnebrew

Clark

(2016). Identifying Middle school students’ challenges in computational thinking-based science learning. Research and Practice in Technology Enhanced Learning, 11(1). https://doi.org/10.1186/s41039-016-0036-2

Benton

Hoyles

Kalas

Noss

(2016). Building mathematical knowledge with programming: Insights from the ScratchMaths project. In Sipitakiat

Tutiyaphunegprasert

(Eds.), Proceedings of constructionism 2016 (pp.25–32). Bangkok: Suksapattana Foundation.

Binkley

Erstad

Herman

Raizen

Ripley

Miller-Ricci

(2012). Defining twenty-first century skills. In Griffin

McGaw

Care

(Eds.), Assessment and teaching of 21st century skills (pp. 17–66). Dordrecht: Springer.

Brennan

Resnick

(2012). New frameworks for studying and assessing the development of computational thinking. In: Proceedings of the 2012 Annual Meeting of the American Educational Research Association, Vancouver, Canada.

Brighouse

(2008). Education without failure? RSA Journal, 154(5535), 36–39.

Çakıroğlu

Ü.

Mumcu

(2020). Focus-Fight-Finalize (3F): Problem-solving steps extracted from behavioral patterns in block based programming. Journal of Educational Computing Research, 58(7), 1279–1310. https://doi.org/10.1177/0735633120930673

Chiu

Huang

(2015). Guided debugging practices of game based programming for novice programmers. International Journal of Information and Education Technology, 5(5), 343–347. https://doi.org/10.7763/ijiet.2015.v5.527

Common Core State Standards Initiative. (2010). Common core state standards for mathematics. www.corestandards.org/Math/

10.

Grover

Basu

(2017). Measuring student learning in introductory block-based programming. Proceedings of the 2017 ACM SIGCSE Technical Symposium on Computer Science Education, 267–272. https://doi.org/10.1145/3017680.3017723

11.

Gugerty

Olson

G. M.

(1986). Comprehension differences in debugging by skilled and novice programmers. In Papers presented at the first workshop on empirical studies of programmers on empirical studies of programmers.

12.

Heemsoth

Heinze

(2014). The impact of incorrect examples on learning fractions: A field experiment with 6th grade students. Instructional Science, 42(4), 639–657. https://doi.org/10.1007/s11251-013-9302-5

13.

Kafai

Burke

(2013). Computer programming goes back to school. Phi Delta Kappan, 95(1), 61–65. https://doi.org/10.1177/003172171309500111

14.

Kapur

(2008). Productive failure. Cognition and Instruction, 26(3), 379–425. https://doi.org/10.1080/07370000802212669

15.

Kapur

(2012). Productive failure in learning the concept of variance. Instructional Science, 40(4), 651–672. https://doi.org/10.1007/s11251-012-9209-6

16.

Kennedy-Clark

(2009). Designing failure to encourage success: Productive failure in a multi-user virtual environment to solve complex problems. Paper presented at the learning in the synergy of multiple disciplines. EC-TEL.

17.

Kim

Yuan

Vasconcelos

Shin

Hill

(2018). Debugging during block-based programming. Instructional Science, 46(5), 767–787. https://doi.org/10.1007/s11251-018-9453-5

18.

Kong

(2019). Components and methods of evaluating computational thinking for fostering creative problem-solvers in senior primary school education. In: Kong

Abelson

(Eds.), Computational thinking education. Springer, Singapore. https://doi.org/10.1007/978-981-13-6528-7

19.

Kotsopoulos

Floyd

Khan

Namukasa

I. K.

Somanath

Weber

Yiu

(2017). A pedagogical framework for computational thinking. Digital Experiences in Mathematics Education, 3(2), 154–171. https://doi.org/10.1007/s40751-017-0031-2

20.

Loibl

Leuders

(2018). Errors during exploration and consolidation—The effectiveness of productive failure as sequentially guided discovery learning. Journal Für Mathematik-Didaktik, 39(1), 69–96. https://doi.org/10.1007/s13138-018-0130-7

21.

Margolis

Goode

Bernier

(2011). The need for computer science. Educational Leadership, 68(5), 68–72.

22.

Mason

Burton

Stacey

(1982). Thinking mathematically. Harlow: Prentice Hall.

23.

Chan

(2019). Learning as making: Using 3D computer-aided design to enhance the learning of shapes and space in STEM-integrated ways. British Journal of Educational Technology, 50(1), 294–308. https://doi.org/10.1111/bjet.12643

24.

Cui

(2020). Examining primary students’ mathematical problem-solving in a programming context: Toward a computationally enhanced mathematics education. ZDM Mathematics Education. Advanced Online Publication, https://doi.org/10.1007/s11858-020-01200-7

25.

Ferrara

(2020). Towards a materialist vision of ‘learning as making’: The case of 3D printing pens in school mathematics. International Journal of Science and Mathematics Education, 18(5), 925–944. https://doi.org/10.1007/s10763-019-10000-9

26.

Organisation for Economics and Co-operation Development. (2018). PISA for development assessment and analytical framework: Reading, mathematics and science. PISA, OECD Publishing.

27.

Papert

(1980). Mindstorms: Children, computers, and powerful ideas. Basic books.

28.

Pei

Weintrop

Wilensky

(2018). Cultivating computational thinking practices and mathematical habits of mind in lattice land. Mathematical Thinking and Learning, 20(1), 75–89. https://doi.org/10.1080/10986065.2018.1403543

29.

Pólya

(1957). How to solve it. Doubleday.

30.

Resnick

Maloney

Monroy-Hernández

Rusk

Eastmond

Brennan

Millner

Rosenbaum

Silver

Silverman

Kafai

(2009). Scratch: Programming for all. Communications of the ACM, 52(11), 60–67.

31.

Reynolds

Caperton

I. H.

(2011). Contrasts in student engagement, meaning-making, dislikes, and challenges in a discovery-based program of game design learning. Educational Technology Research and Development, 59(2), 267–289. https://doi.org/10.1007/s11423-011-9191-8

32.

Rich

K. M.

Spaepen

Strickland

Moran

(2020). Synergies and differences in mathematical and computational thinking: Implications for integrated instruction. Interactive Learning Environments, 28(3), 272–283. https://doi.org/10.1080/10494820.2019.1612445

33.

Samurcay

(1989). The concept of variable in programming: Its meaning and use in problem-solving by novice programmers. In Soloway

Spohrer

, Studying the novice programmer (pp. 161–178). Lawrence Erlbaum Associates.

34.

Sneider

Stephenson

Schafer

Flick

(2014). Teacher's toolkit: Exploring the science framework and NGSS: Computational thinking in the science classroom. Science Scope, 38(3), https://doi.org/10.2505/4/ss14_038_03_10

35.

Spohrer

Soloway

(1986). Novice mistakes: Are the folk wisdoms correct? Communications of the ACM, 29(7), 624–632. https://doi.org/10.1145/6138.6145

36.

Strauss, A., & Corbin, J. (1990). Basics of qualitative research: Grounded theory procedures and techniques. Newbury Park: Sage.

37.

Tran

(2019). Computational thinking equity in elementary classrooms: What third-grade students know and can do. Journal of Educational Computing Research, 57(1), 3–31. https://doi.org/10.1177/0735633117743918

38.

Waterman

K. P.

Goldsmith

Pasquale

(2020). Integrating computational thinking into elementary science curriculum: An examination of activities that support students’ computational thinking in the service of disciplinary learning. Journal of Science Education and Technology, 29(1), 53–64.

39.

Weintrop

Beheshti

Horn

Orton

Jona

Trouille

Wilensky

(2016). Defining computational thinking for mathematics and science classrooms. Journal of Science Education and Technology, 25(1), 127–147. https://doi.org/10.1007/s10956-015-9581-5

40.

Wing

J. M.

(2006). Computational thinking. Communications of the ACM, 49(3), 33–35.

41.

Yadav

Mayfield

Zhou

Hambrusch

Korb

(2014). Computational thinking in elementary and secondary teacher education. ACM Transactions on Computing Education, 14(1), 1–16.