15
This article was downloaded by: [Gazi University] On: 04 October 2014, At: 04:22 Publisher: Taylor & Francis Informa Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House, 37-41 Mortimer Street, London W1T 3JH, UK International Journal of Mathematical Education in Science and Technology Publication details, including instructions for authors and subscription information: http://www.tandfonline.com/loi/tmes20 Teaching teachers mathematics through programming J. B. H. du Boulay a a Department of Artificial Intelligence , University of Edinburgh , Forrest Hill, Edinburgh, Scotland Published online: 09 Jul 2006. To cite this article: J. B. H. du Boulay (1980) Teaching teachers mathematics through programming, International Journal of Mathematical Education in Science and Technology, 11:3, 347-360 To link to this article: http://dx.doi.org/10.1080/0020739800110306 PLEASE SCROLL DOWN FOR ARTICLE Taylor & Francis makes every effort to ensure the accuracy of all the information (the “Content”) contained in the publications on our platform. However, Taylor & Francis, our agents, and our licensors make no representations or warranties whatsoever as to the accuracy, completeness, or suitability for any purpose of the Content. Any opinions and views expressed in this publication are the opinions and views of the authors, and are not the views of or endorsed by Taylor & Francis. The accuracy of the Content should not be relied upon and should be independently verified with primary sources of information. Taylor and Francis shall not be liable for any losses, actions, claims, proceedings, demands, costs, expenses, damages, and other liabilities whatsoever or howsoever caused arising directly or indirectly in connection with, in relation to or arising out of the use of the Content. This article may be used for research, teaching, and private study purposes. Any substantial or systematic reproduction, redistribution, reselling, loan, sub-licensing, systematic supply, or distribution in any form to anyone is expressly forbidden. Terms & Conditions of access and use can be found at http://www.tandfonline.com/ page/terms-and-conditions

Teaching teachers mathematics through programming

  • Upload
    j-b-h

  • View
    214

  • Download
    0

Embed Size (px)

Citation preview

This article was downloaded by: [Gazi University]On: 04 October 2014, At: 04:22Publisher: Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954Registered office: Mortimer House, 37-41 Mortimer Street, London W1T 3JH, UK

International Journal ofMathematical Education in Scienceand TechnologyPublication details, including instructions for authors andsubscription information:http://www.tandfonline.com/loi/tmes20

Teaching teachers mathematicsthrough programmingJ. B. H. du Boulay aa Department of Artificial Intelligence , University ofEdinburgh , Forrest Hill, Edinburgh, ScotlandPublished online: 09 Jul 2006.

To cite this article: J. B. H. du Boulay (1980) Teaching teachers mathematics throughprogramming, International Journal of Mathematical Education in Science and Technology,11:3, 347-360

To link to this article: http://dx.doi.org/10.1080/0020739800110306

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the“Content”) contained in the publications on our platform. However, Taylor & Francis,our agents, and our licensors make no representations or warranties whatsoeveras to the accuracy, completeness, or suitability for any purpose of the Content. Anyopinions and views expressed in this publication are the opinions and views of theauthors, and are not the views of or endorsed by Taylor & Francis. The accuracyof the Content should not be relied upon and should be independently verifiedwith primary sources of information. Taylor and Francis shall not be liable for anylosses, actions, claims, proceedings, demands, costs, expenses, damages, and otherliabilities whatsoever or howsoever caused arising directly or indirectly in connectionwith, in relation to or arising out of the use of the Content.

This article may be used for research, teaching, and private study purposes. Anysubstantial or systematic reproduction, redistribution, reselling, loan, sub-licensing,systematic supply, or distribution in any form to anyone is expressly forbidden.Terms & Conditions of access and use can be found at http://www.tandfonline.com/page/terms-and-conditions

INT. J. MATH. EDUC. SCI. TECHNOL., 1980, VOL. 11, XO. 3, 347-360

Teaching teachers mathematics through programming

by J. B. H. du BOULAY

Department of Artificial Intelligence, University of Edinburgh,Forrest Hill, Edinburgh, Scotland

(Received 4 June 1979)

There are two main arguments underlying the claims for the value ofinteractive computer programming used by students to model mathematicalideas. One is concerned with mathematical content, i.e. with mathematics as anobject of study. The other is concerned with mathematical activity, i.e. doingmathematics, or 'Mathematicking' [1]. Both content and activity includeprocesses and these provide the main links with programming. Examples ofprocesses in the content of mathematics are addition, transformation andintegration, and these can be described by instructions in a computer program.Examples of process in the activity are problem-solving, proof generation andpattern finding which can be described by analogy to program building anddebugging. We assess the arguments for programming, in relation to the trainingof teachers, and describe a pilot-study in which student teachers with mathema-tical difficulties were taught the programming language LOGO. Observation ofthe students, learning the language and using it to manipulate computer modelsof mathematical ideas, which they had not understood previously, highlightsboth advantages and disadvantages in this approach. The problem of therepresentation of mathematical ideas within programming projects is discussed.

1. IntroductionSeveral studies [2,3,4] indicate that student teachers score badly in written

