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