Treffer: Development and Evolution of Instrumented Schemes: A Case Study of Learning Programming for Mathematical Investigations

We are interested in understanding how university students learn to use programming as a tool for "authentic" mathematical investigations (i.e., similar to how some mathematicians use programming in their research work). The theoretical perspective of the instrumental approach offers a way of interpreting this learning in terms of development of schemes by students; these development processes are called instrumental geneses. Nevertheless, how these schemes evolve has not been fully explained. In this paper, we propose to enrich the theoretical frame of the instrumental approach by a model of scheme evolution and to use this new approach to investigate learning to use programming for pure and applied mathematics investigation projects at the university level. We examine the case of one student completing four investigation projects as part of a course workload. We analyze the productive and constructive aspects of the student's activity and the dynamic aspect of the instrumental geneses by identifying the mobilization and evolution of schemes. We argue that our approach constitutes a new theoretical and methodological contribution deepening the understanding of students' instrumented learning processes. Identifying instrumented schemes illuminates in particular how mathematical knowledge and programming knowledge are combined. The analysis in terms of scheme evolutions reveals which characteristics of the situations lead to such evolutions and can thus inform the design of teaching.

As Provided

AN0156619682;esm01jun.22;2022May04.05:22;v2.2.500

Development and evolution of instrumented schemes: a case study of learning programming for mathematical investigations 

We are interested in understanding how university students learn to use programming as a tool for "authentic" mathematical investigations (i.e., similar to how some mathematicians use programming in their research work). The theoretical perspective of the instrumental approach offers a way of interpreting this learning in terms of development of schemes by students; these development processes are called instrumental geneses. Nevertheless, how these schemes evolve has not been fully explained. In this paper, we propose to enrich the theoretical frame of the instrumental approach by a model of scheme evolution and to use this new approach to investigate learning to use programming for pure and applied mathematics investigation projects at the university level. We examine the case of one student completing four investigation projects as part of a course workload. We analyze the productive and constructive aspects of the student's activity and the dynamic aspect of the instrumental geneses by identifying the mobilization and evolution of schemes. We argue that our approach constitutes a new theoretical and methodological contribution deepening the understanding of students' instrumented learning processes. Identifying instrumented schemes illuminates in particular how mathematical knowledge and programming knowledge are combined. The analysis in terms of scheme evolutions reveals which characteristics of the situations lead to such evolutions and can thus inform the design of teaching.

Keywords: Instrumental approach; Scheme evolution; Computer programming; University mathematics education; Mathematics learning

Supplementary Information The online version contains supplementary material available at https://doi.org/10.1007/s10649-021-10133-1.

Introduction

The work presented here takes place in a context of renewed interest for programming and for the joint learning of mathematics and programming. Understanding this complex learning is an important issue for mathematics education research, and we claim that the theoretical frame of the instrumental approach can contribute to such understanding.

We study this issue at the university level and investigate learning to use programming for pure and applied mathematics investigation in the context of an undergraduate mathematics course sequence sustained since 2001 at Brock University: the Mathematics Integrated with Computers and Applications (MICA) I–II–III courses (e.g., see Buteau et al., [12]).

In previous works (e.g., Buteau et al., [14]), we used the instrumental approach (Rabardel, [34]) to investigate students' learning in this context. In this article, we complement this approach by a model of scheme evolution (Coulet, [15]). Our aim here is both to illustrate the use of this new model by applying it to a case study and to refine our understanding of students learning programming for mathematical investigations.

In Section 2, we present a literature review corresponding to programming and project-based learning at the university level. In Section 3, we present our theoretical frame—the instrumental approach—and a model of scheme evolution. We study the case of a student, Jim, and describe our methods for data collection and analysis in Section 4. In Section 5 we present our results concerning the schemes developed by Jim and their evolution, and we discuss these results in Section 6.

Literature review and background

In this section, we first briefly synthesize works related to programming and/or project-based teaching at the university level. Then we introduce some aspects of previous works of the MICA team, which we build upon in the present study.

Related works: programming, project-based teaching at the university level

A focus on coding, computer programming, and computational thinking (Wing, [45]) in education in general, including mathematics education, has grown in the past few years. This interest has a legacy of half a century, since the development of the Logo programming language (Feurzeig & Lukas, [17]), when a relationship between computer programming with mathematical thinking and learning was recognized (e.g., Papert, [31]). As Noss and Hoyles ([30]) explain, a learner who engages in modifying a program articulates relationships between concepts involved in the program, and "it is in this process of articulation that a learner can create mathematics and simultaneously reveal this act of creation to an observer" (p. 54). The pioneer works with Logo also led to the development of an educational paradigm, called constructionism (Papert, [32]), which not only emphasized student-centered computer programming but also other aspects such as project-based learning.

Thus, from the 1970s until the 1990s, much research focused on programming's potential for engaging in mathematical thinking and learning (Benton et al., [4]). With the recent renewed interest, research has explored programming for mathematics. Misfeldt and Ejsing-Duun ([28]) use the instrumental approach (Guin et al., [20]) to propose a model to address teaching mathematics mediated by programming at primary and lower secondary school in Denmark. Lagrange and Rogalski ([22]), in light of the (re-)introduction of programming and algorithmics in the French secondary school curriculum, review research results from this field. They highlight, among several issues, the importance of learning situations and of semiotic registers of representations and also briefly point to the question of the modeling of mathematical objects through computer programming. We note that the studies they review do not use the instrumental approach.

Concerning the tertiary level, some educational studies have revealed how programming may support students' understanding of mathematical concepts (e.g., Leron & Dubinsky, [23]; Wilensky, [44]) and may contribute to the development of critical thinking skills (e.g., Abrahamson et al., [1]; Buteau et al., [9]). A noteworthy recent study is that of Lockwood and De Chenne ([24]) who investigated undergraduate students' combinatorial reasoning in the context of Python computer programming. Other studies focused on project-based learning and programming at university level and some in non-mathematical areas linked with different mathematical themes—for example, pertaining to biology students (e.g., Ludwig et al., [25]; Mascaró et al., [27]) or mathematical modeling in areas such as engineering (e.g., Schmidt & Winsløw, [39])—although the studies tend not to investigate the technology used. Also, other than our own research (e.g., Buteau et al., [6]; Gueudet et al., [19]), we did not find studies at university level whose theoretical frameworks used the instrumental approach.