mathematics tests even after taking mathematics courses in Colleges of Education.These studies all point to students' difficulty with number concepts. Attitude testsshow that Colleges have varying degrees of success in getting students to enjoymathematics [5,6]. Lumb's study [4] demonstrates that even student teachers with'O' level mathematics suffer from a variety of mathematical difficulties that would beexpected to have repercussions in the classroom. So merely raising the entryqualification to Colleges of Education without improvement of the courses may notdo much to improve the standard of mathematics teaching in primary schools.

Seymour Papert [7] has championed a novel approach to this problem. He arguesthat students will come to enjoy and understand mathematics through being taughthow to program a computer. In his view, programming helps students to understandboth specific topics from the conventional content of their courses, e.g. functions,and more elusive aspects of the underlying mathematical activity, e.g. problem-solving. Together with Feurzeig [8], Papert has developed a programming languagecalled LOGO and a computer-controlled drawing device, the 'Turtle', specificallyfor mathematics instruction.

Various attempts have been made to evaluate the effects of programming on theunderstanding of mathematical topics and on attitudes to mathematics. But clearcutresults have yet to emerge. Howe and O'Shea [9] describe how primary schoolchildren showed marked gains in self-confidence and became much keener to enter

0020-739X/8O/1103 0347 $02-00 t 1980 Taylor & Francis Ltd

Dow

nloa

ded

by [

Gaz

i Uni

vers

ity]

at 0

4:22

04

Oct

ober

201

4

348 J. B. H. du Boulay

into mathematical debate with their teachers as a result of taking a LOGOprogramming-based mathematics course. Feurzeig et al. [8] taught arithmetic andalgebra to 13-year-old children using LOGO. The children's teachers and invitedobservers were enthusiastic, but the children's test scores (Iowa Test of BasicAbilities) were no better than those of the control group. Milner [10] taught childrenLOGO programming and found that it increased the children's scores in anunstandardized test of variables. Bjork [11] found that programming in BASICimproved numerical ability, especially among the less able. All these studies describethe enthusiasm and increase in motivation generated by the programminginnovation.

Previous studies of how student teachers react to, and benefit from,programming-based mathematics courses have not studied the interaction betweenthe students and the computer closely. In Quebec, nearly five hundred students,destined to become mathematics teachers, have been taught LOGO programming aspart of their course. Students' responses to an evaluative questionnaire [12]indicated that they believed their problem-solving to have been improved, thoughthis belief was not put to the test. Statz [13] taught problem-solving, based onLOGO programming, to teachers in a summer school and found that by the endabout 60 per cent of the participants were able to outline a model of problem-solvingderived from their programming experience. But, as in the Quebec experiment, nomeasures were made of the teachers' ability to apply this model.

Elliott [14] taught an APL programming-based course and found that thisimproved student teachers' attitudes to mathematics and increased their scores in anunstandardized mathematics test about number systems.

So there is a lack of data on student teachers' ability to program and on the designof suitable programming projects. None of the above studies was concerned withstudents' mathematical difficulties and none was designed to provide remedial helpthrough programming.

2. The pilot studyIn order to get some feel for the practical advantages and disadvantages of the

programming approach for student teachers, the author conducted a small pilotstudy [15]. Fifteen volunteers with minimum mathematical qualifications and self-confessed difficulties with mathematics were recruited from a local College ofEducation. These students were taking a three-year Diploma to qualify as primaryschool teachers. They were taught the language LOGO and they used it to exploresome of their difficulties as welt as areas of mathematics new to them. Theirdifficulties were revealed by a test [16], by observation of the students duringteaching practice and by interview. .The objectives of the study were to discover thestudents' mathematical difficulties, to chart their progress in learning LOGO and toobserve the effects of the programming on their mathematics. Detailed case studiesof three of the students were made using complete records of their work at theterminals including tape-recordings of all tutorial conversations.

3. Mathematical difficultiesStudents in the pilot study took Rees' test [16] and incorrectly answered much

the same 'common core' of difficult questions as her subjects had done. Thesequestions included sums involving fractions, decimals, squares and square roots.Their errors and omissions were unfortunate given that they were to become

Dow

nloa

ded

by [

Gaz

i Uni

vers

ity]

at 0

4:22

04

Oct

ober

201

4

Teaching teachers mathematics 349

teachers, though their scores were about the same as Rees' sample of student teachers[2]..But observation of the students while teaching, and interviews with them,revealed many mathematical difficulties not detectable in this kind of test. Thesedifficulties had consequences just as serious for their teaching and were concernedwith the students' understanding of, and ability to describe, basic mathematicalideas, rather than their ability to do calculations or solve mathematical problems.The students were often unable to justify and explain the mathematical rules thatthey taught and knew how to apply. They also had difficulty in expressingmathematical ideas clearly in English.

