# Education

## Mathematics packages: Their role in education

### Contents

- Introduction
- Comments on the various packages
- Comments on mathematics packages in general
- Conclusions
- Postscripts

11 August 1994

### Introduction

#### What is a mathematics package?

A mathematics package is a piece or collection of pieces of computer software designed to perform various mathematical procedures. These procedures include, but are not limited to the following:

- Basic Arithmetic: The computer functions as an oversized pocket calculator with all the regular functions (e.g., +, −, ×, /, powers & roots, logarithms & exponents, trigonometric & hyperbolic functions, etc.) but with increased accuracy (100 digits!) as an option.
- Expanded Arithmetic: The ability to give answers in rational or root form (as opposed to a decimal approximation) and the ability to find prime factors, greatest common divisors, and least common multiples of integers.
- Algebra: Change of subject, roots of polynomials (including complex roots), simplification of equations.
- Matrices & Vectors: matrix multiplication; dot and cross products; finding determinants, inverses, traces; solutions of linear systems.
- Calculus: Limits, differentials, integrals (definite & indefinite, single and multiple), expansion of series and products.
- Graphing: Functions in two and three dimensions.
- Statistics: To a limited extent only (for statistics one would presumably buy a statistical package).

In this essay I will explore some of the issues surrounding the design and usefulness of mathematics packages at school and in the home with specific reference to Derive, Maple, and Mathematica.

### Comments on the various packages

#### Derive

Occupying a lean 360 kB of disk space *Derive* is a minimalist package. Despite its small size, however, it is capable of many of the same low-end tasks of *Maple* and *Mathematica * — each of which occupies nearly one hundred times as much disk space in full form. High-end computing power is not in the hands of most computer owners, especially the schools. In all but a few well-funded exceptions, your typical high school (the age level at which serious mathematics is first introduced) operates on shoestring computing budget. Memory limitations are an important factor when considering a maths package, especially if a school's hardware is limited to machines that are shared between multiple teachers or departments. *Derive* also wins out on cost. Its $50 price tag is about one-third that of *Maple*'s and a minuscule fraction of the full version of *Mathematica*. Again, for the individual or school on a tight budget these are important considerations.

*Derive* handles the basics in a rather straightforward manner. In terms of arithmetic, algebra, matrices, and calculus it operates in much the same way and is as equally fast as the other programs. Editing, however, is a real chore. *Derive* is geared more towards writing and rewriting than towards editing. One of the great things about computing is the ability to make modifications to a piece of work to see what new outcomes will result. *Derive*'s ungainly editing hinders such exploration. Thus, its use in the classroom would be limited to the checking of work by students or the generation of answer keys by teachers.

I was most disappointed with the *Derive*'s graphing capabilities. The commands for drawing a graph are easy enough to use, but the quality of the output is the worst I have ever seen. The few simple graphs I generated bore little resemblance to what I expected. *Derive* draws graphs as a series of disjointed points and smooth curves are approximated by jaggedly arranged pixels. Only a limited amount of points are plotted on the screen (perhaps to accommodate slower machines), no curve looks continuous, and small details are easily lost on the screen approximation. It also seems as if the graphing subroutines are engaged in some form of internal rounding. Points are often plotted near to where they ought to be, but not accurately enough to give a true picture. This results in functions that appear to have two *y* values in places. The subsequent "curves" look nothing like their classical representations. This precludes using the program in the classroom for visualization purposes. In physics, I spend a great deal of time trying to get students to make smooth graphs. Showing them *Derive*-generated graphs would likely distort their understanding of the graphing process and reinforce their urge to connect the dots.

#### Maple

*Maple* is a step up from *Derive* in terms of sophistication and requires significantly more memory — this is not much of a comparison, however, as *Derive* was exceptionally small. The $79 price tag is reasonable enough to make me consider buying it for my own Macintosh LC, but until I buy additional RAM it would be a bit of a gamble. I am not sure that my machine could even satisfy its minimum RAM requirement of 2560 kB let alone its preferred 4 MB.

*Maple* was fairly easy to learn and use and had editing capabilities that were far superior to *Derive*'s. As was noted in the previous section, the capacity to edit is a feature that is very important when applying computers to learning mathematics. Graphing in *Maple* was reasonable. The graphs were smooth and continuous looking and *Maple*'s editing capabilities made it easier to play with the expression and its range.