Previous research on the MICA courses

Our ongoing research builds on previous studies that focus on MICA courses (e.g., Buteau et al., [12]; Ralph, [37]). In these courses, mathematics majors and future mathematics teachers learn to design and program (mainly in VB.NET language) interactive computer environments, which we have called exploratory objects (EOs), to investigate mathematical concepts, conjectures, theorems, or real-world situations (Muller et al., [29]). For example, we have focused our work on students' constructionist experiences throughout a sequence of 14 EO projects (Buteau et al., [10]), assessment (Buteau & Muller, [8]), and roles and demands of instructors (Buteau et al., [14]). In particular, we examined students' activity that led to a model (see Fig. 1) describing students' process of developing their programming-based mathematics investigation from start to finish in a cyclic and non-linear manner (Buteau & Muller, [7]; Buteau et al., [6]; Marshall & Buteau, [26]). Jim (pseudonym), for example, having decided to investigate the Pólya conjecture (steps 1 − 2), designed a numerical experiment and programmed it in VB.NET (step 3), made sure the program worked correctly (step 4), conducted the experiment by testing numerous cases (steps 5 − 6), and summarized his mathematical investigation, including his results, in a written report (step 7); see the short video (Balt & Buteau, [2]) for an illustration of Jim's activity. It turns out that this model aligns with mathematicians' process when using programming in their own research work (see Broley et al., [5]). This paper focuses on and seeks to gain a deeper understanding of such students' learning processes by using the instrumental approach and a theory of scheme evolution that we briefly summarize in the next section.

Graph: Fig. 1 Development process (dp) model of a student engaging in programming for an authentic mathematical investigation or application (Buteau et al., [6])

Theoretical frames and research question

In this section, we introduce the theoretical frame of the instrumental approach (Rabardel, [34]) and in particular the concept of scheme. We also present a model of scheme mobilization and evolutions proposed by Coulet ([15]). We follow these with our research question.

The instrumental approach, the concept of scheme

The instrumental approach was introduced in the field of cognitive ergonomics by Rabardel ([34]) and further developed and used in mathematics education (Guin et al., [20]). Focusing on human instrumented activity, it distinguishes between an artifact—a physical or non-physical object that is used to achieve a given task—and an instrument (psychological construct) that emerges when there is a meaningful relationship between the artifact and the user for a specific type of task (Rabardel, [34]).

The instrumental approach is rooted in activity theory (Vygotsky, [43]) and draws on the theory of conceptual fields (Vergnaud, [41]), using in particular the concept of scheme (inherited from Piaget, [33]). It studies the goal-directed instrumented activity of subjects (who in our study are mathematics students). A given goal (e.g., "program a simulation of a random experience") defines a class of activity situations (Rabardel & Bourmaud, [36])—a set of situations with the same goal. The activity of the subject is mediated by artifacts (e.g., a programming language). During the activity for different situations of the same class with the artifact, the subject develops an instrument, associating the artifact, and a scheme of use of this artifact. This process is called an instrumental genesis.

A scheme (Vergnaud, [41]) is a stable organization of the subject's activity, for a given class of situations. It comprises four components:

Theorems-in-action (TiAs) are propositions considered as true (e.g., "to simulate a random experiment, I need to generate random numbers in a given range"); they are associated with concepts-in-action (CiAs), concepts considered as relevant (e.g., "simulation"). Inferences constitute the reasoning allowing the subject to calculate subgoals, rules, and properties of the situation (Rabardel, [34]).

The instrumental approach provides theoretical tools for a very precise analysis of how subjects simultaneously act and learn, along their activity mediated with artifacts. Describing the different components of a scheme sheds some light on how the subject collects information, produces inferences, and adapts to a particular situation. Nevertheless, neither the instrumental approach nor the theory of conceptual fields explains how the schemes evolve—how new rules of action (RoAs) or new operational invariants (OIs) are generated along the activity. In the next section, we present a model of this evolution process.

From the instrumental approach perspective, the unit of analysis is the instrument-mediated activity. In our context, the unit of analysis is the students' instrument-mediated activity of using programming language for mathematics investigations in project-based tasks. More precisely, the artifact is a programming language together with an integrated development environment (IDE), for example, Python in Jupyter Notebook IDE or VB.NET in Visual Studio IDE (Buteau et al., [14]).

In our previous work (e.g., Gueudet et al., [19]), we evidenced that students working with this artifact develop schemes for different aims of their activity. We introduced a distinction between m-schemes (when the goal of the activity only concerns mathematics), p-schemes (goal concerning only programming), and (p + m)-schemes, when the goal associates mathematics and programming. For example, the m-scheme of formulating a mathematical conjecture and the p-scheme of debugging associated to step 1 and 4, respectively, in the dp-model. In this paper (Sections 5 and 6), we focus on (p + m) schemes, linking programming and mathematics.

Evolution of schemes

One of the fundamental points of the instrumental approach and its focus on human activity is the consideration and articulation of two functions or dimensions of the subject's activity: productive dimension and constructive dimension. As Rabardel and Bourmaud ([35]) note: "It is the expression of an ontological characteristic of human activity: activity is both productive, i.e. oriented toward the production of results, and constructive, i.e. oriented toward the development of the subject's instruments and resources" (p. 688). The concept of instrumental genesis presented in the previous section provides a precise meaning for these two dimensions. On the one hand, the subject's activity is oriented toward a given goal and mobilizes existing schemes; on the other hand, along this activity, these schemes are evolving. But how do they evolve?