The central difficulty was that the students had learned parts of their ownmathematics 'instrumentally' and this severely limited their ability to teach theirown pupils 'relationally' [17]. This was a clear case of Rees' 'learning-teaching-learning cycle' [18]. Many of the observed difficulties are commonplace: why doesthe rule about dividing fractions work? Why does one add decimal places whenmultiplying decimal numbers? Why are there two scales on a protractor, and howdoes one decide which one to use? Some of the unclear expression of mathematicalideas are more unusual. For example, one student persistently substituted phrases ofthe type 'ten from eight' for 'eight from ten' in her classroom questioning. She didnot notice this even when the tape of the lesson was played back. When the authorpointed it out to her, she explained her mistake in terms of the following literaltranslation between arithmetic notation and English:

10-8

ten from eight

Here the minus sign is translated directly into 'from' without regard for theorder of the arguments. (Lumb [4] noticed that 1 % of the students he tested thoughtthat 7 — 2 = 2 — 7 even after their mathematics course.)

In some cases the student caused confusion because she misunderstood themathematical idea she was trying to put across. The following typical example isfrom a lesson on the division of whole numbers. A division sum, such as 17/3, can beused in two different applications. In one (partition), a set of 17 objects is to bepartitioned into subsets of 3 objects, giving 5 subsets in all and 2 objects over. In theother application (quotition), 17 objects are to be shared among 3 people, giving 5objects each and 2 over. In the first case, the child finds the answer by counting thenumber of subsets produced by the partitioning. In the second case, he must countthe number of objects produced by the sharing. The student teacher mixed up thesetwo applications by starting with an explanation based on partitioning and thencontinuing with phrases and activities based on sharing and finally summing upusing partitioning. The pupils had counters in front of them in order to illustrate thesum. The student's muddled instructions caused some pupils to answer that 5/3 = 3because they had counted subsets instead of objects, having shared out the counters.

Another student observed and worried about her pupils' apparently randomchoice of protractor scale when measuring angles. In the course of her description ofthe problem, it emerged that she was just as uncertain as they were about which scaleto use. Her own strategy was to guess the size of the angle and then use the scale thatgave the most sensible answer. This method could not be used by the childrenbecause they were still learning the relation between the 'shape' of an angle and itsnumerical size in degrees.

Dow

nloa

ded

by [

Gaz

i Uni

vers

ity]

at 0

4:22

04

Oct

ober

201

4

350 J. B. H. du Boulay

The student teachers knew that they had difficulties with mathematics (that iswhy they had volunteered for the study), although they were often uncertain abouttheir nature, as in the examples above. Awareness of their lack of ability sapped theirself-confidence so that some of them doubted their grasp of topics which they clearlydid understand. This lack of confidence caused one student to over-prepare herlessons to the extent that unexpected events completely disrupted her plans and lefther unable to continue sensibly.

Another student was convinced that she could not judge distances, and presentedthis as firm evidence of her mathematical incompetence. In fact, she was able tojudge distances perfectly well by reference to the known dimensions of her ownsitting-room, which she could visualize. But she felt that this personal yardstick wastoo idiosyncratic and that proper mathematicians had some other method of doingthe task. It turned out that it was not her competence at judging distance that worriedher but her use of a personal method unrelated to textbook mathematics.

Very often mathematics lessons were a trial in that students realized the disparitybetween their belief in 'teaching for understanding' and their ability so to do. Somealso dreaded being found out by a child's question or difficulty, as the followingquotation from a student illustrates:

"Usually I'm absolutely terrified whenever any of the children in the schoolasked me about angles. Because I would just have to go away and really thinkabout it. If they want an answer right there and then, I usually had to fob themoff with something else."

4. Learning to programReactions to learning LOGO programming were very mixed. Most students said

that they enjoyed the experience and observation of their work at the terminalshowed that they increased their understanding of the mathematical topics tackled.One student found programming confusing and just as unpleasant as the mathe-matics it was supposed to help. Students were put through a programmingapprenticeship before dealing directly with mathematical issues. Some studentsfound this disconcerting, even though they enjoyed learning to program, because theactivity seemed to have little to do with their mathematical difficulties or with theirfuture careers.

Programming was complex to learn and demanded an appreciable effort on thepart of the students. In fact the computer compared badly with other mathematicalapparatus which is generally very easy to manipulate. This was a serious drawbackespecially considering the students' mathematical difficulties. Particular program-ming difficulties will not be described in detail here. The interested reader is referredto du Boulay [15] for a full discussion of the problems the students faced in learningLOGO.

5. Programming and mathematicsThe students undertook programming projects determined by their mathema-

tical difficulties. Some difficulties emerged through classroom observations, otherswere reported by the students or had arisen during their College of Educationmathematics course. The main purpose of these projects was to use the program-ming language and the computer's ability to draw pictures to provide visualillustrations of basic mathematical ideas. For example, one student used a program

Dow

nloa

ded

by [

Gaz

i Uni

vers

ity]

at 0

4:22

04

Oct

ober

201

4

Teaching teachers mathematics 351

which illustrated multiplication and division of fractions as ratios for changing thedimensions of a picture on a display screen.

The projects differed a lot in the amount of coding that was undertaken by thestudents. As the study progressed, the amount of coding in projects was generallyreduced since it was found that, in some cases, programming issues were divertingattention from mathematical issues.

