[Edu-sig] Algebra + Python

[Seth David Schoen]

Kirby Urner writes:

> A link between programming and algebra is in this concept
> of variables.  A polynomial in the 2nd degree is typically
> written as Ax^2 + Bx + C, which in Python is more like
> A*x**2 + B*x + C.  The capital letters are called constant
> coefficients and they "fix" a polynomial, give it its 
> characteristic "call letters" (like in radio:  the is 
> KQPD...).  Then x is what varies -- you might stipulate 
> over some domain, e.g. from in [-10,10] (square brackets 
> means inclusive).

This point is very subtle.  I'm afraid that a lot of adults still
couldn't tell -- for example -- the difference between an expression
like "x+3" and an equation like "y=x+3".

Mathematicians tend to get very comfortable with higher-order
functions, "function factories", operations on functions, and the
like.  Unfortunately, it seems that other people often don't.

If we see in a math book

	Consider the equation

		y = Ax + B

there's already a good deal of sophistication: first, "y = Ax + B"
is _not_ a general fact (or theorem) which is true in general, without
context or qualification.  In this case it's a hypothesis, or, some
would say, a statement of a subworld in which this _is_ an axiom or
a theorem (one of many possible such subworlds contained as logical
possibilities within our own world).  (This might be confusing because
_some_ formulas, like those in physics or like the quadratic formula,
_are_ general -- and are something to memorize and to apply in a whole
class of situations.  Whereas here, this equation is not a great truth
about nature, but just an assumption which we make temporarily to see
what would follow from it.)

But also, A and B were not specified explicitly.  So we're told that
"A and B are numbers" and "x and y are numbers" -- but they have
different roles with respect to the situation.

A, B, x, and y are _all_ unspecified, but A and B are "constants" and
x and y are "variables": yet later on we may make a further
hypothesis.  "Suppose x is 3 -- then what happens?"  (One kind of
answer is "Then y will be 3A + B".)  Isn't it funny, from the point of
view of a beginning algebra student, that a "constant", which is
supposed to represent a _particular number_, is still often given in
symbolic form, and we often never learn what the constant actually
stood for?

That leads to yet another conceptual problem: _do_ variables always
actually "stand for" some particular quantity?  At the very beginning
of algebra, as I experienced it, the answer was an unqualified "yes":
each letter is just a sort of "alias" or "code name" or something for
a _particular quantity_, and it is our job to find that particular
quantity and so "solve the problem".

This completely glosses over the possibility of underdetermined
equations, which simply describe relationships between quantities
(some mathematicians like to think of functions, or mappings between
sets).  If we say y=f(x) -- without giving other simultaneous
equations -- we have an underdetermined system, and there is no longer
a meaningful question of "What is x?".  x is not anything in
particular; x is really a signifier for the entire domain of a
function.

But, interestingly, if we add more equations to a system, it may
become determined.  In that case, we are asking "What are the
particular values of the variables x, y, z for which all of these
things could be true at the same time?" or "If all of these
constraints were applied at once, what possibilities would be left?"
or "What is the intersection of the geometric objects corresponding to
the loci of points satisfying each of these relations?".

In the geometric interpretation, "y = Ax^2 + Bx + C" is actually an
equation representing a shape in five-dimensional shape, one equation
in five unknowns.  When we study a particular quadratic, we are
intersecting that shape with the shapes given by three other
equations: A = [some given constant], B = [some given constant], and
C = [some given constant].  Then, by substitution, we could turn this,
if we choose, into one equation in two unknowns (the familiar
quadratic).  But some people would prefer to say that all five
dimensions are still there -- we are just looking at a particular
region, where some other conditions specific to our problem happen to
obtain.

The geometric interpretation of any equation (or inequality or other
kind of relation) as expressing something about a subset of a space
with a huge number of dimensions (one per variable) is something that
shows up in explicit detail in linear algebra, but before that is only
hinted at.  Some Algebra II textbooks mention a bit about "so many
equations in so many unknowns", and substitution, and maybe even
determinants, but there isn't the strong geometric sense of "there are
an infinite number of dimensions of space, and by writing mathematical
relations we choose to focus our attention on intersections or
disjunctions or whatever of subsets of that space".  And I don't know
whether the multidimensional spatial metaphor is helpful or harmful in
7th grade; if people have read E. A. Abbott, it will at least be
_exciting_ to them.

Once I studied Scheme and lambda and environments in _SICP_, I felt
much more comfortable about all of this.  Here programming can help
a great deal, I think.  But I wonder how many algebra students can't
really see what's going on and what the actual roles of those letters
are.

> At the command line, 8th graders would have one kind of 
> function called a "polynomial factory" that turned out 
> polynomials with a specific set of coefficients.  These
> would then be floated as functions in their own right, 
> ready to take in x domain values and spit out f(x) range
> values.
> 
> There may be a better way to write the factory function than
> I've shown below.  I'd like to see other solutions:
> 
>  >>> def makepoly(A,B,C):	
>         """
>         Build a polynomial function from coefficients
>         """
>   	  return eval("lambda x: %s*x**2 + %s*x + %s" % (A,B,C))

If Python's variable scope rules didn't prevent it,

	return lambda x: A*x**2 + B*x + C

would be much easier to read, because it would avoid the format string
stuff, which is _not_ so intuitive unless you're already a C
programmer.  Earlier today I wrote "%02x" without flinching, so "%s"
is second nature.  But if you're trying to get students to understand
how the lambda is working, "%s" and the tuple may add a lot of
confusion which it would be nice to be able to avoid.

