[Edu-sig] re: Terminology question: just operator overriding?

[Kirby Urner]

At 09:24 AM 6/30/2003 -0400, Arthur wrote:
>Kirby Urner wrote:
>
>>At 06:49 PM 6/29/2003 -0400, Arthur wrote:
>Kirby writes -
>>
>>More concretely, it's considered high level, and part of abstract
>>algebra, to be able to generalize from ordinary numbers to these
>>generic "types" with their group, ring and field properties.
>>The addition and multiplication operators become abstracted, to
>>mean whatever operations follow similar patterns (e.g. you need
>>identity elements).
>>So I hardly think the mathematicians can object that we're dumbing
>>down the math curriculum or getting off on a tangent, if we look
>>at an extensible type system, such as Python provides, and use
>>our ability to override __add__ and __mul__ as we define one type
>>after another (permutations, integers modulo N, matrices,
>>polynomials, rationals -- the sets of 'math objects' people
>>traditionally study in group theory and abstract algebra classes).
>
>Override?  Overload,no?  Or I am just wrong here? Who cares, really.

I guess you're right -- I'm not overriding __add__ and __mul__ in
most cases, because not inheriting them.  The (object) object
at the top of new-style classes doesn't have those methods.

I like 'syntax overloading' more than 'operator' overloading,
because I don't like to call parentheses and brackets
'operators'.  But I guess I could call 'em that.

>More to the point:
>
>I am more concerned about the programmers than the mathematicians. Aren't 
>there those who feel strongly that object concepts are overplayed and 
>dumbing down programming?

Yeah, there's at least one guy with a whole website devoted to anti OO.
http://www.geocities.com/tablizer/oopbad.htm

>I am out of my element, and not particlarly interested, in those kinds of 
>discussions.  But expect you will face them.

Agreed.  It's one thing to be a useful paradigm, another thing to claim
to be THE paradigm.  No need to get too doctrinaire.

It's general enough to be interesting and unifying.  I wonder if any
texts take the class-object approach to subatomic particles.  An
electron is defined by a class template (in terms of what it can do),
but a specific electron is distinguished from others by virtue of
being an instance, with its own state data).

>Here I am satisfied - with you - with the practicalities.  The object 
>concept largely is what is in the real world of programming, and is 
>probably somewhere at work at the grocery store.  At some level I also 
>accept that it represents the survival of the fittest concept.  At this 
>stage of the game, at least.
>
>Art

Because we can define __mul__ and __add__ as we wish, we'll use 'em to
return the remainders of products and additions after division by N:

 >>> class M(object):
         n = 12

         def __init__(self,value):
             self.value = value % self.n

         def __repr__(self):
             return str(self.value)

         def __mul__(self,other):
             return M(self.value * other.value)

         def __add__(self,other):
             return M(self.value + other.value)

Now we can show off the group properties of <G,*> if the set G
includes only those positives < N with no factors in common
with N, i.e. gcd(member, N) = 1.  We call these 'the totatives
of N':

  >>> def gcd(a,b):
         while b:
            a,b = b,a%b
         return a

  >>> totatives = [i for i in range(1,12) if gcd(i,12)==1]
  >>> totatives
  [1, 5, 7, 11]

So lets multiply every member of [1, 5, 7, 11] by every
other, remembering that these aren't regular integers, but
M-objects, another kind of math object, with their own
meaning for __mul__:

  >>> showmul(12)
   1  5  7 11
   5  1 11  7
   7 11  1  5
  11  7  5  1

Every row has an identity, meaning each element has an inverse,
and we've got closure.

I didn't show any guts for showmul.  showadd does the same for
add.

I don't actually get into integers modulo N in my PowerPoint
for OSCON -- but this is a good example of how we leverage
Python's operator overloading to explore the properties of
math objects with custom meanings for * and +  (/ and - turn
out to be syntactic sugar -- we define 'em in terms of * and +).

Kirby