Before describing a number of projects in detail, a brief description of theprogramming facilities will be given. The students learned to write two differentkinds of program in LOGO: one concerned with drawing, and the other concernedwith symbol manipulation. This was not always a hard and fast distinction becausesome programs did both.

5.1. Drawing programsThe most visually appealing part of LOGO for the students (and the part that

originally motivated the author) was Papert's Turtle Geometry [19]. This is thestudy of that class of plane figures produced by a small computer-controlled andmotorized cart with an attached pen. The cart, called a Turtle because of its shape,responds to commands either to move FORWARD or BACKWARD in thedirection it is currently facing, or to rotate LEFT wards or RIGHTwards on thespot. For example, figure 1 shows a LOGO program consisting of a sequence ofcommands to draw a regular hexagon. Notice that the rotations correspond to theexterior angles of the hexagon.

DEFINE "HEXAGONFORWARD 100LEFT 60FORWARD 100LEFT 60FORWARD 100LEFT 60FORWARD 100LEFT 60FORWARD 100LEFT 60FORWARD 100LEFT 60END

6O"

Figure 1. Hexagon.

The edges of the hexagon are arrowed in the figure to show the direction of motion ofthe Turtle.

Even such simple programs were not always written correctly the first time, andthe computer often produced unintended pictures when the students made mistakesover their angles or distances. But students were usually determined to make thecomputer do the right thing and debugged their programs until they workedproperly. Success in completing a drawing gave students a great deal of pleasure,though one of them reported, rather ruefully, her father's comments on a simplepicture produced after much labour.

"My dad sort of looked at it [the picture] and then looked at the long piece ofpaper [the reworked instructions]. 'My God', he said 'you doing all that just for

Dow

nloa

ded

by [

Gaz

i Uni

vers

ity]

at 0

4:22

04

Oct

ober

201

4

352 J. B. H. du Boulay

DEFINE "STARFORWARD 100LEFT 144FORWARD 100LEFT 144FORWARD 100LEFT 144FORWARD 100LEFT 144FORWARD 100LEFT 144END

Figure 2. Star pentagon.

that wee thing.' You know they think it's all simple. But it's not really simple, notto work out how to get it. I don't think it's simple."

One student became intrigued by drawing such polygons and was able to use theactivity to derive and explain various angle properties of regular polygons, such asthe relation between the number of vertices and the total interior angle. She extendedher analysis to star polygons, which were drawn by programs similar to that for thehexagon, see figure 2.

The student continued by considering the symmetry properties of regularpolygons and was able to make what for her were genuine mathematical discoveries,such as the relation between the exterior angle of the polygon and its rotationalsymmetry. In this case the computer functioned as a laboratory, as Papert hasargued, where her hypotheses were instantiated as simple programs and then tested.This was very enjoyable for the student and it gave her a strong sense of havingachieved something of personal mathematical worth through her own effort.

5.2. Symbol manipulation programsAs well as including instructions for drawing pictures, LOGO also contains

instructions for manipulating symbols. The language provides three data-types:integers, words and lists. One project asked students to write a series of programs tomanipulate fractions. Fractions were expressed as lists of two elements, e.g. 3/4became [3 4]. The program to add fractions, called FRACADD took two suchfractions as arguments and returned their sum as its result.

PRINT FRACADD [1 3] [1 2][5 6]

This project involved the student in instructing the computer what to do with thenumerators (the first element of each list) and the denominators (the second elementof each list). Certain parts of this particular project, such as the program to reduce afraction to its lowest terms, proved extremely difficult given the partially developedprogramming skills of the students. But the attempt to write such a program forcedthe students to make their own cancelling algorithms explicit and this was beneficial.One student realized the importance of prime numbers in this task. But a great dealof her effort was devoted to overcoming programming problems and this distractedher from the mathematical issues.

Dow

nloa

ded

by [

Gaz

i Uni

vers

ity]

at 0

4:22

04

Oct

ober

201

4

Teaching teachers mathematics 353

6. Level of representationThe most difficult problem in designing programming tasks was to devise

projects which effectively illustrated the desired mathematical idea, without toomany confusing programming details. Two methods of tackling this problem wereemployed. Firstly, projects which demanded programs of any complexity wereabandoned. The loss of practice in debugging and program planning was com-pensated by the increased focus on immediate mathematical issues. As much use aspossible was made of programs consisting of only a few instructions. For example,the drawing instructions FORWARD and BACKWARD were used to modelintegers. That is +100 was represented as FORWARD 100 and - 1 0 0 becameBACKWARD 100. By this means, students were able to model arithmeticexpressions, consisting of operations on integers, in terms of simple sequences ofdrawing instructions that moved the Turtle. The computer played the role of alaboratory, as in Turtle Geometry; but in this case it was an integer laboratory.

Simple programs also helped to flesh out what was otherwise meaninglessnotation for the students. Thus the puzzling expression, 'the mapping^' on the realnumbers denned by j : x-*l/x' was turned into a LOGO program to do the mappingwhich consisted of three lines of code.

DEFINE "J "XRESULT DIVIDE 1 VALUE "XEND