The work of Coulet ([15]) provides answers to this question. Focusing on the two dimensions of the activity—productive and constructive—Coulet proposes a dynamic model of competence: "Dynamic analysis model to describe and assess competences" (Fig. 2). Coulet defines competence as the pair (situation, scheme) and notes that individuals' competence should be viewed primarily as adaptive organization of their activity. This model characterizes the organization of these dimensions in terms of mobilization of a scheme in a given situation as articulated by Vergnaud ([41]), mediated by artifacts and reorganized with three regulation loops.

Graph: Fig. 2 Dynamic analysis model to describe and assess competences (Coulet, [15])

Coulet's model utilizes Piaget's ([33]) theory of equilibration which articulates how individuals adapt to their environment. When individuals encounter something new or foreign to their structures for understanding (i.e., scheme), an imbalance happens that requires restoring. Equilibration involves two processes: assimilation (assimilating the new element by bringing it into the structure) and accommodation (accommodating or modifying the learning).

Schemes are adaptable cognitive structures that have a history, which changes as they are adapted to a range of different situations (Béguin & Rabardel, [3]); in other words, schemes assimilate. Also, schemes are accommodating, which means they can change when the situation changes. Coulet's model allows for the description of the activity as a "productive activity," expressed by mobilization of a scheme, and uses the three regulation loops of the activity ("constructive activity"), to specify evolution of scheme:

Our study does not focus on competences but rather on the learning processes taking place in a goal-directed activity mediated by artifacts. For this reason, we will call Coulet's model "model of scheme evolution."

Research question

Within the instrumental approach, learning is viewed through the concept of instrumental genesis: learning means developing schemes, which are mobilized for given situations and enriched through the activity in these situations. Nevertheless, how schemes emerge and evolve is not explained in the theory. Hence, the model of scheme evolution could be a useful complement for a refined understanding of the instrumental geneses. With this perspective, the research question we focus on here is:How does the instrumental approach, enriched by a model of scheme evolution, capture how students learn to use programming for authentic mathematical investigations?

Methods

In this article, we use the instrumental approach and the dynamic model of scheme evolution frames to investigate the case of Jim, a participant in the first year of our naturalistic (i.e., not design-based) 5-year research in which some parts (participant recruitment and data collection) were designed in a way that would be least intrusive to (or constrained by) the natural learning environment (i.e., the undergraduate MICA I–II–III course sequence mentioned above). Our research follows students' development during (and beyond) their MICA courses, as they engage in 14 mathematics exploratory object projects that count for 71% of each student's final grades. Participants in the first year of this research included Jim and five others from a pool of 46 MICA I students who were voluntarily recruited. The MICA I course consists of four projects: three assigned individual ones and a fourth for which students freely select the topic. The course format includes a 2-h weekly lab, where students progressively learn to program in a mathematical context, and 2-h weekly lectures that introduce students to the mathematics needed for their investigation project assignments (Buteau et al., [12]).

Data collected in our research include in particular each participant's MICA I projects (that include a computer program and accompanying report for each project) and individual semi-structured task-based interviews after completion of each of their projects. The interview guiding questions incorporated "explicitation" techniques (Vermersch, [42]) for each project to help participants relive their actions during the whole project development, and as such aligned with the dp-model (see Fig. 1; see also Appendix 1 for the interview template). Student participant data also included weekly post-lab session online reflections (with guiding questions) and an initial baseline online questionnaire, followed by an interview, before the beginning of MICA I. In addition, we collected all course material, including lab session and project guidelines.

To initiate the scheme analysis, we selected Jim because he was particularly reflective and elaborated more on his responses. Jim is not exceptional in terms of achievement (in mathematics or in programming). His early data (baseline questionnaire; baseline interview; lab 1–4 reflections; project 1 interview; project 1 including program and report) were first analyzed, individually by two parties and then consolidated, for an initial identification and description of schemes compiled in a table. We analyzed Jim's interviews by trying to observe in his declarations elements of schemes: goal of the activity, description of how he acted in the situation, and reasons for acting this way. The table of schemes was then reorganized according to the dp-model. In addition, Jim's whole data were coded through thematic analysis techniques, as were the other five participants' data. Codes were developed based on categories informed by the conceptual framework (Buteau et al., [11]). Each participant's interview and lab reflection data were coded individually by two coders, followed by a thematic analysis done jointly by the two coders. Themes were consolidated among the six participants' analyses and led to 16 subthemes regrouped in five main themes, two of which corresponded to strategies and perceptions. Using codes under the strategies (associated to rules-of-action) and the perceptions (associated to operational invariants) themes, the initial table of Jim's schemes was refined and chronologically extended to his whole MICA I data (see Appendix 2 for screenshots illustrating the whole scheme table). This analysis of Jim's schemes also included the coding of his projects. Moreover, whenever Jim did not present a reason for a given rule-of-action, we hypothesized an associated operational invariant. Finally, we refined further the scheme descriptions with subgoals, anticipations, and inferences while revisiting the data.

The usual methodology associated with the instrumental approach to study a subject's learning involves direct observation of the subject's activity (Drijvers et al., [16]). In Gueudet et al. ([19]), we noted however that due to our naturalistic methodological approach and because students complete most of their project work outside classroom time, we do not directly observe participants' project engagement in order to confront their declarations during their interviews and their actual activity. Only a part of this activity is accessible through the projects they produce. Not directly observing students is certainly a limitation of our research, but on the other hand, our methodology incorporates all institutional constraints of the subject's activity. We mitigate this limitation by triangulating all the data available on each participant, projects (their produced program and written report), task-based interview transcriptions, and lab reflections, and as such, we suggest that the analysis of our collected data provides significant evidence of the subjects' instrumental genesis (Gueudet et al., [19]).