The best part of *Maple* is the ability to produce three-dimensional graphs. This is what computers are made for. Drawing 3D graphs by hand is an extremely laborious procedure and sketching them is an art that few mathematicians have mastered. Exploring graphs in three dimensions is next to impossible for the casual mathematician. Computers open the door to exploring 3D visualization for many who might not otherwise consider it. *Maple*'s 3D graphs are rather straightforward although the coloring scheme used seemed rather arbitrary. It appeared as if swatches of color were patched together on to the surfaces. The ability to rotate the axes made up for this to a certain extent. Being able to reposition oneself with respect to the surface helped in visualizing it. However, even with the particularly powerful computers available in the laboratory, the 3D rendering was a bit slow and appropriate representation would require higher resolution monitors than were available. The unavailability of sufficiently sophisticated hardware may preclude the use of *Maple* in some school settings.

The worst thing about *Maple* was its inane insistence on ending every command line with a semicolon before hitting the enter key. This incessant devotion to an obscure and illogical syntax was an inconvenience at first but began to feel more like torture as time went on. Just when I thought I had internalized the semicolon, logic would take over and I would omit it. Programmers that remain ignorant of user friendliness should be prohibited from writing commercial software. Although many of them lack programming sophistication the amateurs that produce shareware and freeware do a much better job in this regards. Commercial programmers on the other hand punish us twice — once at the cash register and then again at the keyboard.

#### Mathematica

*Mathematica* is a completely impractical program for use by anyone outside of academic or industrial research and development work. For what I need from it, I would never pay the exorbitant retail cost. Even with the student discount, it's a heavy burden to carry. The full program is a behemoth that eats up both RAM and disk space. I could never use *Mathematica* with my present home computer as the 5 MB of RAM that it requires is more than double what I have available and the 20 MB or so disk space it consumes would top out my hard drive. Your typical school would need to buy one machine and have it specially configured to run *Mathematica* (assuming they didn't have machines for multimedia or other memory intensive applications). I could only recommend *Mathematica* for schools that were already flush with high-end microcomputers or were about to receive a generous grant.

With all due respect to frugality let me also say that this is just the kind of program I dream about. High-end computing is to the 90s what high-end stereo equipment was to the 70s — a guy thing. The newest toys for big boys are 100+ MHz Power Macs and Pentiums, gigabyte hard drives, and memory-intensive packages. I would want to own a copy of *Mathematica* for no other reason than because it can do everything. As someone who enjoys mathematics and physics as an avocation, I never know when I might get drawn into an esoteric function or computation. Being so powerful, *Mathematica* is a program I could use for years.

Dreams of winning the lottery aside, I like what I've seen of the program so far. It behaves much the same as the other two programs, but with a bit more sophistication. Graphs in *Mathematica* had a cleaner appearance and the color scheme on the 3D graphs — one color for low points, another for high points, and something else for in between — made more sense than *Maple*'s apparently random tiling effect. I also noticed that *Mathematica* has an animation command. In physics, some of the most difficult topics to teach are those involving dynamic processes. Wave phenomena, for example, do not lend themselves well to blackboard diagrams. If I could show what happens to a point in a media as a wave passes using the animation features of *Mathematica*, I would have one more reason to buy it. As we have not yet explored this aspect of the program, I cannot say for certain whether this is the case.

### Comments on mathematics packages in general

#### Mathematics packages as programming languages

Each of the packages we explored is basically a compiler for a programming language particular to the limited scope of a single application. They just happen to have the capability of drawing nifty graphs and computing 2^{25} − 1 to one hundred digit accuracy. Although I understand that *Mathematica* has a bit of acceptance in academic circles, as far as programming languages go, each of the packets examined in class is equally weak. Except for *Derive*'s pathetic graphing capabilities and *Mathematica*'s amoebalike passion for absorbing subroutines, one package is pretty much the same as any other. One ridiculous set of idiosyncrasies has been replaced with another equally ridiculous set — where *Maple* needed functions in lowercase *Mathematica* needed them in title case, where *Maple* used parenthesis *Mathematica* used square brackets, where *Maple* demanded semicolon-return at the end of a line *Mathematica* demanded shift-return. That we have three isolated programs each operating pretty much the same as the other illuminates the drive many programmers feel to be the author of their own programming language. The question we have to ask is do we really need another language? I think not.

What is *Mathematica* but a collection of subroutines. The entire package could have been written in a conventional language such as FORTRAN, Pascal, or C. These are languages that are available in the public domain. Anyone with an advanced knowledge of programming could write a compiler and sell it without having to worry about creating a market of people knowledgeable in its syntax. They already exist, being churned out by the thousands in computer science departments across the nation. To this compiler they could add a collection of subroutines and make them available as a package in much the same manner as was done with *Maple* and *Mathematica*. Anyone interested in programming could easily jump into this type of package and begin writing programs and subroutines of their own. As things stand now, I would need to take a course devoted entirely to programming *Mathematica* for me to learn how to use it to the fullest extent and, after spending several hundred dollars, there really should be no task on it that I could not accomplish.

