[Edu-sig] creating an interface vs. using one

[kirby urner]

> If N happens to be prime, then you get a Galois Field, i.e. you can
> bring __add__ into it, provided you now also have 0 (still excluded as
> a divisor).
>
> >>> class Modint(object):
>         modulus = 20
>         def __init__(self, v):
>                 self.v = v % Modint.modulus
>         def __mul__(self, other):
>                 return Modint(self.v * other.v)
>         def __add__(self, other):
>                 return Modint(self.v + other.v)
>         __rmul__ = __mul__
>         __radd__ = __add__
>         def __repr__(self):
>                 return "%s modulo %s" % (self.v, Modint.modulus)
>

Note:

you may be wondering "what divisor?" in that no __div__ was defined.

The abstract algebra approach is to see __div__ and __sub__ as
"syntactical sugars" that combine two operations:  inverting the right
argument, and then operating with either __mul__ or __add__.

In other words, the "multiplicative inverse" of M is "that member of
the group which, multiplied by M, gives the multiplicative identity"
(1), while the "additive inverse" of M is that which, when __add__ed,
gives 0 (the additive identity).

Then we define:

class Modint(object):

    # ... stuff omitted

   def __div__(self, other):
        return self * other.multinv()  # depends on def of __mul__

   def __sub__(self, other):
        return self + other.addinv() # depends on def of __add__

You'll probably also want to hook __pow__ so our k**(-1) gives 1/k etc. as well.

Students will have a far better understanding of the *patterns*
established within Abstract Algebra, such that when other "math
objects" come along, such as Matrices, it'll be easier to talk about
their non-commutative (still associative) group properties.  They'll
understand how * (multiplication) is a generalization across many
types of object. Same with +.

Polynomials, for example, aren't a group under multiplication because
although we have closure (poly * poly == poly), we don't always have
inverses, i.e. 1/P is probably a Rational Expression and but not a
Polynomial.  So we speak of the Ring properties here (ranked between
Group and Field, in terms of how many rules and restrictions).

As gnu math teachers, we cover all this before college, no problem,
using Python, Ruby or whatever.  Strong OO is advisable, as it's just
natural to consider Polyhedra as Objects (with spin methods, face
count attributes etc.), and we *definitely* want lots of those.

Yes, with VPython, we'll be able to give visual expression to some of
our math objects, such as Vectors and Polyhedra.

But other math objects, such as these Integers Modulo N, needn't get
involved in direct visualizations. No fancy Physics Engine need apply
i.e. the command line (the Python shell) is quite sufficient, thank
you very much (in this sense I agree with Arthur, about not always
needing Ninjas (too distracting sometimes, like those MSFT "helpers"
sometimes (e.g. that guy walks around and explodes sometimes))).

Ruby also has pretty strong OpenGL support near its core.  In that
sense, I think Arthur is right to be pointing to VPython as Python's
counterpart add-on.  We're not behind Ruby, just assemble differently
on the client machine (wxPython -- another whole world).

SciPy is a good example of a distro schools might want to start out
with.  Does it include VPython already?  My impression is it's very XY
(flatland), less XYZ (spatial), but perhaps I'm out of date on that
score.

I still don't see that bundling VPython in the core install need be
the solution.  Guido should rewrite the standard tutorial if so.  Or
somebody should.

But isn't it kind of late in the game to be trying to swallow that
battery too?  Why not go with my earlier solution:  admit that
Python's best add-ons aren't necessarily in the Standard Library.  The
SL is just a starter kit, not the Big Enchilada.

I think the logical level at which to bundle is the school.  Parents
will see Ivan using doing 3D XYZ graphics on a flatscreen in Budapest,
and wonder why Johnny at Portland Public is still punching a TI.

It's the school that should be asked, not Python.org, which has no
responsibility to *push* these solutions on people.

We want schools to *pull* based on forces in the marketplace (i.e.
competition).  We don't want PSF to have to shovel and/or spoon feed.
That's not its job.

Make *schools* do the work.  Python.org has already done more than
enough.  Everyone associated with Python, including Guido, should have
permission to retire with royalties, and not lift a finger to "save
education".

Twasn't Python Nation that sank it in the first place.

Kirby