For this case study, we focused on Jim's data from MICA I. Jim is a first year student in the Bachelor of Science Honours in Mathematics program. From his baseline questionnaire, we noted that his outlook toward mathematics and technology was very positive prior to entering the course. Formally, he had very limited knowledge of computer programming, except for some exposure in his youth with Logo programming. Through the MICA I course, Jim completed all four assigned mathematics investigation projects, namely project 1 concerning the investigation of a conjecture (of their choice) about prime numbers (Jim chose the Pólya conjecture); project 2 about the RSA encryption method, including the random generation of public and private keys; project 3 concerning the exploration of the discrete dynamic system based on a two-parameter cubic; and the original final project 4, in lieu of a final exam, about a pure or applied mathematics investigation of their choice (Jim decided to investigate the Buffon needle problem about the probability that a needle randomly dropped on a floor with parallel slats would cross over two slats).

Results

In this section, we present examples of analyses of the data collected. These analyses concern firstly (§5.1) the development by Jim of a new scheme; then Jim's mobilization of this scheme, which is the productive aspect of his activity (§5.2); and finally (§5.3) evolutions of this scheme and of a second scheme, strongly linked with the first one. We present these schemes as tables (e.g., Table 1) including their different elements: the goal, subgoals, anticipations, rules of action (RoAs), operational invariants (we focused on theorems-in-action for length reasons), and inferences. The order in the table corresponds—as far as possible—with the organization of the activity.

Table 1 Description of the scheme: "articulating a mathematical process in the programming language"

<table frame="hsides" rules="groups"><thead><tr><th align="left" colspan="2"><p>Goal (p + m)/subgoals and anticipations</p></th><th align="left"><p>Rules-of-action</p></th><th align="left"><p>Theorems-in-action</p></th></tr></thead><tbody><tr><td align="left" rowspan="6"><p>Articulating a mathematical process in the programming language</p></td><td align="left" rowspan="3"><p>Organizing the mathematical process for its coding&#8212;anticipation of a program structure</p></td><td align="left"><p>I start by organizing, on paper, what needs to be programmed until I get the whole picture</p></td><td align="left"><p>Writing ideas on paper helps organize my thoughts</p></td></tr><tr><td align="left"><p>I organize the mathematical process as a nested system</p></td><td align="left"><p>There might not be a "procedure" to follow when coding a mathematical process. It is a creative activity</p><p>A mathematical process can be seen as a nested system made of many parts</p><p>Mathematics and programming as systems have embedded layers</p></td></tr><tr><td align="left"><p>I decompose the nested system in individual processes before programming</p></td><td align="left"><p>To program a nested mathematics process, one can break it down and individually code the smaller parts</p></td></tr><tr><td align="left" rowspan="3"><p>Programming&#8212;anticipation of a code</p></td><td align="left"><p>I begin the coding by "translating" in the programming language what I would do by hand</p></td><td align="left"><p>A programming language can work in a similar manner as one works by hand</p></td></tr><tr><td align="left"><p>I incrementally code individual processes of the nested system</p></td><td align="left"><p>Coding individual processes incrementally facilitates developing and controlling, step-wise, a code</p></td></tr><tr><td align="left"><p>If I previously coded a similar process, I remix that code</p></td><td align="left"><p>Previous codes may be useful for my current program</p></td></tr><tr><td align="left" colspan="4"><p>Inferences. Jim starts by organizing the mathematical process. His reasoning is based on the anticipation of a program structure (Jim will infer the program structure based on the situation). Jim organizes first his ideas on paper (RoA). He knows that "A mathematical process can be seen as a nested system made of many parts" and that "to program a nested mathematical process, one can break it down and individually code the smaller parts" (TiAs), which makes him organize the overall mathematical process and its smaller individual mathematics components (RoAs). When Jim has a picture of the whole of his program structure (information gathering), he begins to program with the anticipation of a code (Jim will infer the code based on the situation). He appears to believe that "a programming language can work in a similar manner as one works by hand" (TiA), which explains that he starts by "translating" what he would do by hand (RoA). Jim knows that coding incrementally individual processes facilitates developing step-wise a code and controlling it (TiA), which leads him to incrementally code according to the program structure he has in mind. All along, if he remembers (information gathering) similar mathematical processes that he previously coded and as such could be useful in his current program (TiA), he remixes it (RoA)&#8212;that is, he searches for the code already written and makes necessary modifications</p></td></tr></tbody></table>

Development of a scheme and constructive activity

Here we present the example of development of the scheme "articulating a mathematical process in the programming language" associated to step 3 in the dp-model. Table 1 summarizes the components of this scheme that Jim appears to have developed in his first mathematics investigation project (project 1, investigating the Pólya conjecture about prime numbers). Up until the project 1 in the course, Jim had not been required to articulate from scratch a mathematical process in programming, and as such, we hypothesize that Jim developed a new scheme. It is a (p + m)-scheme because its goal involves both programming and mathematics.

Jim had been given in lab 3, prior to his project 1, a VB.NET code (with a minor bug) that checks whether a positive integer is prime or not and was asked to copy, fix, and explain it. For his project 1, Jim had to create a code counting the number of prime factors of a given integer (input) in order to investigate Pólya's conjecture. In describing how he approached the coding of his project 1, Jim noted:I tried to start on paper ... I basically tried to organize and sort out what needed to be programmed but I kind of realized as I was going, I kind of knew everything that needed to be done. It just required a set of systems nested within each other so once I know that, I had to figure out how to program each individual system. This one check for prime. This one is a loop ... that sort of thing. (Jim.EO1.8)

We interpret this description by Jim as indicating many rules of action while anticipating a program structure for the Pólya conjecture, such as "I start by organizing on paper ..."; "I organize the mathematical process as a nested system"; and "I decompose the nested system in individual processes before programming." In particular, Jim's reflection of "I kind of knew everything that needed to be done" may be interpreted as Jim's information gathering as part of this scheme: Jim checks that he does not need new knowledge for the coding of the Pólya conjecture. As such, he only has to identify the different components, in mathematics and in programming, and associate them. We interpret that Jim grounds this association on the belief that "Mathematics and programming as systems have embedded layers" (theorem-in-action), as suggested from his statement:How sometimes you will have a variable within a sine function. ... Or a nested loop, kind of one layer down. It is like something within a greater system. (Jim.EO1.11)