In this particular case the student did not have to run the program. Merelyreformulating the mapping in the more familiar (to her) LOGO instructions enabledher to see what a mapping was and what it did. As in the integer project, once theprogram had been used to help understand the idea, it was abandoned in favour ofconventional mathematical notation. The program provided a convenient jumping-off point.

The second way in which the programming was kept simple was by enhancingthe programming language with new instructions. These were implemented inLOGO and conformed to the same syntactic rules as the rest of the language. Theobjective was to devise small sets of instructions that could form a simplesub-language for the exploration of a particular domain. This is similar to the way thatthe instructions FORWARD, BACKWARD, LEFT and R I G H T enable TurtleGeometry to be explored. The LOGO teaching sequences developed by Lukas et al.[20] gave examples of how students could undertake this development forthemselves. Such a process proved too complex and too time consuming for thestudents in the present study.

One example of such a system, implemented by the author, consisted of a series ofprograms that enabled the symmetry transformations of the rectangle to be studiedby experiment. A transformation corresponded to an action carried out by thecomputer in response to a student's command, and a state corresponded to theresultant picture of the rectangle drawn on a display screen. This exemplified thedistinction between a state and a transformation that had been troubling some of thestudents.

The students' task was to observe the effect of a single transformation, or asequence of transformations on the displayed rectangle. By this means they were ableto discover relationships among the transformations. This method had the

Dow

nloa

ded

by [

Gaz

i Uni

vers

ity]

at 0

4:22

04

Oct

ober

201

4

354 J. B. H. du Boulay

advantage over the conventional use of a cardboard rectangle that the computerexecuted the transformations correctly and so the students could concentrate on therelations between the transformations rather than on carrying them out themselves.

Asking the students to implement these programs for themselves in LOGOwould have presented the problem at the wrong level of detail, since most of thecoding concerned the internal storage of the transformations and their subsequentdepiction on the screen, and not their underlying mathematical properties. This islike the distinction between computing with Dienes Multibase Arithmetic Blocksand sawing up the wood to make the blocks. Undoubtedly, measuring and cuttingthe wood are useful things to do but they do not teach about place value.

Another suite of programs illustrated the multiplication and division of fractions.This implemented fractions as operators, used to transform the size of a picturedisplayed on a screen in the ratio given by the fraction. The new picture, of changedsize, could itself be transformed by inputting another fraction, and so on. This gaveone student her first concrete example of equivalent fractions, i.e. those fractions thatproduced the same change in size of the picture. The program also allowed her toexplore visually such ideas as inverse, multiplication and division of fractions. Thisprovided some meaning for that puzzling rule about 'turning upside down andmultiplying'.

The pictures drawn on the screen consisted of a simple house outline. Thesepictures were used in the accompanying worksheets to develop an iconic represen-tation of fraction operations. So multiplication of fractions was illustrated as in figure3 which shows the multiplication of 3/4 by 2/1. Division of fractions was presented asthe inverse of multiplication. The question of 2/3 divided by 1/4 became the questionof what multiplied by 1/4 would produce 2/3 (see figure 4).

This program helped the student who used it to relate division of fractions toother ideas rather than just remembering it as a rule without reasons.

By contrast, a less successful project invited students to write programs to drawrepresentations of fractions as pie diagrams on a display screen (see figure 5). Herethe difficulty was that the dominant issue for the students was how to design theprogram to draw the representation and this had little to do with the underlyingproperties of fractions, which were the point of the project.

Figure 3. 3/4x2/1.

Dow

nloa

ded

by [

Gaz

i Uni

vers

ity]

at 0

4:22

04

Oct

ober

201

4

Teaching teachers mathematics 355

Figure 5. Fraction pie diagrams.

7. Advantages and disadvantagesThe overall advantages and disadvantages of the programming work are

summarized in table 1.

Advantages

Emphasizes importance of explicitlanguage.

Certain key concepts are well illustratede.g. function, algorithm, angle, state andtransformation.

Splendid opportunities for problem-solving are available.

Disadvantages

But can cause frustration because getting asolution to a problem can take a long time.

But it is not easy to design programmingprojects which address the mathematicaldifficulties of the students at the right levelof representation.

But ease of access to the machine en-courages trial and error methods ratherthan systematic analysis of a problem.

Table 1. Advantages and disadvantages of learning mathematics through programming.

The last disadvantage in the table, the use of trial and error methods, is really aproperty of the teaching and an experimental approach to mathematics rather thanbeing specifically related to programming. There was a tendency for the students tosolve problems by small incremental steps rather than by following an overall plan.This meant that, once a program had been successfully completed or abandoned,there was little incentive on the students' part to look at the program as a whole inorder tq analyse how and why it had worked or failed. The emphasis in many projectsshifted from the initial mathematical problem to the programming problem but didnot shift back again.

This disadvantage can probably be reduced by a change in teaching method thatplaces more emphasis on planning. In this connection, Dienes [21] describesstrategies for helping students progress from free play with structured apparatus toproving theorems in the mathematical system embodied by the apparatus.

8. Mathematical contentPrograms and programming constructs can be embodiments of mathematical

