Expressiveness and Abstraction with Computer Algebra Software Phillip Kent, Institute of Education, University of London
[email protected] http://pkent.homestead.com This invited talk was given in June 2000 at the meeting “Journées d'étude: Environnements informatiques de calcul symbolique et apprentissage des mathématiques”, Rennes, France Twenty years ago, Seymour Papert put forth a vision for how computer software could transform the learning of mathematics: The idea of ‘talking mathematics’ to a computer can be generalised to a view of learning mathematics in ‘Mathland’; that is to say, in a context which is to learning mathematics what living in France is to learning French*. (Papert 1980, page 6) When I first read this, in 1994, it connected very powerfully with my work at that time, which was developing new mathematics curriculum for undergraduate students based on the computer algebra system (CAS), Mathematica. Surely (I thought) a CAS is the closest one can get to “talking mathematics” with a computer? Was I standing on the borders of Mathland? Well, six years later I am still excited by Papert’s vision, but, of course, still a long distance from a realisation of Mathland. In this paper, I describe two curriculum developments undertaken by myself and colleagues at Imperial College in London (the METRIC project, i.e. Mathematics Education Technology Research at Imperial College). Through these two examples, I want to explain the principles by which we attempted to realise Papert’s vision with CAS. These principles are neither new, nor of any great theoretical complexity, but they should, I believe, be much better known amongst the community of “didacticians” concerned with CAS software and CAS-equipped calculators.
1. The expressiveness of CAS It is difficult to find a good, compact definition of expressiveness, although it is discussed at length in the following references: Papert 1980; diSessa, Hoyles & Noss 1995; Noss & Hoyles 1996; diSessa 2000. I would say that there are two main ideas: firstly, a computational medium is expressive in the sense that one can express ideas (mental objects) in concrete form (visible, public objects); secondly, it is crucial that actions are carried out by means of programming in a syntactically precise language. (I use the term “programming” in a broad sense, as I’ll explain later). Richard Noss and Celia Hoyles have used the term “auto-
*
I hope the meaning of this quotation is clear, but it may be useful to say it explicitly: Papert is equating the failures of “school mathematics” and “school French” to produce (generally speaking) enough students who are sufficiently capable of understanding, and communicating with, mathematics or French. In the case of French, or any natural language, we know the superiority of learning a language by living in a country where that language is spoken. Papert’s vision for computer software is that it could provide the basis for a “country” where mathematics (mediated via a computational form) is the native language.
expressive”, to emphasise the way that a computational medium can be a place where mathematical actions are both performed and reflected upon: … we have expressed our action in a language which in turn, allows us to reflect on our action. We did not have to leave the paper (metaphorically) on the table and transport our thinking to another, algebraic world of inert symbols: in our dynamic algebraic world the symbols came alive. We have breathed life into the symbols: they come alive because they can be executed. (Noss 1997)
Let me approach the idea of the expressiveness of CAS by considering two different conceptions of a computer algebra system: •
As a “professional” tool
•
As a medium (“language”) for mathematical expression
In my experience the second conception is encountered much less often than the first. Now, it is true that the second is implicitly present in the first: a CAS is useful as a professional tool precisely because it allows the user to express and execute the right kind of mathematical calculations. But, I’m convinced that ways of talking about something shape ways of thinking about it, and the great weakness of the “tool” metaphor (at least in the English language) is that it conveys almost no intellectual sense (a tool is a hammer, or a screwdriver, just possibly a computer in the most general sense). However, the “expressive medium” conception emphasises that: •
a CAS consists of a representation of mathematical ideas and objects, and
•
this representation will be better or worse adapted to (i.e, more or less expressive about) different mathematical contexts
Now, the programmability of a CAS means that we can modify and extend the representation for the benefit of learner in a particular context. That is, it is possible to build mathematical structures “…into the fabric of the medium, thus shaping the types of action that are possible: they do not only exist in the mind of the learner. The level of what can be thought about, talked about, is notched up a rung or two” (Noss & Hoyles 1996, p. 126). The following examples suggest two contexts in which the representations provided by a CAS (Mathematica) were modified and extended.
2. Example One: A microworld for differential equations This example concerns first-year university science students at the very beginning of their learning about ordinary differential equations (ODEs); for a fuller description of it, see James et al (1997), Kent et al (1998). I must emphasise that in the UK science students are rarely expected to learn any formal theory about ODEs; it is enough that they can interpret and construct ODEs that model physical phenomena, find the solutions to simple ODEs by penand-paper, and use software to find solutions where necessary. So, when I speak of the “meaning” of an ODE, I am not referring to formal concepts like existence and uniqueness of solutions. Microworld is a term that has been much used (and abused), so I’ll begin by saying in some detail what we mean by it.
The idea of a microworld A microworld is a computational environment that represents a particular knowledge domain and that is constructed for the purpose of learning about that domain. It contains:
• computational objects that embody key mathematical ideas • activities designed so that by operating on these objects, and constructing other objects out of them, learners can encounter, recognise and explore the mathematical ideas The design of a microworld involves making hypotheses about: • what are the likely starting points of students • what are the appropriate representations for particular knowledge domains • what are the appropriate kinds of activities that will promote conjecturing and construction I will say very little on the third point, but it is discussed in the references already mentioned.
ODEWorld ODEWorld focuses on the very beginning of the study of differential equations, and has a number of activities designed around a single “computational object”, TangentField. The first activity asks students to examine the meaning of the term “differential equation” (DE). Why? Mathematics education research (e.g. Dreyfus 1990, Harel & Kaput 1991) suggests that it is common for students to hold to a point-wise conception of derivative: hence their initial meaning for a DE, “dy/dx = 2x”, could be as a relation which states “the derivative at a point [dy/dx] is [=] 2x”. Upon meeting DEs, the student is required to build an entirely new interpretation for a statement like “dy/dx = 2x”. In the context of differentiation, this is a simple description of the derivative of some particular function; in its new manifestation it is an equation that is satisfied by infinitely many solutions. Thus, we framed the following hypothesis: Students may enter ODEWorld with the pointwise conception. Could we design a tool, and activities, to enable students to develop from that conception towards the general, “global” conception of derivative, and hence begin to make meanings for DEs? This “webbing” support, as conceived by Noss & Hoyles (1996), works by “embedding” in a tool both the hypothesised starting concepts of the learner, and the concepts we intend the learner to end up with: Like the web of mathematical ideas, the [World Wide Web] is too complex to understand globally—but local connections are relatively accessible. At the same time, one way—perhaps the only way—to gain an overview of the [WWW] is to develop for oneself a local collection of familiar connections, and build from there along lines of one’s own interests and obsessions. The idea of webbing is meant to convey the presence of a structure that learners can draw upon and reconstruct for support—in ways that they choose as appropriate for their struggle to construct meaning for some mathematics. (Noss & Hoyles 1996)
TangentField In fact, the tool that we implemented, TangentField, is a very familiar one in the context of ODEs: it produces graphs of “tangent fields” (direction fields) for first-order ordinary differential equations. These are a familiar visual representation for ODEs, linking a firstorder ODE with its solutions by distributing small “tangent segments” across the x-y plane, whose gradients are specified by the ODE. TangentField can plot a tangent segment at any single point in the plane, here for dy/dx = 2x (this mode corresponds to the point-wise interpretation of derivative):
TangentField[2x, {x, y[x]}, {{0.5,0.6}}, PlotRange->{{0,1},{0,1}}] 1 0.8 0.6 0.4 0.2
0.2
0.4
0.6
0.8
1
But TangentField in general accepts a list of coordinates, thus the idea of derivative as a function (which is something defined for a set of points) is “embedded” in the tool: TangentField[2x, {x, y[x]}, ScatteredPoints[{-5,5},{-5,5},200]]
4 2
-4
-2
2
4
-2 -4
As I said, tangent fields are a familiar representation for ODEs. But, in paper-and-pencil mathematics, a tangent field is only really usable by someone with the substantial experience to know the shapes and behaviours of typical solutions (usually in textbooks the idea is only introduced after the treatment of linear ODE techniques and in preparation for nonlinear ODEs). In the computational version, however, you find that you can easily see patterns of curves among the tangent segments. An expert user can see these for what they are: the graphs of the solutions of the ODE. But the student does not need the concept of solutions to see these curves—by constructing a meaning for the families of curves, a student may begin to construct the concepts of “solutions” and “differential equation”. Now, you may well ask, was our hypothesis correct? Unfortunately, we did not obtain a good answer to that question since there was a curriculum change shortly after we completed this microworld, and ODEs were no longer taught to that particular group of students. However, other work on this approach by, especially, David Tall (see, for example, Tall 1989) suggests that it can be very successful.
The importance of programming ODEWorld includes small programming activities (not shown here), because these naturally invite students to engage with construction, conjecture and experiment—all of which are central to mathematical activity. Moreover, for a CAS, there is a natural progression in the sophistication of expression, from using tools (first singly, then in more sophisticated combinations) to making tools—and hence becoming an independent user of the system. This development, of using tools in combination, through to making tools, is programming (in a broad sense of the term). It could also be called “talking CAS”, in Papert’s sense of “talking mathematics to a computer”. I realise that programming is not nowadays a fashionable activity in educational (or general) computing. But I’m convinced that if “talking mathematics” is possible with a CAS, it has got to involve programming, in the broad sense just described.
3. Example Two: Trajectories for learning My second example is concerned with an advanced course on dynamics taken by third-year mathematics students; for a full account of this work see Kent (1999). Dynamics should be a natural arena for computer-based explorations; indeed, the growth of nonlinear dynamics and chaos theory over the past 30 years could only have taken place given the central role of computational experiment and visualisation. However, advanced students are not enthusiastic about getting involved with computing work, which they know from experience is often frustrating, time-consuming and not worth the exam credits offered. Therefore, this was an attempt to find some way of using Mathematica which would offer the students less of a programming exercise and more of a mathematical experience. Logo was an important inspiration in this, with its aim of being directly supportive of mathematical thinking and expression (cf. Papert 1980, diSessa et al 1995, Noss & Hoyles 1996). I tried to make Mathematica “expressive” for dynamics by exploiting a feature of its programming language that allows for the creation of new data structures (objects), and functions that can operate on them. The idea being that, as the students program (create and manipulate) these objects, they must deal with a “concrete” representation of abstract mathematical concepts. In principle, meaning can be given to mathematical concepts through this constructive, explicit interplay of concrete and abstract. As an example dynamical system, consider the “simple pendulum” (i.e. large amplitude oscillations without air resistance). The equation of motion is x' ' = − sin x or, written as a pair of first-order equations, x ' = v , v' = − sin x . x and v are the dependent variables, or in the language of dynamics, the phase space variables. The simple pendulum has no explicit solutions so is most easily looked at using numerical techniques. Generally, in advanced dynamics one is concerned with understanding the geometrical structure of solutions as orbits in the phase space.
The problem… There is a serious problem, for inexperienced users, with the difficulty of Mathematica’s syntax for numerical solution of ODEs, and the graphing of solutions. First, you must solve the equations numerically: spsolns = NDSolve[{ x'[t]==v[t], v'[t]==-Sin[x[t]], x[0]==π/2, v[0]==0.0}, {x, v}, {t, 10}]
{{x→InterpolatingFunction[{{0., 10.}},], v→InterpolatingFunction[{{0., 10.}},]}} These resulting InterpolatingFunction objects are obscure, and an equally obscure “extraction” of the solution data is necessary to produce a usable output: x1 = First[x /. spsolns] v1 = First[v /. spsolns] Finally, we are ready to make some graphs, for example the plot of a single component of the solution, such as x(t), or the phase space v(t) against x(t): Plot[x1[t], {t, 0, 10}] 1.5 1 0.5 2
4
6
8
10
-0.5 -1 -1.5
ParametricPlot[{x1[t], v1[t]}, {t, 0, 10}]
1
0.5
-1.5
-1
-0.5
0.5
1
1.5
-0.5
-1
My solution… There is a need to suppress technical details, and to provide “mathematical objects” that are appropriate for the context of dynamics. It seemed right to me to make trajectories (ie. the solution curves in phase space) the fundamental objects. So, in place of the NDSolve and extraction commands above, I wrote a new Mathematica function that creates a “Trajectory” object:
traj1 = MakeTrajectory[{ x'[t]==v[t], v'[t]==-Sin[x[t]]}, {x[0]==π/3, v[0]==0.0}, {x, v}, {t, 10}]
-TrajectoryAnd I also created various functions to operate on Trajectory objects, such as to make a plot of x(t): TimeSeries[traj1, x] Or a phase space plot: TrajPlot2D[traj1, {x, v}] The Trajectory object is simply a re-packaging of the messy NDSolve output, plus some other useful things. One is perfectly free to look at the internal structure of a Trajectory. The point is, though, that students are not required to look at the insides, and every operation they might reasonably wish to perform, such as drawing different kinds of graphs, is carried out using a set of special functions which take Trajectories as inputs. One might ask here, how can I know what students want to do with Trajectories? Am I limiting what students can express? Inevitably, yes; that is a necessary part of making CAS expressive in a particular context. The students here are not expected to be “tool builders”, but users of a pre-supplied package. A more “open” design would be a different task, for a different context.
A mathematical object language? So far, I’ve demonstrated Trajectories as a more convenient way of looking at solutions. But there is more: Trajectory objects can be manipulated to produce non-graphical as well as graphical objects. For example, it’s a common task in dynamics to check on the conservation of total mechanical energy (and other conserved quantities). My Mathematica toolkit provides a function to calculate the values of a given quantity for the phase space points along a Trajectory: energies = CheckQuantity[traj1, v^2/2- Cos[x]]
{-0.5, -0.5, -0.5, ……………………, -0.499995, -0.499995, -0.499995, -0.499995} So energy has been conserved to within a numerical error; it’s easy to plot these values using one of Mathematica’s built-in commands: ListPlot[energies, PlotJoined -> True] -0.499992 -0.499994 -0.499996 -0.499998
20
40
60
80
This idea of object manipulation can be developed into far more complex situations. For example, a powerful technique in dynamics is the analysis of the Poincaré section of orbits in a phase space. One chooses a plane (section) in the phase space (which could be more than 3dimensional, so the plane could be a hyperplane) and given a set of orbits, the problem is to find out all the intersections of those orbits with the plane (for one direction of travel only). In my Mathematica toolkit, there is a command PoincareSection which takes a Trajectory and a plane as inputs, and outputs the set of intersection points: PoincareSection[henonHeilesTraj, Plane[{0,0,0},{1,0,0}]
{Point[{0,-0.121,0}],Point[{0,-0.121, 0.00117}],Point[{0, 0.121, 0.00291}], …………………………………………………………… Point[{0,-0.109,0.0215}],Point[{0,-0.115, 0.0116}], Point[{0,-0.118,0.00737}],Point[{0, -0.121,0.00694}]} The following figure shows a Trajectory in 3-D phase space (top left), and three different Poincaré sections: 0.4 0.2 0 -0.2 -0.4 0.4 0.2 0 -0.2 -0.4 0.4 -0.2
0.2 0 -0.2 0 0.2 0.4 0 4
0.4 0.2 0 -0.2 -0.4 0.4 0.2 0 -0.2 -0.4 0.4 -0.2
0.4 0.2 0 -0.2 -0.4 0.4
-0.4 0.4 -0.2
0 0.2 0.4 0 4
0.4 0.2 0 -0.2 -0.4 0.4 0.2 0 -0.2
0 0.2 0.4 0 4
-0.4 0.4 -0.2
0 0.2 0.4 0 4
The workings of PoincareSection, which are detailed in Kent (1999), are fairly complex. As I’ve already pointed out, the principle of dealing with mathematical objects leads one to suppress construction details and to focus the learner’s attention on the mathematical essentials, namely the Trajectory, the plane and the intersection Points. But what is really remarkable to me about this object language approach is that there is a very direct correspondence between the geometrical nature of the construction of a Poincaré section and how this gets programmed in Mathematica; so direct in fact that one can write very compact code that works independently of the number of phase space dimensions—thus providing a way for learners to think about hyper-dimensional (4 and higher) dynamical systems (see Kent 1999, chapter 5, for speculations about this).
4. Abstraction in computer science, and in mathematics What MakeTrajectory and the other commands in the Mathematica toolkit achieve is that, computationally, details have been suppressed beneath an “abstraction barrier”, but also mathematically, the details of the Trajectory’s construction (via numerical integration) have been suppressed in favour of a qualitative study of Trajectories, phase portraits, conserved quantities, etc. (according to the “qualitative theory of differential equations” as introduced by Poincaré a century ago). Uri Leron has been advocating for many years this kind of approach to using computers in mathematics learning: Programming in an appropriate level of abstraction means choosing ‘primitives’ that are appropriate for the problem (and to the programmer) at hand. Since there is no reason to expect that the suitable primitives will just happen to be there as the primitives of the language we are using, this mostly means creating our own primitives—in essence creating a special purpose language for the problem at hand ... In refusing to deal with lower-level detail while thinking of the (high-level) problem to be solved, we have constructed a metaphoric ‘abstraction barrier’ that separates the programming task into two nearly independent tasks: Above the barrier we deal with solving the original problem in terms of the “abstract primitives” we have selected; below, we deal with the details of implementing these abstract primitives. (Leron 1987, pp. 16-17) Furthermore, he points out the radically different ways of talking about abstraction in mathematics and computer science: Though everybody agrees that mathematics deals with abstractions, the topic is not normally considered as part of mathematical subject-matter proper. In fact, you cannot read about it in mathematical textbooks (even ones with titles such as “abstract algebra”); instead, you’ll have to search for it in books on the philosophy, psychology or history of mathematics or in popular books on the nature of mathematics. The opposite is true in computer science, where abstraction is a methodology which is explicitly discussed, taught and practiced. (Leron 1987, p. 25) Now, of course abstraction in mathematics (and mathematics education) cannot be equated with abstraction in computer science. But I think Leron is absolutely correct about the different attitudes towards abstraction. For example, consider the way it is typically discussed in Advanced Mathematical Thinking theories about mathematics learning (see Kent 1999 for the sources of these quotes): •
abstraction happens more or less unconsciously for the learner as a result of doing constructive activities: “an ontological shift, a sudden ability” (Sfard) “there is no suggestion here that all (or any) of the advanced mathematics described [here] is actually done by any kind of direct application (conscious or otherwise) of reflective abstraction. … The point, rather, is that when properly understood, reflective abstraction appears as a description of the mechanism of the development of intellectual thought.” (Dubinsky)
•
abstraction is a barrier that successful learners must “get across”: “We believe that [the] bifurcation of strategy—between flexible use of number as object or process and fixation on procedural counting—is one of the most significant factors in
the difference between success and failure. We call it the proceptual divide.” (Gray & Tall) I will conclude with a modest proposal: can we (in mathematics education) change our attitude about abstraction in at least some mathematical domains, with CAS providing the adaptable language for “talking about” abstraction in different contexts? Can we learn from computer science education (e.g. Abelson & Sussman 1996 is a classic text) to see abstraction not (only) as a problem caused by multi-layered complexity, but as a powerful tool for dealing with complexity?
Bibliography Abelson, H. and Sussman, G. J. (1996). Structure and Interpretation of Computer Programs, second edition. M.I.T. Press. diSessa, A. (2000). Changing Minds: Computers, learning and literacy. M.I.T. Press. diSessa, A., Hoyles, C. and Noss, R. (Eds.) (1995). Computers and Exploratory Learning. Berlin: Springer-Verlag. (NATO ASI Series F, Volume 146.) Dreyfus, T. (1990). “Advanced mathematical thinking”. In P. Nesher and J. Kilpatrick (Eds.), Mathematics and Cognition (ICMI Study Series). Cambridge University Press. pp. 113-134. Harel, G. and Kaput, J. (1991). “The role of conceptual entities and their symbols in building advanced mathematical concepts”. In D. Tall (Ed.), Advanced Mathematical Thinking. Kluwer Academic. Pages 82-93. James, M., Kent, P. and Ramsden, P. (1997). “TangentField: A tool for ‘webbing’ the learning of differential equations”. Poster presented at the 10th International Conference on Technology in Collegiate Mathematics (Chicago). [Download from http://metric2.ma.ic.ac.uk/articles/ictcm97/poster/Poster.pdf ] Kent, P., James, M. and Ramsden, P. (1998), “Mathematical microworlds with Mathematica”, in L. Lum (ed.) Proceedings of the Tenth International Conference on Technology in Collegiate Mathematics. Addison-Wesley. [Download from http://metric2.ma.ic.ac.uk/articles/ictcm97 ] Kent, P. (1999). Trajectories for Learning. Unpublished Masters dissertation, Institute of Education, University of London. [Download from http://pkent.homestead.com ] Leron, U. (1987). “Abstraction barriers in mathematics and computer science”. In J. Hillel (Ed.), Proceedings of the Third International Logo and Mathematics Education Conference (Montreal). Noss, R. (1997). “On static and dynamic algebra systems”. In J. Kaput (Ed.), Early Algebra. New York: SUNY Press. Noss, R. and Hoyles, C. (1996). Windows on Mathematical Meanings. Kluwer Academic. Papert, S. (1980). Mindstorms: Children, computers and powerful ideas. New York: Basic Books. [Traduction française: Jaillissement de l'esprit: Ordinateurs et apprentissage, Paris: Flammarion, 1981.] Tall, D. (1989). “Concept images, generic organizers, computers, and curriculum change”. For the Learning of Mathematics, 9, 3, 37-42.
