[Edu-sig] re: throwaway code (a.k.a. personal-use scribbling)
Kirby Urner
pdx4d@teleport.com
Fri, 4 May 2001 21:28:09 -0700
In a recent thread, we were looking at source code for doing
polynomial expressions, with both a symbolic and number
crunching aspect. Thanks to Brent, the polynomial quickly
became an object, which allowed for operator overloading of
multiply, add, subtract and power (but not divide).
Example usage:
>>> from polynomial import *
>>> p1 = Poly([1,2,3])
>>> p2 = Poly([2,0,0])
>>> p1
x**2 + 2*x + 3
>>> p2
2*x**2
>>> p1*p2
2*x**4 + 4*x**3 + 6*x**2
>>> p2(10)
200
>>> p1+p2
3*x**2 + 2*x + 3
>>> p2.deriv()
4*x
I think such source code is illustrative of a genre I'd call
"throwaway code".
In the old days, time on computers was hard to come by,
programming was more difficult and for the highly skilled, and
so if you had the opportunity to write some code, the
economics of the situation often dictated that you do so "for
the ages".
In other words, your end-user was someone you maybe will never
meet, but because you've written a set of FORTRAN functions
for manipulating matrices, and put them in a library someplace,
along with documentation, that end user will be able to take
advantage of your precious skills (and FORTRAN's power).
Given your code might get pulled in by some larger system in
charge of monitoring nuclear power plants, or launching a
rocket, it'd better be robust and full of error trapping --
make your code as bullet proof and "ready for anything" as
possible.
That's the opposite of throwaway code, and the need for it hasn't
gone away by any means. We all depend on such robust, archived,
documented and (if we're lucky) open source assets at every turn.
On the other hand, computer time is now very cheap, programming
is relatively easy, and it's no longer anti-economic to write code
with primarily one end-user in mind -- oneself. It's more of a
scratch pad approach. You scribble code as you would math
notations to perform a calculation, with the added benefit that
your module is more easily saved and re-run later.
simplematrix.py is another example of throwaway code. It looks
a lot like polynomial.py in that it contains essentially one
list of data, and overrides * ** + and -. No determinant or
inverse here [in the works]. This is not a commercial grade
module, optimized for speed, and generic enough for any end
user. It's more illustrative of the kind of thing a student
could whip out in a relatively short time.
Example usage:
>>> from simplematrix import Matrix
>>> a = Matrix([[1,2],[3,4]])
>>> a
[1, 2]
[3, 4]
>>> b = Matrix([[-1,0],[0,-1]])
>>> b
[-1, 0]
[0, -1]
>>> a*b
[-1, -2]
[-3, -4]
>>> a**2
[7, 10]
[15, 22]
>>> a+2
[3, 4]
[5, 6]
"Math through programming" is very tied to this "throwaway code"
concept, because the focus is on the math, the mathematical
concepts, and not on all the claptrap that makes a program
commercial grade and ready for prime time. We don't assume an
anonymous and/or naive and/or malicious end user who might keep
passing illegal arguments. We don't necessarily optimize for
speed (which might mean coding in C and using Python as a front
end) because our goal is transparency: it's more important to
be able to see/read the code and understand what principles it
embodies. We therefore to use "pure Python" whenever possible.
One thesis I've advanced at my website is that the computer science
notion of "object" is going to percolate more and more through math
world, such that we'll be spontaneously thinking of polynomials and
matrices as objects (vectors, quaternions, sets, functions -- all
are objects). One difference between a function and an object is
that an object saves persistent state data internally. Functions
are more "pass through" and the feeling you get is that data is out
in some logical space, there to be operated upon by functions, but
functions don't contain data, and data have no clue about functions.
With objects, this changes: data is may be internal to objects,
which is also where the functionality is contained. Instead of
"functions working on data", we have "objects containing both data
and functions, and working with one another". It may be a subtle
shift, but I think one that's destined to affect mathematics, not
just computer science.
So in Python, using throwaway code, now that we have both Poly
objects (polynomials) and Matrix objects, with no additional code,
we can create some synergy: pass a matrix to a polynomial for
evaluation, or populate a matrix with polynomials. This illustrates
the power of objects, and why we might want to teach Python in
complement with mathematics -- because it helps us conceptualize
the math:
>>> p1
x**2 + 2*x + 3
>>> p2
2*x**2
>>> a
[1, 2]
[3, 4]
>>> # passing matrix object to a polynomial object
>>> p1(a)
[12, 17]
[24, 33]
>>> # populating a matrix w/ polynomials
>>> c = Matrix([[p1,p2],[p2,-p1]])
>>> c
[x**2 + 2*x + 3, 2*x**2]
[2*x**2, -x**2 - 2*x - 3]
>>> c**2
[5*x**4 + 4*x**3 + 10*x**2 + 12*x + 9, 0]
[0, 5*x**4 + 4*x**3 + 10*x**2 + 12*x + 9]
# passing a matrix populated with polynomials to a polynomial
>>> p2(c)
[10*x**4 + 8*x**3 + 20*x**2 + 24*x + 18, 0]
[0, 10*x**4 + 8*x**3 + 20*x**2 + 24*x + 18]
Kirby
Notes:
polynomial.py
http://www.inetarena.com/~pdx4d/ocn/python/polynomial.html (or .py)
simplematrix.py
http://www.inetarena.com/~pdx4d/ocn/python/simplematrix.html (or .py)
Re: OOP affecting math
http://www.inetarena.com/~pdx4d/ocn/oopalgebra.html