ideas, e.g. functions, variables and algorithms. Thus a set of instructions in aprogramming language for illustrating fraction operations visually can be used asmanipulable objects, providing a concrete embodiment for mathematical ex-perimentation in the same manner as other structured apparatus. In an interactivelanguage such as LOGO, the reactive nature of the computer plays a similar role tothe visual and tactile feedback from the apparatus. It provides information about theproperties of, and relations between, the objects under investigation.

A student's comments given an indication of the effects of this kind of work.

"I can sort of visualize an angle . . . but before it was dreadful."''If I hadn't done this [work with fraction programs] and some child had asked

Dow

nloa

ded

by [

Gaz

i Uni

vers

ity]

at 0

4:22

04

Oct

ober

201

4

356 J. B. H. du Boulay

me . . . I wouldn't of . . . aha, I would say it's just a rule.""I know what it means now [equivalence of fractions] because I was never reallyclear exactly before."

For some ideas the computer has an advantage over other materials in that it canmodel and illustrate processes. Thus a programming language, by providingprimitives to display geometric transformations on a screen, enables students toexplore the effects of individual combinations of transformations.

Sometimes the action is purely symbolic, e.g. the program to do mappings. Thisenabled the student to find out what mappings are by describing in a program whatthey do. But the programs have to remain simple enough for an inspection of theircode, by an inexperienced student programmer, to reveal their action. This may wellbe a disadvantage for the elegant and concise APL notation compared to the morelong-winded LOGO equivalent.

9. Mathematical activityThe idea that mathematics could be an enjoyable activity, that students could

make personal discoveries through their own efforts and that they could pose andsolve problems for themselves emerged clearly in the study. Student teachers oughtto have personal experience of activity-based, individual, exploratory mathematicalwork if they are to appreciate its strengths (and weaknesses) for their own pupils. Astudent's comments make the point.

" . . . it's something new for us as learning maths is for a child. Many problemswill be similar. But I came to LOGO with a dread of maths. That probablycolours what I do—hopefully a child wouldn't feel like this."

and •

" . . . I think obviously you can appreciate a child's difficulty because when youcome up against something here and it's really hard and you've got to work awayat it . . . and we find it hard, what must it be like for a child?"

Programming, even at the simple level described here, has a special role to play inthe case of student teachers in mathematical difficulty. Working with the computer isa compelling experience. Students want to make it act according to their wishes. Thestudents' tutor can thus easily take on a supportive, advisory role helping them todeal with the computer's 'shortcomings', rather than lecturing them as the expertand reinforcing their sense of failure in the face of his expertise. As one studentcommented:

"Now especially this achievement, that was good, you know, em, where I couldfind my own mistake and where I could correct it."

Another strand in the activity argument concerns explicitness. Feurzeig et al. [8]argue that many people do not understand the need for the rigour demanded inmathematical expression. It is not seen as a method of reducing ambiguity. Butcomputers have to be instructed in a formal language and students accepted the valueof formality in this context. Here symbols had precise meanings and so the studentcould plan exactly what she wanted the computer to do and could interpret its actionsin relation to the instructions given. Writing a program forced the student to producean explicit description of the process to be carried out, which she could examine andtest at leisure. A student's comment illustrates this.

Dow

nloa

ded

by [

Gaz

i Uni

vers

ity]

at 0

4:22

04

Oct

ober

201

4

Teaching teachers mathematics 357

" . . . possibly because you have got to think about it so much, and I suppose a lotofitdoesgo in. Because you've got to .. .well like this bit here [the programmingwork in hand] you have to, like when I was doing it before, you know, I had tokeep going over it and over it again and you really had to puzzle out what, whenyou made mistakes. I find that helps a lot when remembering it . . . and I make alot of mistakes and I have really got to puzzle out where I've gone wrong andthen I '11 remember it better. I f I had done it perfectly the first time, it would havebeen in and out [of my head] in two seconds."

A second advantage of programming is that it highlights mistakes whereasworking conventionally, with paper and pencil, the student may unknowinglycommit all kinds of errors. This is because she must both specify the instructions andexecute them herself.

The content of some mathematical courses is being broadened by explicitlyincorporating what otherwise would be implicit aspects of mathematical activity, e.g.proof generation [22] and problem-solving [23]. Papert [19] argues that abstractproblem-solving heuristics, such as those described by Polya [24], are given vividillustration in the strategies for planning, writing and debugging computerprograms. The theory is that these general heuristics, developed through experienceof programming, can later be applied to strictly mathematical problems. Elliott [14]develops a similar argument about the transfer of such skills to mathematicsteaching, which she views as a kind of problem-solving. Notice that these argumentsdo not depend on the students solving mathematical problems, as such, in theirprogramming. They are concerned with the analogy between the activity ofprogramming itself and the activity of mathematics.

Elliott's argument is given some support by one student in the pilot study whobroke off suddenly from her programming, where she was trying to make sense of aLOGO error message, to announce:

"Do you know what I can see? When the child doesn't understand the teacherand the teacher doesn't understand the child, the frustration starts."

