Harold Abelson , Harold Abelson. This Site. Google Scholar. Andrea diSessa Andrea diSessa. Publication date:. View More View Less. Cite Icon Cite. Series Foreword Doi:. Preface Doi:. Acknowledgments Doi:. Preliminary Notes Doi:. Hints and Answers. Hints for Selected Exercises Doi:. Answers to Selected Exercises Doi:. In the second trimester, we use a teacher-created program called Geometer -- see Figure 3.
This environment compares favorably with something like the Geometry Supposer, but is inferior to Cabri or Geometer's Sketchpad. Still, it helps to get many important and interesting ideas across, particularly in construction challenges, or to a lesser extent in the generation of conjectures. Once a construction has been achieved, it can be replayed over and over, with different initial points, or manipulated simply by dragging the initial points.
Typical assignments are: construction of tangent lines and circles in various situations; writing procedures to draw triangles given three sides SSS , two sides and the angle between them SAS , or two angles and the side between them ASA ; writing procedures to construct various quadrilaterals, and discussion of the number of inputs required, and which procedures can construct which figures. For example, the parallelogram procedure requires three inputs, and with appropriate values for these inputs, can be used to also draw a square, a rectangle, or a rhombus.
This reveals concretely the logical relationships between the figures. Geometer was programmed by a few people in their spare time, rather than by professional programmers over several years. The result was a nice chunk of the instructional functionality with a huge amount less programming effort. This is a big benefit if you believe like the creators of Boxer do that teachers and students need a wide variety of kinds of software rather than just a few applications.
Boxer can be used to develop useful learning tools for number theory, for probability and statistics, for physics, and so on. While each Boxer tool is inferior to a comparable commercial product, it is relatively easy to create and modify by the teacher , and it is completely programmable by the students. Once students know the basics of Boxer programming, they can write program in Geometer or in any of the other Boxer tools.
Theoretically, this can lead to a programming-centered, tool-rich culture in schools. Practically, we're not there yet, but I'd like to describe some glimpses I've had of such a culture.
Figure 3a: Commands can be used by double-clicking on them or by including them in procedures. Double-clicking can automatically build a written record of the construction see Figure 3b , which can be inspected, edited, saved, accessed and executed later. The boxed points a, b, c are the initial points, and can be dragged, in the style of much fancier dynamic geometry software. Figure 3b: Here is the construction that yielded the figure in 3a.
It was saved automatically by the program. The comments were added later. My best experience with the kind of synergy that is possible when programming meets mathematics was in a class called "Infinity".
In this ten-week course, we used Boxer to learn about iterating functions, and about self-similar fractal figures. There were other topics in the course, but I will only address the ones that involved Boxer.
A few students had used Logo in the past, but most had no prior experience with programming. The class consisted of two sophomores, a dozen juniors, and one senior. Only one sophomore and the senior could be considered to be top-track math students as measured for example by whether they took calculus in their senior year.
Among the rest, all had completed two years of high school algebra and took this class as their last math class. In short, most can be considered average college-bound students though one ended up not going to college, and another went to a community college. I dwell on the composition of the class because I was stunned by the high level of achievement in the two areas where Boxer was used.
After a brief introduction to Boxer, we investigated the iteration of functions by way of programming procedures that would build tables to show the value of the function after a given number of iterations. In other words, very early on, we tackled the sort of programming list manipulation which I was only able to introduce to tiny numbers of students in my Logo days.
Moreover, the mathematical payoff was enormous. We experimented with various functions in a way that clarified the meaning of composition, iteration, and recursion, and we compared algebraic methods to analyze those phenomena with computational ones.
This work made it possible to have an unusually effective introduction to mathematical induction. In particular, we used Boxer to experiment with the chaotic iteration of non-linear functions. The Iterating 2 x -2 problem originated at that time, but I worked on it long after the class was over. Later, students were introduced to basic turtle graphic commands, and to a series of templates of programs to generate self-similar figures.
Within a few weeks, all students without exception had created strikingly beautiful and complex fractals as their final project.
See Figure 4 for a few samples. In addition to the programs, students were expected to analyze the mathematics of the images they created, including its dimensionality and the total distance traveled by the turtle in creating the image. Again, this was a level of work I was only able to get out of very few in my Logo days: using recursive structures in programs had seemed to be only accessible to the very top students.
I could have used a ready-made fractal-generating program for this part of the course, though I am not sure it would have been possible to create figures like the ones in Figure 4 with that approach.
I could have used spreadsheets for the work on iteration. However, the students would not have nearly the depth of understanding they were able to gain by doing their own programming. Besides, the "overhead" that is the necessary component of learning any software starts to add up if you always use a different piece of software for each task.
Boxer made it possible to have a unified electronic environment throughout the course. Whatever interface quirk or programming construct was learned in one context was easy to transport to another, which contributed to substantial savings in overhead. Figure 4a : The same student-written fractal tree program, with different degrees of symmetry, and at different levels, produced all these images. Figure 5b: This student included her mathematical comments including the dimensionality of the fractal and the number of cross-shaped "voids" at level n in the boxes under the image.
Figure 5c: This complex and beautiful mathematical object was invented by a student in the Infinity class. Overall, it has three-fold symmetry, but upon close inspection, you will find four-, five-, and six-fold symmetries locally. The program that created it allows you to "zoom" into any of the local centers of symmetry, and create a full-sized representation of it.
The work we have done in Boxer in the past few years has been partially successful, as evidenced by the student work shown above. However, we have experienced a fair amount of frustration along the way, and cannot really claim total success. There has been much resistance to Boxer from many students. This can be partially explained by its early tendency to crash a lot, which caused students to lose much work through no fault of their own.
In addition, there were a number of weaknesses in the interface, which originated on UNIX workstations, and for a long time differed markedly from what students expected from their use with other software on the Macintoshes we have been using. As a result of student frustration, it has not been easy to "sell" it to my colleagues. Fortunately, Boxer is now more stable, and its interface much more Mac-like.
Another partial explanation of the difficulties we encountered is that many students come to the course with negative prejudices about programming. In our culture, the stereotype of the nerdy programmer is perhaps even more widespread and negative than the stereotype of the geeky mathematician. People never tire of saying that you don't need to understand electricity to turn on the light, and that similarly, you don't need to understand programming to use a computer.
This is of course true, but no one seems to object to teaching our students about electricity. The software industry, well aware of the cultural bias, tries to avoid even the word "programming" when addressing their customers.
For example, most fairly complicated applications allow the user to create "macros" or "scripts". Applications are programs, macros are programs, and scripts are programs --but the euphemisms reign. And yet, programming offers an extension of our brain in a way that qualifies it as a new level of literacy, with broad applicability to many fields.
There is power in understanding algorithms. The programmer's habits of mind breaking down large tasks into small ones; thinking about structure hierarchically and logically; seeking clarity in presentation and precision in language; and so on are useful in a wide range of human activity, especially mathematics.
Math education certainly has been transformed by access to programming. Heck, there would be no graphing calculators or dynamic geometry software without programmers! And in contemporary mathematical research, computers are used routinely in a very broad range of fields: number theory, topology, combinatorics, and so on. Programming is the most creative activity one can have at the computer, and it is wrong to reserve this for a tiny minority of our students.
There was a time when reading, writing, and arithmetic were not taught to all.
0コメント