Jim completed a working program to investigate the Pólya conjecture. His final code (see Fig. 3 for excerpt) evidences that he programmed according to a planned nested system structure as mentioned in the quote above, namely "It just required a set of systems nested within each other so once I know that, I had to figure out how to program each individual system." Indeed, Jim used comments in his program that highlight individual processes (/\ i to \/ i) of his designed nested structure. In it, we find a modified copy of the lab 3 code (from /\ 3 to \/ 4) about checking the primality of a positive integer, which suggests Jim's rule-of-action of remixing.

Graph: Fig. 3 Excerpt of Jim's project 1 code concerning the Pólya conjecture (highlights added by the authors)

Prior to the programming of his project 1, in lab 3, Jim foresees his approach to coding a mathematics process from scratch to "start by 'translating' what I would do by hand"; Jim writes about the programming of checking the primality of a positive integer:[I] do believe that assuming I knew how to use the 'Mod' command I would have (given time) been able to make something resembling it from scratch, as the logic of how it searches for primes has already been touched upon in class [i.e. a paper & pencil method]. (Jim.Lab3)

By the end of project 1, Jim appeared to have developed a stable organization of the activity for the goal "articulating a mathematical process in the programming language": a scheme (termed "articulating" scheme in what follows). As we will describe in the next subsections, Jim mobilized this scheme (productive activity) for posteriori situations; moreover, this scheme also evolved (constructive activity).

Mobilization of the scheme and productive activity

In the subsequent projects, Jim had to articulate mathematical processes in the programming language and, as such, mobilized his scheme described in Table 1. Indeed, his approach appears to have been similar as his account of his engagement suggests particularly the rules-of-action "I decompose the nested system in individual processes before programming" and "I incrementally code individual processes of the nested system" and no new rule-of-action. For example, concerning his project 2 project on RSA encryption, Jim reports:I would program each process in steps either into a function or when it was ready into the final method. (Jim.EO2.5)

Jim also elaborates on all the steps he did. In addition in his project 2 code, we find evidence of the three mathematical processes, namely <math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><msup><mrow><mi>a</mi></mrow><mi>k</mi></msup><mi>m</mi><mi>o</mi><mi>d</mi><mi>n</mi></mrow></math> , gcd(m,n), and Euler <math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mi>&#966;</mi><mfenced close=")" open="("><mi>n</mi></mfenced></mrow></math> functions, separately coded as programming functions and combined in a way that articulates the aimed RSA mathematics process of encoding a secret message M given a public key (n,e), that is, <math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><msup><mrow><mi>M</mi></mrow><mi>e</mi></msup><mi>m</mi><mi>o</mi><mi>d</mi><mi>&#966;</mi><mfenced close=")" open="("><mi>n</mi></mfenced></mrow></math> . Also, his code for these three processes aligns with the labs 5 and 6 guidelines and, as such, suggests that Jim remixed the related codes from his previous lab work. Later in his project 3 about the investigation of the discrete dynamical system of a two-parameter cubic, Jim reports highlighting clearly his incremental coding approach:It was more just, program it in steps and just chunk, chunk it all together and make the program. (Jim.EO3.4)

Jim thus appears to have mobilized once more his "articulating" scheme; indeed, Jim's code provides some evidence of this, but also, when describing how he approached this project 3, Jim notes:I basically used that lab [9, where we coded a numerical and graphical representation of the dynamical system based on the logistic function] as a template and then just built off of that. (Jim.EO3.4)

However, working on the project 2 produced a specific feedback: Jim reports having felt lost in the code as he was still completing it. It led him to modify part of his scheme as described below.

Evolution of schemes and constructive activity

In this section, we consider the evolution, through short-loop and long-loop regulations, of two examples of scheme: the "articulating scheme" evoked above and of a second (p + m) scheme "validating the programmed mathematics." This second scheme corresponds to step 4 of the dp-model but is strongly connected with the "articulating" scheme.

Short-loop regulation

In project 2, Jim faced more elaborated mathematical processes than in project 1 to code in VB.NET. This new situation required that Jim adapt his "articulating scheme." He appears to have failed to adapt it in project 2 but to have rectified it in project 3 as a change in the organization of his rules-of-action to better achieve the same productive activity described above; indeed, Jim says:half way through [in project 2] I had stopped kinda planning and kind of regretted that afterwards, as it's like you kind of get lost in the code but ah this, for this [project 3] project I planned fairly well, I didn't get lost, it was straightforward, so I'm pretty happy with the way I did this. (Jim.EO3.39)

This change in his activity organization appears to take form as a refined rule of information gathering that triggers his moving between the two subgoals, as we describe in this revised sentence part of the inferences in Table 1 (revision in italics): "When Jim has a picture of a part or the whole of his program structure (information gathering), he begins to program with the anticipation of a code."

According to Coulet's model, this can be interpreted as a short-loop regulation.

Long-loop regulation

We consider here step 4 of the dp-model: "Verifying and validating the (mathematics) code of the object." In this step, some of Jim's activity was a classical debugging activity (e.g., correcting typos in VB.NET). We do not consider this activity but focus on the validation linked with the mathematics.

In project 1, Jim tested his program (investigating the Pólya conjecture) with simple cases. He provided numerous data examples in his report, including for the (easily hand-calculated) cases of n = 8 and n = 9, each with a total of 5 integers, smaller or equal to n, having an odd number of prime factors. We interpret that, in project 1, Jim developed a scheme for the goal "validating the programmed mathematics," with the characteristics presented in Table 2.

Table 2 Description of the scheme "validating the programmed mathematics," project 1

