[Edu-sig] Learning Math or Simulation with Python or Smalltalk

[Paul D. Fernhout]

Andreas Raab wrote:
> tri
>      " triangular num n "
>      " = sum of n consecutive counting nos (n>=1) "
>      n <= 1
>        ifTrue:[^n]
>        ifFalse:[^n + (n-1) tri]

Perhaps a Smalltalk could be changed to accept from a workspace the following?

Integer>>tri
   self <= 1
     ifTrue: [self]
     ifFalse: [self + (self - 1) tri]

There is a bug with the use of "n" I think in your example? This 
modification also eliminates the return, as it is implied as being the 
result of #ifTrue:ifFalse: and also as it is the last statement in the 
method. Python needs the return however.

I guess I actually don't see this "if" as control flow, by the way, more 
as result calculation, so the lack of a preceeding if does not bother me 
in this case. But I agree with you that since the "f(x)" style is how 
conventional math is taught, "x f" could be disconcerting. The question 
then is, how far would "gnu math" be willing to depart from current 
mathematical conventions? :-)

For fun, another approach using imaginary Self-like Smalltalk prototypes. :-)

=====

Calculator := Proto new.

Calculator at: #tri: put:
   [:n |
   "triangular num n = sum of n consecutive counting numbers (n>=1)"
   n <= 1
     ifTrue: [n]
     ifFalse: [n + (self tri: n - 1)]
   ].

Calculator at: #sqr: put:
   [:n |
   "square num = sum of 2 consecutive triangular numbers "
   n <= 1
     ifTrue: [n]
     ifFalse: [(self tri: n) + (self tri: n - 1)]
   ].

(Calculator tri: 20) print.
(Calculator sqr: 4) print.

======

So, you could select this code in a Workspace and pick "do it".

But, explaining the use of brackets to novices could be awkward, as they 
need to understand a level of abstraction related to deferring a computation.

If one could integrate Python-ish identational syntax into Smalltalk 
somehow, one could have:

Calculator at: #tri: put:
   :n
   "triangular num n = sum of n consecutive counting numbers (n>=1)"
   n <= 1
     ifTrue:
	n
     ifFalse:
	n + (self tri: n - 1)

where indenting a subsequent line implied a block, except when it began 
with a keyword (not sure that covers all cases though, or if it does not 
create other problems). Generally I Smalltalk doe snot need indentational 
syntax as much as Python does, because methods are typically short and 
managed in a browser, whereas Python functions are often long and managed 
in a text editor with perhaps hundreds or thousands of lines in one file.

In PataPata, this could be done as:

=====
import Prototypes
Calculator = PrototypeClass()

def tri(self, n):
     # triangular num n
     # = sum of n consecutive counting nos (n>=1)
     if n<=1: return n
     else: return n + tri(n-1)
Calculator.tri = tri

def sqr(self, n):
     # square num = sum of 2 consecutive triangular nos
     return sqr(n) + sqr(n-1)
Calculator.sqr = sqr

=====

Or as:

=====

import Prototypes
world = PrototypeClass()
class Calculator:
   __metaclass__ = world.buildPrototype
   def tri(self, n):
     # triangular num n
     # = sum of n consecutive counting nos (n>=1)
     if n<=1: return n
     else: return n + tri(n-1)

   def sqr(self, n):
     # square num = sum of 2 consecutive triangular nos
     return sqr(n) + sqr(n-1)

=====

Still, a lot more extra stuff than Kirby's orignal:

===

From: http://www.4dsolutions.net/ocn/numeracy0.html

def tri(n):
     # triangular num n
     # = sum of n consecutive counting nos (n>=1)
     if n<=1: return n
     else: return n + tri(n-1)

def sqr(n):
     # square num = sum of 2 consecutive triangular nos
     return tri(n) + tri(n-1)

====

But, it is also doing more. Kids spend tens of hours learning to type. Why 
should we expect them to be doing math from the first minute? Maybe the 
issue is that kids need to learn about levels and abstraction and pointers 
first? When I taught C programming to Bio majors I spent a lot of time in 
the first classes getting the college kids to point to each other and 
follow that around the room, and to pass string around, and so fort. The 
reason is I knew that pointers were the hardest part of C programming, and 
so I started with that fairly early on (Well, after a bit of turtle stuff, 
and getting kids to pretend to be turtles, or trying to. :-) Then I spent 
hours in the computer lab with them. (To answer a question Kirby asked 
previously on teaching style.)