>  >>> f = makepoly(2,3,4)  # pass coefficients as arguments
>  >>> f(10)                # f is now a function of x
>  234
>  >>> 2*10**2 + 3*10 + 4   # check
>  234
>  >>> f(-10)
>  174
>  >>> [f(x) for x in range(-10,11)]  # remember, 2nd arg is non-inclusive
>  [174, 139, 108, 81, 58, 39, 24, 13, 6, 3, 4, 9, 18, 31, 
>   48, 69, 94, 123, 156, 193, 234]
>  >>> g = makepoly(1,-2,-7)  # make a new polynomial
>  >>> g(5)  
>  8
>  >>> g(f(5))                # composition of functions
>  4616
>  >>> f(g(5))                # f(g(x)) is not equal to g(f(x))
>  156

I still think that some of my old math teachers would be floored if
they could see some of these applications.

> Moving beyond 8th grade, we want students to understand what's
> meant be D(f(x)) at point x, i.e. dy/dx at x -- the derivative.
> Again, Python makes this easy in that we can write a generic 
> derivative taker:
> 
>   >>> def deriv(f,x):
>         """
>         Return approximate value of dy/dx at f(x)
>         """
>   	  h = .0001
> 	  return (f(x+h)-f(x))/h
> 
>   >>> deriv(f,2)       # f(x) = 2*x**2 + 3*x + 4
>   11.000200000026439
>   >>> deriv(g,2)       # g(x) = x**2 - 2*x - 7
>   2.0001000000036129
> 
> If you remember how to take the derivative of a polynomial, you'll
> know that f'(x) = 4*x + 3 and g'(x) = 2*x - 2 -- so these are pretty
> good approximations.

I would add an h parameter, with a default value:

def deriv(f,x,h=0.0001):
	return (f(x+h)-f(x))/h

Another possibility is to take the right-limit numerical derivative
and the left-limit numerical derivative.

def left_deriv(f,x,h=0.0001):
	return (f(x)-f(x-h))/h

Contrasting the two shows (among other things) that the numerical
methods are imprecise and the kind of errors you get may depend on
where you take your samples.  (The magnitude of the error will depend
on the magnitude of h, but the sign of the error will depend on which
side you take the derivative on.)

I think I would have been happy to have been given some numerical
methods before I knew calculus, and then to learn a precise way to do
it.  (If I had programs that say that the slope of something is
2.0000001, I would like to know how to prove that my programs aren't
quite right, and that the real slope is 2.)  Python is a good language
for this; I have written concise Riemann sum and Monte Carlo programs
which find the area under a circle, to illustrate for students how
those techniques work.  My Riemann sum program is 17 lines and my
Monte Carlo program is 51 lines; I think they're readily readable for
a non-programmer.

The current situation is definitely the reverse -- you get symbolic
differentiation and integration first, and numerical methods on a
computer later on.  In fact, because I wasn't going into engineering,
I never had the numerical methods course, and I still don't know about
a lot of the efficient ways for doing numerical integration of
differential equations and so on.

I wonder whether the "symbolic first, numerical later" comes from the
historical lack of availability of computers, or whether it's intended
to promote detailed understanding.  I know a lot of math teachers were
very unhappy with graphing calculators because of the extent to which
their approximations can substitute for proof.

You would see algebra tests where a teacher would say "solve this
system" or "solve this polynomial" and students would pull out
graphing calculators and get an answer like "2.003" and write "x=2".
So one obvious problem is that they weren't solving anything -- they
were just typing the equations into the graphing calculator, and it
would find intersections or roots by iterative approximation methods.

Another problem is that students were seeing an answer that looked
plausible and believing it without any proof.  So if x "looks like
about 2" (in the calculator), students might have little compunction
about writing "x=2".  But this could be wrong!  It's easy to devise
problems where a numerical solution is _close to_ an integer or a
rational, so if you do an approximation you can easily be misled.
Sometimes there is a symbolic method which would give a precise answer
in symbolic form (and show that the guess from the approximation is
actually incorrect).

On the other side, people who do work with applied mathematics
nowadays often spend a lot of time writing programs to do numerical
approximation -- numerical integration and differentiation, numerical
approximate solution of linear systems, numerical approximation of
roots of polynomials, and dynamic or statistical simulation.  I met
lots of experimental physicists who did simulation work and who
weren't trying to find any kind of symbolic form for anything -- they
wanted _numbers_!  Crunch, crunch, crunch.

So some people might say that, if a good deal of mathematics is done
(as it is) with computer approximation and simulation, then getting
people started early with experimenting with computer approximation
and simulation is a good thing.  The question is whether there is
necessarily a loss in understanding of theory when people are taught
these numerical techniques early on.  (Who wants to do symbolic
integration to figure a definite integral when your TI calculator has
FnInt?)

Of course, you can program symbolic manipulation in a computer too.  A
very good exercise which some students at my old high school once got
a lot of attention for attacking is symbolic differentiation -- given
a string or a tree representation of a function of one variable,
compute a string or a tree representation of its symbolic derivative.
The representation just has to be _valid_; you don't have to simplify.

This also leads to the interesting question of how you get a string
converted into a tree or a tree converted into a string, which is
something people are _definitely_ going to encounter in great detail
in computer science.  Finding the abstract structure of a formal
expression, which is to say parsing it, just keeps coming up
everywhere.

I could have understood a lot about that in high school, if somebody
had taught it.

-- 
Seth David Schoen <schoen@loyalty.org>  | And do not say, I will study when I
Temp.  http://www.loyalty.org/~schoen/  | have leisure; for perhaps you will
down:  http://www.loyalty.org/   (CAF)  | not have leisure.  -- Pirke Avot 2:5