<table frame="hsides" rules="groups"><thead><tr><th align="left" colspan="2"><p>Goal (p + m)/subgoals and anticipations</p></th><th align="left"><p>Rules-of-action</p></th><th align="left"><p>Theorems-in-action</p></th></tr></thead><tbody><tr><td align="left"><p>Validating the programmed mathematics</p></td><td align="left"><p>Realize an input/output test of the program</p><p>Anticipation of a mistake in the programmed mathematics</p></td><td align="left"><p>I choose cases for which I know the results (calculated by hand, from a trustful source, etc.)</p><p>I enter these inputs in the program and compare the outputs with the expected results</p></td><td align="left"><p>An unexpected output indicates that the program must be corrected</p><p>A program providing no incorrect outputs for several inputs is likely to be valid</p></td></tr><tr><td align="left" colspan="4"><p>Inferences. Jim anticipates that there might be some mistakes in the programmed mathematics. He chooses cases for which he can find the results without using his program (RoA). Then he uses these cases as inputs in his program and compares the outputs with the expected results (RoA). If all of the tested outputs correspond with the expected results, Jim infers that the programmed mathematics is valid</p></td></tr></tbody></table>

This scheme evolved for project 2 and remained unchanged for project 3. The proposed tasks (RSA encryption and discrete dynamic systems, respectively) involved significantly more elaborated mathematics processes than in project 1. Jim describes obtaining an unexpected result while working on his project 2 program; we interpret that he repetitively applied the rules-of-action above as he altered his code until he obtained the expected results.As the program became more and more complex it became more and more difficult if something went wrong to kind of go back and see where it went wrong. I remember there was one part where I ... I don't remember ... I think it was something that I put the wrong starting number in a FOR loop or something and I didn't catch it until after a lot of trial and error. (Jim.EO2.9)

We interpret this as a long loop: the feedback from the task leads Jim to develop a new theorem-in-action, "In a long program it is difficult to identify where a mistake is." This led him to need to alternate coding and validation (firstly testing individual parts, then combining them, then testing the combinations), thereby making his testing procedure more complex.Simply put [how did I know it worked?], basically by running it. I would test each kind of function in isolation to make sure it's working properly. I would test each function individually to make sure they work and then basically combined the function in simple ways, and then if the program didn't crash or did something completely unexpected, I could basically assume from that point that it is working properly, and by the end I would just be able to type in a message, encode, generate some keys, encode copy paste and decode the message back and it would work perfectly. (Jim.EO2.14)

In project 2, it was not possible for Jim to compute an output by hand. This prompted another long loop: Jim tested the whole program with cases for which he was able to determine the result, combining input/output tests, based on a mathematical property. The mathematics content (RSA encryption) led to a particular kind of case: from the encrypted form of an input message, the program (with the adequate key) should produce the original message (i.e., by performing an appropriate pair of input/output tests). We interpret this as a particular inference, allowing Jim to adapt his activity in the case of the RSA encryption.

Moreover, Jim did not choose only random chains of characters for his tests. Another new rule-of-action and an associated theorem-in-action were linked with the coding/decoding of "potentially problematic cases" to test the validity. If the program returns correct outputs for potentially problematic cases, he can have even more confidence in its validity:Oh yeah, I did the classic statement: 'The quick brown fox.[1]' All worked perfectly. (Jim.EO2.17).

We summarize the evolved version of the scheme in Table 3.

Table 3 Evolutions in the scheme "validating the programmed mathematics," project 2. (The new elements are in italics)

<table frame="hsides" rules="groups"><thead><tr><th align="left" colspan="2"><p>Goal (p + m)/subgoals and anticipations</p></th><th align="left"><p>Rules-of-action</p></th><th align="left"><p>Theorems-in-action</p></th></tr></thead><tbody><tr><td align="left" rowspan="5"><p>Validating the programmed mathematics</p></td><td align="left"><p>Realize an input/output test of <italic>a part</italic> of the program</p><p>Anticipation of a mistake in <italic>a part</italic> of the program</p></td><td align="left"><p>I choose cases for which I know the results <italic>of a part of the program</italic> (calculated by hand, from a trustful source, etc.)</p><p>I enter these inputs in <italic>the part of program</italic> and compare the outputs with the expected results</p></td><td align="left"><p><italic>In a long program, it is difficult to identify where a mistake is</italic></p><p><italic>A program is valid if each part of it is valid</italic></p><p>An unexpected output indicates that <italic>a part of the</italic> program must be corrected</p><p><italic>A part of</italic> the program providing no incorrect outputs for several inputs is likely to be valid</p></td></tr><tr><td align="left"><p>Realize an input/output test of <italic>the combination of valid parts</italic></p><p>Anticipation of a mistake in <italic>the combination</italic></p></td><td align="left"><p>I choose cases for which I know the results <italic>of a part of the program</italic> (calculated by hand, from a trustful source, etc.)</p><p>I enter these inputs in <italic>the part of program</italic> and compare the outputs with the expected results</p></td><td align="left"><p><italic>In a long program, it is difficult to identify where a mistake is</italic></p><p><italic>A program is valid if each part of it is valid</italic></p><p>An unexpected output <italic>from the combination of valid parts</italic> indicates that <italic>the combination</italic> must be corrected</p></td></tr><tr><td align="left" rowspan="3"><p>Realize an input/output test of the program</p><p>Anticipation of a mistake in the program</p></td><td align="left"><p>I choose cases for which I know the results (calculated by hand, from a trustful source, etc.)</p><p>I enter these inputs in the program and compare the outputs with the expected results</p></td><td align="left"><p>An unexpected output indicates that the program must be corrected</p><p>A program providing no incorrect outputs for several inputs is likely to be valid</p></td></tr><tr><td align="left"><p><italic>If I am unable to determine cases for which I know the results, I combine input/output tests for which I know the result based on mathematical properties</italic></p></td><td align="left"><p><italic>A mathematical property must be carried over into the programmed mathematics</italic></p></td></tr><tr><td align="left"><p><italic>I choose and test potentially problematic cases</italic></p></td><td align="left"><p><italic>A program providing no incorrect output for a potentially problematic case is likely to be valid</italic></p></td></tr><tr><td align="left" colspan="4"><p>Inferences. Jim anticipates mistakes in his program. <italic>He knows that "in a long program it is difficult to identify where a mistake is" and that "a program is valid if each part of it is valid" (TiAs). This leads him to alternate phases of programming and validating. He anticipates mistakes in each part of the program; thus, after writing a part of the program,</italic> he tests its validity <italic>before writing another part with an input/output test.</italic> If he gets an unexpected result, he knows that <italic>this part</italic> must be corrected (TiA). If he does not get an unexpected result for any of the inputs, he infers that <italic>the part</italic> is correct (TiA). <italic>When Jim has combined validated parts (information gathering), he anticipates a mistake in each combination and similarly conducts input/output tests for the combinations. When Jim believes he has finished this incremental validation (information gathering), he tests the complete program by conducting input/output tests (RoA), including for potentially problematic cases, as he still anticipates mistakes. If he does not get an unexpected result for any of the inputs, he then infers that the whole program is correct (TiA). However, if he is unable to determine cases for which he knows the results, Jim instead combines input/output tests for which he knows the result based on mathematical properties (RoA). This is governed by his belief that a mathematical property must be carried over into the programmed mathematics (TiA)</italic></p></td></tr></tbody></table>

