[Edu-sig] Freedom: some Smalltalk history and Python implications
kirby.urner at gmail.com
Fri Aug 11 22:43:28 CEST 2006
On 8/11/06, Andreas Raab <andreas.raab at gmx.de> wrote:
> Not knowing what is easy for you that question seems a little hard to
> answer (also I'm thinking we're getting somewhat off-topic here). There
Think of my 8th graders that I'm trying to give a first exposure to a
geometric interpretation of vector arithmetic.
We have the lexical mechanics, thanks to the Vector class definition,
but now it's time to bind this arithmetic to a visualization in some
In VPython, you hand off the a builtin visual.vector object and you're
done. With POV-Ray, it's a little more complicated: use the cylinder
for your edge.
> are different ways in whic you can go about this problem:
> a) Using an immediate mode interface where you truly "draw yourself".
> For the (older) Squeak 3D engine we have an interface that is similar to
> OpenGL (in such that it supports very similar operations like submitting
> vertices, normals, colors etc.) and in Croquet everything is built
> directly on top of OpenGL. For the immediate mode interface there is a
> pretty nice tutorial included with Balloon3D.
It sounds like all the machinery is there (OpenGL is what VPython sits
on as well). My question is more to the look of the code. How
complicated to get into visual interpretations of expressions with
vectors, now that a vector class has been defined.
> b) Using a retained mode interface, e.g., constructing a polygon mesh
> and simply visualizing that. In this case you would probably use
> Wonderland as it provides some nice high-level animation facilities.
I'm not going for a lot of swooshy effects, just a close tie-in
between lexical and graphical content. I want the algebra of
sequences to move them smoothly through XYZ thinking, to simple
expressions of geometric objects, such as polyhedra. All should be
code driven (so they see how their vectors work).
In Python, I might give them a module with several polyhedra pre-coded
(we can study the source later). They do something like this:
>>> from rbf import Icosahedron
>>> myIcosa = Icosahedron()
>>> scenefile = POVwriter("thefile.pov")
At this point, thefile.pov will have all the scene description
language needed to render a pretty Icosahedron:
> > How do I draw an Icosahedron using Squeaks built-in 3D vector graphics engine?
> Not sure what you're looking for here. Do you want to see some actual
> code? Or are looking for general advice?
I'd like to get the flavor of the actual code, either out of the box
in Squeakland, or after a teacher has written the necessary code to
help students get started.
What would it look like to just get a simple tetrahedron in some
OpenGL context. Do I need to extend pre-existing classes some how?
The goal is to involve my new Vector class in some easy way, so that
students make the connection between lexical vector arithmetic, and
> >> Operators are just binary messages in Smalltalk, which reminds of
> >> another issue that is often a stumbling stone early on: No operator
> >> precedence. All binary operations are evaluated strictly left to right
> > How about operator overloading. That's pretty easy right? Like what
> > we do with __add__.
> Well, yes, that's what I said. Operators are just messages, you treat
> them like anything else. If you want to implement addition using "+" you
> just implement a message with the name "+" that's all.
OK, thanks. Some other sources were making it sound like operator
overloading wasn't a feature of Smalltalk. Sounds like its easy, and
more like in Ruby, where you use a literal + to overload + (vs.
something like __add__).
> > But there *is* a way to have + trigger vector addition yes. I was a
> > bit unclear when you went:
> >> v1Plus42 := v1 + 42.
> >> v1Plusv2 := v1 + v2.
> > How did you get that + behavior in Squeak?
> By implementing it in the Vector class. Here is a simplified variant of
> how this may look:
> Vector>>+ aNumericObject
OK, so this use of + is where we begin the overloading definition I take it...
> aNumericObject isNumber
> ifTrue:[^self scalarAdd: aNumericObject]
> ifFalse:[^self vectorAdd: aNumericObject].
> and then:
> Vector>>scalarAdd: aNumber
> x := x + aNumber.
> y := y + aNumber.
> z := z + aNumber.
> Vector>>vectorAdd: aVector
> x := x + aVector x.
> y := y + aVector y.
> z := z + aVector z.
> The case analysis in Vector>>+ can be quite annoying so often there are
> other techniques (like double-dispatching) used to implement the proper
> coercion. The common technique currently used by Squeak coerces based on
> generality, so to implement the "reverse" set of operations you'd do, e.g.,
> Vector>>adaptToNumber: aNumber andSend: aSymbol
> "If I am involved in arithmetic with a scalar, return a Vector of
> the results of each element combined with the scalar in that
> x: (x perform: aSymbol with: aNumber)
> y: (y perform: aSymbol with: aNumber)
> z: (z perform: aSymbol with: aNumber)
I'd simplify this to not allow addition of scalars to vectors. Only
vectors add to vectors, plus scalars multiply them (but vectors don't
multiply with vectors).
> But now we're *really* getting off topic. If you are interested in these
> issues I'd recommend asking questions here:
This isn't off topic at all from my point of view. Pythonic
mathematics dives into operator overloading pretty much immediately.
If I were to convert my curriculum to Smalltalk, I'd need to bone up
on precisely these details, so thank you.
> >> E, V, F? Don't know that lingo ;-)
> > E = Edges, V = Vertices, F = Faces. Euler's V + F = E + 2 is his law
> > for polyhedra (the +2 goes away if you do a donut, or is +1 on a flat
> > surface). This is where topology enters our curriculum (with Euler).
> Oops, how embarrassing. It's been so long for me that I didn't even
> recognize it. Of course I do (or should I say I did ;-) know that lingo...
> - Andreas
Some complain about the "dumbed down" kind of vectors we do, but
remember, this is a first pass.
All our vectors have their tail at the origin, so if you want a line
segment (vs. a vector) you need *two* vectors to specify it, one
pointing to each end.
It's these line segments we identify with Edges when doing polyhedra.
Polyhedra get defined as face-tuples. That's the necessary topology
right there, with each element of the tuple a reference to a vector.
Polyhedra are of course the next class we get into, once we have our Vectors.
More information about the Edu-sig