Again, both the Smalltalk-sh prototype code and the PataPata example are 
doing more -- by building objects which respond to messages. But whereas 
Kirby starts with recursion as important (levels of nesting), from a 
Smalltalk-ish OO point of view  (and by extension, OO simulation) getting 
kids to understand the abstraction of objects receiving and processing and 
sending messages may be seen as more important. :-)

One of the problems of teaching programming is that many kids need to 
learn the very basics sometimes. For example, that is one reason learning 
to play music at an early age may be better for building a programmer than 
actually learning to program first. Learning to read sheet music to play a 
song on an instrument creates a simple experience where kids can learn a 
correspondence between marks on the paper and some process going on 
producing something of value. That "text to process" abstraction is the 
biggest abstraction kids need to learn to program (even if the "text" is 
some other form of eToy symbols). But after that definitely understanding 
a "levels of nesting" abstraction is important. Kirby's example gets at 
levels in a sense by focusing on recursion in the first example (I guess 
he can assume his particular kids know the text to process abstraction 
already?). Still, one might argue from an OO (and simulation) point of 
view that understanding the abstraction of message sending is more 
important than the abstraction of levels of nesting? Guess it depends what 
you are emphasizing -- math or simulation? (Now some forms of simulation 
are highly mathematical, so it isn't either/or, of course, but one of 
emphasis).

I think it likely that 75% of the college biology majors I taught 
way-back-when would have been hopelessly lost after Kirby's first example. 
  :-) Many bio majors choose that major so they (presumably) don't have to 
do any abstract math. This can be a big problem for them as advanced bio 
can be very mathematical, and which is why I as a mathematical kid did 
well taking an advanced college bio class even with little knowledge about 
college bio at the start and skipping all the intro courses (the real bio 
majors freaked out at seeing an integral on the chalkboard).

 From my own experience years later, it's a problem having a mixed bunch 
of students in a programmign course -- a separate issue relating to 
educational bureaucracies -- but how to do you teach a a programming class 
where 25% of kids have not used a computer, 25% know word processing, 25% 
know BASIC, and 25% already probably know the language of interest? For 
me, the only thing that worked somewhat was a lot of time in the computer 
lab providing essentially individualized instruction to one to three 
people at a computer or two at a time. I think that level of interaction 
is more important than the specifics of the curriculum (not to say a good 
text book or curriculum is not of value). Frankly, I'm a poor "classroom" 
teacher; doing that well is a skill I don't have requiring some good mix 
of showmanship and prepared pedagogy and projected authority. But put me 
in a computer lab with doing hands on stuff with a few kids at a time, and 
then it is a good match, because I am building on my (consulting) strength 
of being able to help people get past specific programming stumbling 
blocks to do really neat things they want to do.

As Andreas points out, Smalltalk has different stumbling blocks than 
Python for teaching mathematics. Can one learn from the other?

Anyway, when I look at Python for education, I ask myself (theoretically 
these days, which could be a problem, as Kirby points out) what stumbling 
blocks would a kid (or anyone, especially myself :-) have to using Python 
to make a GUI (or core code) for a simulation, and I want to remove those 
as best as I can (PataPata is one attempt). That's one difference from 
Kirby's interests and mine -- I'll agree based on the above Python 
as-it-is (rather than using Smalltalk syntax) is a good vehicle for 
teaching mathematics the way he does it, and a gentler way (at least at 
first) for today's kids who already learn a certain notation. :-) Both 
Smalltalk and PataPata (Python prototypes) require a bigger first leap for 
that. But, my interest is more to get kids building simulations, where the 
math is incidental (though eventually important of course). So, I 
encounter different stumbling blocks than Kirby would. For me, issues 
like, how do we define a set of parameters and easily display and 
manipulate them with a GUI is a stumbling block in Python. As is, how do 
we define an object on the screen that responds to messages by moving? 
These are things which Squeak (or Squeak with eToys) does fairly easily, 
by contrast. So, if a different notation is a stumbling block in Smalltalk 
for mathematics, GUI building and inspecting state is a stumbling block in 
Python for simulation (not that you can't do it, just that it is perhaps 
harder than it has to be).

--Paul Fernhout