He applied the same scheme to project 3 but could not completely adapt to the situation, probably because of the graphical nature of the output, new to project 3:I think really the biggest problem was figuring out ways, um, in the middle of the program to test that it was actually working properly ... some of the things with the code were kind of unintuitive on how to actually test them and you wouldn't really know some things. (Jim.EO3.16)

Due to length limitation, we cannot develop here more of the evidence but end with Jim's operational invariants in his own words:All the individual parts are working, the final thing is working, the final thing looks like what it should be, so therefore it, I can assume it's working. (Jim.EO3.24)

Discussion and implications

Our research question was:How does the instrumental approach, enriched by a model of scheme evolution, capture how students learn to use programming for authentic mathematical investigations?

In this section, we firstly present our answers to this question in the case of Jim and then we consider answers going beyond this case. We also discuss more generally the contribution of this study, for research and for education, and propose perspectives for further research.

Instrumental geneses and scheme evolutions: the case of Jim

In the case of Jim, we claim that he developed an instrument from the programming language (and integrated development environment), for the general goal "conduct a mathematical investigation." Describing this single instrument with that general goal would prevent us from accessing precise features of his learning process. As stated by Rabardel ([34]), the subjects develop systems of instruments where several goals (and subgoals) and thus several schemes intervene. Thus, in this context (learning to use programming for mathematical investigations), students develop a complex web of schemes (Gueudet et al., [19]). The structure of this web of schemes is linked with the structure of the dp-model.

For Jim we gave the examples of two schemes: "articulating a mathematical process in the programming language" and "validating the programmed mathematics." We observed that Jim developed strong links between these two schemes, in particular during the evolution of the "Validating" scheme. When the mathematics became more elaborated, Jim alternated phases of articulating the mathematical process and validating the programmed mathematics; this back and forth movement is represented in the dp-model by the arrows between steps 3 and 4.

According to Vergnaud ([41]), a scheme is the invariant organization of activity for a certain class of situations; at the same time, the components of a scheme should offer the possibility of adaptation to the specific features of each situation. Analyzing data collected in Jim's case, we identified elements of the invariant organization of his activity; these elements do not depend on the mathematical content. We also presented elements of the scheme which allow its adaptation to particular situations, and how the scheme is actually adapted, in particular for specific mathematical contents. For example, for "validating the programmed mathematics," the invariant organization comprises the choice of cases for which Jim knows the result and the comparison of the output of the program with the expected result. In the particular situation "validating the programmed mathematics for the RSA encryption," he uses the specific mathematical properties of the situation. The program should allow to un-code the coded message and find the original message; this is an adaptation of the scheme for this particular situation, linked with the mathematical principle for the RSA encryption. Moreover, he tests his program with possibly problematic cases. The choice of these cases also comes from the mathematical properties of the situation. Studying (p + m) schemes for Jim, we captured how his mathematical knowledge and programming knowledge were combined.

Also, enriching the instrumental approach with the model of scheme evolutions (Coulet, [15]), we observed evolutions of schemes developed by Jim when he faced "big programming projects." In the context of these projects, the feedback coming from the task led to evolutions of Jim's scheme. Following Coulet's model, we distinguished between "short loops" (e.g., "trying to have a picture of the whole program structure before programing" evolved to "trying to have a picture of a part or the whole of his program structure") and "long loops" (e.g., "In a long program it is difficult to identify where a mistake is" was a new theorem-in-action).

Instrumental approach, scheme evolution, and analyses about the learning of programming