The best attempt to test Papert's theory in the classroom has been made by Statz[13], but with only marginal success. She developed a model of problem-solving,influenced by Polya [24], and related features in this model to specific programmingactivities. An example here is the decomposition of a complex problem into sub-problems. In LOGO, the language taught by Statz, this became the activity ofdefining a super-procedure in terms of sub-procedures. Statz taught childrenproblem-solving through programming and then tested them on four problems.Significant gains in score were found on two of the four tasks. One consisted of wordpuzzles involving anagrams and word classification. The other task asked children tofind permutations of three or four digits. But there are criticisms of the way sheassigned scores to the children's solutions [25], and her analysis of the relationshipbetween the skills needed to solve the problems and the skills practised inprogramming is open to question.

The students in the pilot study appreciated the value of heuristics such asproblem decomposition.

"I think that sometimes I can look at a problem and split it down into bits—before I tended to go headlong without really looking at a problem—greatdifficulties following!"

Dow

nloa

ded

by [

Gaz

i Uni

vers

ity]

at 0

4:22

04

Oct

ober

201

4

358 J. B. H. du Boulay

So if we concede that programming teaches heuristics such as problemdecomposition, and that the student may learn that these techniques ought to beapplied to solve mathematical problems, the student is still faced with the difficultyof knowing how to apply them in the domain of mathematics. As yet there is verylittle empirical evidence to support the claim that learning problem-solvingheuristics in programming increases mathematical problem-solving ability.

10. Choice of programming languageThe particular programming language chosen to teach mathematics will have a

crucial effect on the success of the enterprise. It will delineate the kind ofmathematics that can be done, and it will mould the form of the solutions found.LOGO has a lot to offer in this respect. Its drawing instructions are useful both forintroducing students to programming and for illustrating mathematical ideasvisually. The procedural nature of the language enables the student to write self-contained programs (procedures and functions) to carry out small tasks, and then usethese programs in just the same way as the standard instructions. But LOGO has itsdrawbacks. For example, the range of datatypes is restricted and this can make theexpression of some mathematical ideas clumsy. The reader is referred to Schmidt[26] for a discussion about programming languages suitable for teaching elementarymathematics.

Learning to program is a considerable task for student teachers. Students'difficulties may be reduced by changes both in programming languages and inteaching methods. Some approaches to this problem are described by du Boulay andO'Shea [27]. It is possible to reduce the amount of programming that has to bemastered and still leave scope for interesting amounts of mathematics to be tackled.This means that certain features have to be added to the language to allow the studentto write programs without having to do a lot of coding. One approach to this problemis to create a high-level language for the exploration of a particular mathematicalsystem, e.g. geometric transformations. Borning's Thinglab [28] implemented inthe language Smalltalk is an example of this approach.

11. Choice of programming taskProgramming can distort a course towards what is programmable and away from

what is mathematically important. This is because certain mathematical ideas, e.g.algorithms, are easy to illustrate, where others are much more difficult, e.g. a visualillustration of division of fractions. For example, it is very easy to implementnumber-manipulating algorithms on a computer. So there may be a tendency to havethe students program such algorithms, e.g. a method of computing primes orgreatest common divisors. This can be a justifiable activity if one is concerned thatthe student learn about algorithms as such, or as a device to teach those particularalgorithms, or as a means of demonstrating the underlying similarity of apparentlydifferent algorithms [29]. But programming an algorithm is hardly more likely togive insight into its meaning, range of application and implications than traditionalmethods of expression. This factor is especially important in the case of studentteachers. We have argued that many of the difficulties of student teachers are relatedto the meaning of algorithms rather than to recall of their component steps. Forexample, in the case of fractions, the students knew that 'turn upside-down andmultiply' was an algorithm for computing division, but they did not understandwhy. Nor did the students know how they might justify such a rule to their pupils,

Dow

nloa

ded

by [

Gaz

i Uni

vers

ity]

at 0

4:22

04

Oct

ober

201

4

Teaching teachers mathematics 359

except to say 'it's just a rule'. Merely writing a program to implement the fractiondivision algorithm will not help with this problem.

12. ConclusionIt proved possible to increase students' understanding of particular mathema-

tical ideas and to improve their attitudes to particular topics in mathematics. But thedeep-seated anxiety about the subject as a whole, expressed by some of the students,proved impossible to change. This is hardly surprising given their long previoushistory of mathematical failure. One student sadly commented that she had become:

" . . . slightly more confident, but I don't think anything could make be feelcompletely confident."

The study indicates a number of factors that influence the success or failure ofprogramming-based mathematics projects. It is very important that the main issuesfaced by the student in writing a program are mathematical. This implies that theprogram and the programming language must deal with the mathematical topic atthe appropriate level of representation. These factors are:

(a) Programs to be written by the student should be short and should deal withthe properties of the mathematical objects or processes under consideration,and not with accidental features of their representation within the chosenprogramming language.

(b) The language should be enhanced with new instructions (e.g. for carrying outtransformations) to achieve (a) above.

(c) Instructions that generate visual illustrations of mathematical ideas are veryuseful.

(d) Reworking algorithms in programming notation is not in itself a usefulactivity for student teachers to undertake.

