Their Role in Education

E-World

© 1992-2008 by Glenn Elert

All Rights Reserved -- Fair Use Encouraged

11 August 1994

- Introduction
- Comments on the Various Packages
- Comments on Mathematics Packages in General
- Conclusions
- Postscripts

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 tree 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.

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* 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* 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.

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.

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 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.

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.

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.

Updates go here.

Glenn Elert Author, Illustrator, Webmaster hypertextbook.com chaos, physics, facts, eworld, get bent |

No condition is permanent.