#### Proposal for a user friendly package

When we moved on to *Mathematica*, I was really hoping that the program would make use of the user friendly aspects of the Macintosh operating system. What I found instead was yet another scrolling window that needed flawlessly typed commands governed by odd and esoteric rules. What somebody really needs to do is write a program that runs by way of some sort of graphical user interface.

For instance, say you wanted to graph a particular function. The program would provide you with a little window to *build* not type the function in, somewhat as the program I used to construct equations for the word processor I used writing this paper. Using this program, instead of typing (x^3+1)/(x^2-1) the user would build the function…

x^{3} + 1 |

x^{2} − 1 |

inside a window labeled graph, enter the extremes of the range into boxes labeled "min" and "max" and hit a button labeled "draw". To change the function the user would highlight the part to be change with the mouse and enter the changes. The range could be changed the same way or they could be adjusted using up and down buttons. To plot in three dimensions, the user would press a resize button in the corner and see the window expand downwards to reveal an additional range for the second variable.

A similar GUI system could be created for matrices. In my word processor, when I want to create a table I simply move the mouse to the table button on the "ribbon," press down, drag the table icon until it has acquired the necessary number of rows and columns and release. Voila! I now have a table that I can fill in any order I want. I don't have to follow some programmer's rules that vary from package to package. I could do the diagonals first, or the corners first, or top-to-bottom left-to-right. This is much easier and quicker than typing the command for a matrix, entering numbers in order, enclosing the sequence in parentheses, and then hitting return only to find that I forgot the final semicolon, or that I should have used square brackets instead of parentheses, or that I should have hit shift-enter instead of enter.

### Conclusions

#### Do we really need mathematics packages?

Unless I was teaching in a college setting or in a camp devoted to the teaching of advanced science and mathematics to adolescents, I could not recommend that a school buy any of the three packages we examined — *Mathematica* and *Maple* because of the ungainly memory, financial, and training requirements and *Derive* because of its inelegance. No school needs any of these packages. There are graphing programs available of reasonable size and cost for visualization and no school on earth *needs* a glorified calculator with 100 digits of accuracy. In addition, giving students the keys to the teacher's edition by providing them with access to a package that can calculate integrals and perform change of subject would likely hinder their educations more than promote them. Given the opportunity, many students will opt for the easy way out. Instead of learning the rules of algebra many of them would just as soon do all their math homework on the package and get a 100% on their homework. This assumes that the correct way to teach mathematics is through drill and repeat based instruction.

#### The role of packages in the future

Why is mathematics taught in the schools in the first place? Does anyone really need to know how to divide complex numbers? An overwhelming majority of the people on this planet have made it through their entire adult lives without once needing to solve a set of simultaneous equations. Why should we assume that our students should need to learn this skill to graduate high school? Math education needs to follow a different route than the one it has followed in the past. The acceptance of pocket calculators has induced the demise of the longhand method of calculating square roots in mathematics education. I don't hear anyone mourning the loss of this skill. Knowing how to find a square root is not as important as knowing what to do with one. Likewise, knowing how to construct a set of simultaneous equations and deciding whether they can be solved is more important that knowing the procedure for solving them. This fact is something that is often lost in the debate about how math should be taught. We spend so much time drilling algorithms into our students' heads — 75% of instruction time by my estimate — that they never see the use of this knowledge. If a computer can do these tasks faster and more reliably than a human can then it should be used.

Every task that a spreadsheet program can do a human can also do, yet this has not stopped business schools from teaching accounting. Businesses have not been rendered less productive by having hired accountants trained on computers. The reverse has happened. Accounting divisions are more productive now because they can make projections based tweaking the data. Educators should look to this as an example of the successful integration of computing with mathematics. I really believe that children could learn algebra by sixth grade and calculus by ninth if only they weren't burdened with memorizing formulae and algorithms.

The *Writing to Read* movement in reading education parallels my thoughts as to how mathematics should be taught. In *Writing to Read*, students are told to write stories before they are taught the rules of spelling and grammar. Mistakes of "invented spelling" are allowed as the main focus is on getting the students to concentrate on the overall structure of their compositions. *What* a student is trying to say is much more important than *how* he spells any of the words in the story. Math should be taught in a similar manner, as an exploration of the behavior of numbers and not as a series of loosely connected procedures devoid of context.

### Postscripts

Updates go here.