Beyond the case of Jim, we claim that our analyses illustrate the relevance of the instrumental approach, particularly its concept of instrumented scheme for understanding the activity of students learning to use programming in the context of mathematical investigation. The concept of scheme is linked in Vergnaud's ([41]) work with the distinction between the operational form of knowledge (action in the physical and social world) and the predicative form of knowledge (linguistic and symbolic expressions of this knowledge). Both kinds of knowledge are essential for understanding students' activity. We claim that although most research in mathematics education at the university level is focused on the predicative form of knowledge, in the context of programming for mathematical investigation, we need to understand also the operational form of knowledge (e.g., "Decompose the nested system in individual processes before programming" is identified through the analysis of Jim's description of his activity).

Moreover, in this context, an important issue for research is to understand how the programming knowledge and the mathematical knowledge are combined. Geraniou and Jankvist ([18]) use the instrumental approach to bridge mathematical and digital competencies and propose a definition of "mathematical digital competency." Our study aligns with this perspective (with a focus on programming); the instrumental approach allowed us to bridge mathematical and programming knowledge, in particular through the identification of what we called the (p + m)-schemes, whose goal associates mathematics and programming. In such schemes, we observed that the inferences provide a reasoning where the mathematical and programming knowledge are intricate. For example, for the validation in project 1, Jim chooses simple cases and calculates by hand. For E02, he is not able to calculate by hand, but he knows that he can encode and then decode a message and should find the original message.

In this study, we identified schemes as invariant organizations of the activity for a given class of situations, incorporating also possibilities for adaptation to the specific features of situations within the same class. We analyzed how a scheme can be adapted to particular situations, through inferences in particular. This can be considered as a "classical" use of the instrumental approach; nevertheless, according to our readings, in the research literature, detailed descriptions of schemes are scarce. We also proposed to enrich the instrumental approach by using a model of scheme evolution (Coulet, [15]). Using this model in the case of Jim, we observed that indeed for some situations, the feedback leads to changes in the scheme that go beyond adaptations. Sometimes these changes only impact the rules generating sequences of action, within a short regulation loop. Sometimes the changes also impact the operational invariants, in a long regulation loop. Interestingly, we noted that in the case of a long loop, all the components of the scheme change, except for the goal. A long loop also produces new subgoals, anticipations, rules, and inferences.

Contributions for research and education and perspectives.

The productive and constructive aspects of the activity are closely linked. As illustrated by the case of Jim, depending on the features of the situation, sometimes he mobilizes an existing scheme and adapts to the particular features of the situation (productive activity). On other occasions, the feedbacks evidence that the adaptation is not sufficient, and this leads to changes in the operational invariants and rules of action, or even to the development of a new scheme (constructive activity). Integrating the model of scheme evolution in the instrumental approach deepens our understanding of learning processes with this perspective. We invite colleagues working with the instrumental approach to use it and to investigate its potential contribution.

This theoretical contribution is associated with a specific method. The data (here descriptions provided by Jim) are coded to identify the different elements of a scheme. This is done for several situations (see Appendix 2). This coding allowed us to observe the emergence and stabilization of new rules of action, new operational invariants, or new goals. This method could be improved and refined in particular by recording the student's actual activity; in the present study, the link with Jim's actual activity was only possible through his completed assignments, which is clearly a limitation. In our future research, we may combine interview data and direct observations more systematically.

The theoretical contribution proposed in this paper focused on the different components of schemes, on their relations and evolutions, in particular on the operational invariants and on how they pilot rules-of-action (operational knowledge, in Vergnaud's terms). While our aim here was not to study whether operational invariants in (p + m)-schemes are linked with computational thinking, mathematical thinking, or both, many interesting works address this difference (e.g., Knuth, [21]; Rogalski, [38]), and it constitutes a promising perspective for our future work.

The results obtained with this new theoretical and methodological contribution can also be informative for university instructors. With a perspective on learning as evolution of schemes, an essential component of teaching is the design of situations in which the adaptation of existing schemes is not sufficient and hence fosters short loops, long loops, and the development of new schemes. Identifying the features of such situations can lead to recommendations for university instructors.

Another limitation of the study presented here, as mentioned earlier, is that we followed a single student, Jim. Nevertheless we hypothesize that some of Jim's operational invariants are shared with many students (e.g., "To program a nested mathematics process, one can break it down and individually code the smaller parts"; "If the output is correct for a possibly problematic case, the program is likely to be valid"). Analyzing other data and trying to observe the presence of these operational invariants for other students is one of our directions for further research. As Rabardel ([34]) notes, a subject learns by developing individual schemes, but also by adopting social schemes. In the context we study, these social schemes are not explicitly presented (to the instructors or to the students). Nevertheless, we claim that "implicit social schemes" exist and could be identified through the analysis and confrontation of several individuals' schemes and presented to teachers. In our ongoing research (e.g., Buteau et al., [13]), we study how teachers orchestrate (Trouche, [40]) the students' instrumental genesis when they use programming for a mathematical investigation. This could contribute to the development of relevant teachers' practices in this context.

Acknowledgements

This work is funded by the Social Sciences and Humanities Research Council of Canada (#435-2017-0367) and has received ethics clearance from the Research Ethics Board at Brock University (REB #17-088). We thank all of the research assistants involved in our project for their valuable work toward our research, in particular Kirstin Dreise who significantly contributed by creating Jim's Excel table of schemes.

Appendix 1 Interview question template for MICA projects (i.e., programming-based pure or app...

Graph

Appendix 2 Tool developed and used for the analysis of Jim's mobilization and evolution of sc...

Figure 4 presents a table illustrating the process used to analyze Jim's schemes throughout his MICA I experience. It is a screenshot of the "articulating" scheme (goal in the green column A) and its rules-of-action, concepts-in-action, and theorems-in-action components (green column E) after Jim's first labs, its evolution (green column G) during project 1, and then its mobilization (empty green columns I, K, M, O, Q) in his subsequent labs and projects, progressing in time (along MICA I course activities) from column C to R. These were interpreted from evidence in Jim's data of rules-of-action (blue cells in columns H, L, P) and operational invariants (yellow cells in columns F, J) with their associated strategy and perception codes listed in column B in blue and yellow cells, respectively, used to identify scheme components and also from inferred evidence in Jim's data of scheme mobilization (dark green cell in columns N and R, with code in column B). Finally, columns C-D (pre-MICA I) are hidden as they were blank representing no evidence of the scheme.

Graph: Fig. 4 Analysis of Jim's scheme of "articulating a mathematical process in the programming language" throughout his MICA I experience

Electronic supplementary material

Below is the link to the electronic supplementary material.

Graph: Supplementary file1 (DOCX 530 KB)

Graph: Supplementary file2 (DOCX 90 KB)

Graph: Supplementary file3 (DOCX 188 KB)

Graph: Supplementary file4 (DOCX 17 KB)

Publisher's Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

By Ghislaine Gueudet; Chantal Buteau; Eric Muller; Joyce Mgombelo; Ana Isabel Sacristán and Marisol Santacruz Rodriguez

Reported by Author; Author; Author; Author; Author; Author