AcknowledgmentsI thank Ken Johnson, Jim Howe, Tim O'Shea and Mike Sharpies who

commented on a draft of this paper. I am grateful to the Social Sciences ResearchCouncil for financial support.

References[1] MASON, J. H., and BAKER, J. E., 1977, Mathematicking: The Distinction Between Process

and Content (Faculty of Mathematics, Open University).[2] REES, R., 1974, Maths Sch., 3, 25.[3] HAYLOCK, D. W., 1977, Maths Sch., 6, 22.[4] LUMB, D., 1974, Maths Teaching, 68, 47.[5] LUMB, D., and CHILD, D., 1976, Educ. Stud., 2, 1.[6] RAY, S. P., 1975, Some Factors Affecting Recruitment to Main Mathematics Courses in a

College of Education, unpublished M.Ed. Thesis, University of Newcastle.[7] PAPERT, S., 1973, Uses of Technology to Enhance Education (Cambridge, Mass: Artificial

Intelligence Laboratory, Massachusetts Institute of Technology).[8] FEURZEIG, W., PAPERT, S., BLOOM, M., GRANT, R., and SOLOMON, C, 1969,

Programming Languages as a Conceptual Framework for Teaching Mathematics, Reportno. 1889 (Cambridge, Mass: Bolt, Beranek and Newman Inc.).

[9] HOWE, J. A. M., and O'SHEA, T., 1978, Computational Metaphors for Children, inHuman and Artificial Intelligence edited by F. Klix (Berlin: VEB Deutscher Verlag derWissenschaffen).

Dow

nloa

ded

by [

Gaz

i Uni

vers

ity]

at 0

4:22

04

Oct

ober

201

4

360 Teaching teachers mathematics

[10] MILNER, S., 1973, The effects of computer programming on performance, in mathe-matics, paper presented at American Education Research Association, ERIC reportsED 076 391.

[11] BJORK, L.-E., 1975, An introductory computer programming course and some of itseffects on the teaching of mathematics, Proceedings of the IFIP 2nd WorldConference, 'Computers in Education' edited by O. Lecarme, and R. Lewis(Amsterdam: North Holland).

[12] DANIEL, J. S., and VILLARDIER, L., 1976, Deuxieme Rapport d'Evaluation sur le CoursPermama Per 006 'Algorithmes et Progranimation' (University of Quebec, Tele-University).

[13] STATZ, J., 1973, Syracuse University LOGO Project: Final Report (New York: SyracuseUniversity).

[14] ELLIOTT, P. C , 1976, Int. J. Math. Educ. Sci. Technol., 7, 447.[15] DU BOULAY, J. B. H., 1978, Learning Primary Mathematics Through Computer

Programming, unpublished Ph.D. Thesis, Department of Artificial Intelligence,University of Edinburgh.

[16] REES, R., 1973, Mathematics in Further Education: Difficulties Experienced by Craft andTechnician Students (London:Hutchinson Educational).

[17] SKEMP, R. R., 1976, Maths Teaching, 11, 20.[18] REES, R., 1974, Times Educ. Suppl., 19/4/74, p. 63.[19] PAPERT, S., 1972, Int. J. Math. Educ. Sci. Technol., 3, 249.[20] LUKAS, G., FAFLICK, P., and FEURZEiG, W., 1971, LOGO Teaching Sequences, Reportno.

2165 (Cambridge, Mass: Bolt, Beranek and Newman Inc.).[21] DIENES, Z. P., 1973, The Six Stages in the Process of Learning Mathematics (Windsor:

NFER).[22] LAKATOS, I., 1976, Proofs and Refutations (Cambridge: Cambridge University Press).[23] MASON, J. H., 1978, Mathematics: A Psychological Perspective (Milton Keynes: Open

University Press).[24] POLYA, G., 1957, How to Solve It (New York: Doubleday Anchor Books).[25] WEYER, S. A., and CANNARA, A. B., 1975, Children Learning Computer Programming:

Experiments with Languages, Curricula and Programming Devices, Technical Report no.250 (Institute for Mathematical Studies in the Social Sciences, Stanford University,California).

[26] SCHMIDT, A., 1975, Simulative transfer of mathematical concepts by interactiveprogramming. Proceedings of the IFIP 2nd World Conference, Computers inEducation edited by O. Lecarme, and R. Lewis, (Amsterdam: North Holland).

[27] DU BOULAY, J. B. H., and O'SHEA, T., 1978, Seeing the works: a strategy for teachinginteractive programming. Proceedings of the Workshop on Computing Skills andAdaptive Systems, University of Liverpool.

[28] BORNING, A., 1977, Thinglab—an object-oriented system for building simulations usingconstraints, Proceedings of the Annual Joint Conference on Artificial Intelligence,Massachusetts Institute of Technology, Cambridge, Massachusetts.

[29] ELLIOTT, P. C, 1978, Int. J. Math. Educ. Sci. Technol., 9, 79.

Dow

nloa

ded

by [

Gaz

i Uni

vers

ity]

at 0

4:22

04

Oct

ober

201

4