At 06:49 PM 6/29/2003 -0400, Arthur wrote:

Kirby Urner wrote:

...

Mostly it's about how this thinking in terms of objects is generic and powerful enough to deserve a bigger footprint in K-12, and that traditional math concepts might be well served by these same metaphors (math objects, defined by class blueprints, with instances containing specific state info -- e.g. fractions, polynomials, vectors etc.). Python makes these metaphors concrete.

Sounds sensible.

Seems to me if we were satisfied with very targetted introduction of well-established concepts that have their roots in programming (as applied mathematics) and intergrate the use of those concepts well with existing curricula at the K-12 level - very much along the lines you suggest, it seems to me - well, there might be some measurable upside to it all.

As a philosophy major, I'm aware of how the logicians were always pushing for a semantics that'd be precise, computational, yet all encompassing at the same time. Propositional calculus and like that. But this was before programming languages (Bertrand Russell et al, and Leibniz before that). Yet the object oriented paradigm is another example of a similar push. The student is deliberately prodded to look well beyond the computer, or some specific language, to see the world in terms of objects, their interfaces, their interactions. We even talk about events (which aren't just mouse clicks and key presses) -- very general.

It is conceptually sound, and does not even depend, necessarily, on the availability of a machine. Though no question, that would be better.

Small is beautiful.

Art

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). OOP gives a good general context, a philosophical basis rich in metaphors, inside of which we can develop and reinforce a lot of traditional math and science concepts -- in tandem with a computer language. There's also a lot of generic language skills required, to express ideas about attributes, methods, inheritance, encapsulation, interfaces and so on. Numeracy and literacy skills both get a work out. It's a reasonable approach. I think a mix of philosophy and computer science should be more aggressively advanced as a basis for curriculum integration. In the old days, arithmetic was a lot about how the corner store operated. Today, the corner store uses scanners in the checkout lanes, wired to relational databases designed to monitor sales and trigger re-orders (some stores also track purchases by customer -- e.g. Safeway cards). Yes, we still need curriculum that explains what goes on in the corner store -- but this can no longer be done without reference to computerized infrastructure. Kirby

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

At 02:59 PM 6/30/2003 -0400, Arthur wrote:

Kirby writes -

...

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

In fairness to Python, perhaps you should at least give some play to its multi-paradigm approach. Just so people don't confuse it with being religiously OO, as for example, Ruby or Smalltalk seem to be. Talking

Also Java. I understand that in Perl the class definition is really synonymous with the module defining it. In Python, a module as similar to a class, in that we use dot notation to access its contents. There's a dictionary involved. But there's no subclassing of modules.

through my hat, BTW, if it isn't clear - that is, considering the depth of my undersanding of these issues and my experience with Smalltalk and Ruby.

In Smalltalk, as I understand it, there's no direct access to any of what we'd call a property. The interface of an object to the outer world is methods and that's it. I've started through the Ruby tutorial a few times. I'm sort of like Eckel here -- it's not enough better/different from Python to attract really sustained interest, whereas a language as different as J... Bruce hadn't heard of J when I mentioned it during his presentation to PORPIG.

The fact is that since Python is my major language, the distinction between programming paradigms is not a very useful paradigm with which to concern onceself. The best way to get from Point A to Point B, via Python's facilities, is the more useful question. What paradigm borders I cross in the process is not something with which I concern myself (or truly understand). If I had more trouble finding my way from A to B - in a way that someone following after me would have difficulty following - I would then concern myself more with why that might be. And think more, perhaps, about programming paradigms. At the level at which I am working, at least, I don't see the issue arising.

Makes sense. What I like about Python is how easy it makes the class idea. You don't need to consider it an advanced topic. You can define functions in the usual fashion, and interact with them in the shell. Then, if you like, you can bundle them such that they're presented through a class. For example, one kind of math object I *do* get into in my OSCON slides is the permutation. A permutation is a mapping of elements to the same elements in a different order (surjective and onto, as the math heads like to say). Take a deck of cards... Anyway, there's a meaning for multiplication here, in that if one permuation takes you from A to B, and another from B to C, then their product takes you directly from A to C. I develop that as a function at the module level, then invoke it internally to a class definition. The pattern is like this: -------- Module ------------- def compose(map1, map2): ... return map3 class Permutation(object): ... def __mul__(self): return Permutation(compose(self.amap, other.amap)) ------------------------------ In other words, the class definition wraps first class functions without bothering to rewrite them. It's because Python allows first class functions, not just classes, that we're able to do this.

My prejudice toward using OOP concepts was probably just a function of the fact that it was a natural fit for much of what I was doing and how I was thinking about what I was doing.

I'm glad you were in the right frame of mind at the right time. I don't think there's anything quite like PyGeo out there. It's still too new to have imitators. Is it explicitly GPL'd? I don't remember. I think you'd be pleased if some 15 year old started hacking into it, yes?

Parathentically, the difficulty with OOP is spoken about, in things I have stumbled across, as a Circle and Ellipse problem (I think I have this right). Being a form of the Chicken and Egg problem.

I'm not familiar with this particular critique. So I'll take the bait. Seems the ellipse would be the more general case, with the circle being a special case of ellipse, kind of like the square is a special case of rectangle. In the typical Venn Diagram, the squares go inside the rectangles, so circles should go inside the ellipses.

Interestingly, to me, thinking in terms of Projective Geoemetry, the issue evaporates. Since they the Circle and Ellipse are projectively equivalent. And one would not expect to be able to derive one from the other. They are the same thing, different spelling.

Art

Ah so. So maybe it's not an issue of deciding which inherits from which. There's only one class here. Likewise with the triangle. Can I get any triangle I want from the equilateral, depending on how I project? I'm experiencing an upwelling of ignorance re something so basic, turned spontaneously to Google, only to become side-tracked by http://www.geocities.com/moonhoabinh/chatter.html ... Perhaps you have the time to give us some pointers re triangles in projective geometry. Any PyGeos already done on that topic? Kirby

At 10:07 PM 6/30/2003 -0700, Kirby Urner wrote:

...

...

...

p1 [['A', 'W', 'Z', 'R', 'N', 'G'], ['C', 'Q', 'S', 'X', ' ', 'B', 'M'], ['E', 'V', 'L'], ['D', 'K', 'J', 'O', 'Y', 'P', 'H', 'T', 'U', 'F', 'I']]

Using cyclic notation e.g. A goes to W, W to R and so on.

Goofed again. A to W, W to Z, Z to R and so on (G to A). I use the random.shuffle(list) function to jiggle the letters and make the permutation. def simplecode (elems): neworder = elems[:] # make copy random.shuffle(neworder) return dict( zip(elems, neworder) ) The letters are just: letters = list(string.ascii_uppercase + ' ') Better quit now, before this thread becomes a never ending erratum. Kirby