[Edu-sig] Hello from a CS Teacher

Kirby Urner pdx4d@teleport.com
Fri, 11 Feb 2000 16:59:48 -0800


Steve Morris writes:
>I know I am talking about a moderately big project (although not as
>big as you might think, and much of it might already be available)
>with a longer payback cycle and will likely get snide comments about
>vaporware, however I think it is worth some thought. It will certainly
>never happen if it doesn't get discussed. If it gets beyond discussion
>into some specific proposals I am willing to help.

I don't have any problem with such brainstorming myself 
-- sounds like you'd be able to make a serious dent in 
such a project.

Another approach is to use Python code to dissect this 
whole notion of object-based simulations.  Write some 
simple "cave paintings" that give the _idea_ of how a 
simulation is designed and built, one that actually 
runs somehow -- but doesn't do anything super fancy.  

Then turn to other off-the-shelf software for the jazzier
simulations, including even SimCity and SimAnt.  Maybe
view a documentary on airplane design and see how real
engineers use a combination of computer models, wind 
tunnel experiments or whatever it is they do.  After all,
we're just physics students here, not airplane engineers.
Bernoulli's principle is what's important to us, not the 
nitty gritty of real world wing design.

In this scenario, the role of Python is to "sketch" ideas
about simulations, about objects, to provide clear windows 
into a world of much greater complexity.  But you maybe 
don't actually need to write any new "bouncing molecules"
application -- because maybe you find Java applet that 
does this already and play with that.

On the other hand, I think what students _really_ need to 
understand (and don't, for the most part) is that "collision 
detection" is a generic problem which many have tackled. So 
learn enough relevant concepts to be able to poke around 
in a website like: 

       http://www.win.tue.nl/cs/tt/gino/solid/

Get the flavor of that world, the fact that we have all
these algorithms already out there.  The goal is really
_reading comprehension_:  the ability to scan websites 
such as the above and not disconnect, not throw up your
hands and say "oh god, I'll _never_ understand _any_ of
this".  On the contrary, you're getting more confidant 
around this kind of stuff by the day (our curriculum
is working).

My sense is that we're already awash in exciting, usable 
software.  There's just a ton of stuff out there.  What's
missing is a graduated, user-friendly on-ramp that makes
a lot of this stuff clear _conceptually_.  The bottleneck
is not in the raw materials department, but in the lack 
of good, clear curriculum materials which take advantage 
of our embarrassment of riches.  We're awash in goodies, 
but at a loss about how to integrate them _conceptually_ 
-- because over-specialized approaches have such a 
strangle-hold these days.

I think Python has the potential to help us elucidate 
what's going on in the guts of our simulations, whether or 
not those simulations are actually written in Python or 
not.  

Plus, as a kind of algorithm-specifying notation, we can write 
very simple executables to spell out a lot of basic math ideas.
For example, below is something I wrote just now to generate 
a list of prime numbers.  It's the age-old Sieve of Eratosthenes
(circa 200 BC).  We teach this stuff anyway.  

I'm sure others posting to this list have done lots of similar 
experiments. It'd be good to start building a library of 
modules that classroom teachers and/or home-schoolers (of any
age group) could use (in part simply as examples to get them 
going -- as more teachers warm to the idea of Python in the 
classroom, they'll start "rolling their own").  

I'm looking for ways to get the snowball rolling.  Then it'll 
just get bigger as it gathers momentum.

Kirby

MODULE:  seive.py

primes = [2]    # dynamic list of primes

def get2nb(nbprimes):
   # return list of primes
   # nbprimes = number of primes to list

   global primes  # keep at module level for re-use

   # chop the list if already longer than we need
   if len(primes)>nbprimes: primes = primes[:nbprimes]

   # start with highest prime so far
   i = primes[-1]

   while len(primes)<nbprimes:
       if addprime(i): primes.append(i)
       # skip even numbers (only 2 is prime)
       if i==2: i=i+1
       else:    i=i+1

   return primes

def addprime(n):
   # internal seive to check whether a number is prime

   verdict = 1   # default is "yes, add to list"

   for i in primes:
        if (i==n) | (n%i == 0): # is prime or no remainder
           verdict = 0          # so we _don't_ want to add
           break
        if i**2 > n:            # stop trying to divide by
           break                # lower primes when p**2 > n

   return verdict

In action:

>>> reload(seive)
<module 'seive' from 'G:\Python\seive.py'>
>>> seive.get2nb(10)
[2, 3, 5, 7, 11, 13, 17, 19, 23, 29]
>>> seive.get2nb(5)
[2, 3, 5, 7, 11]
>>> seive.get2nb(30)
[2, 3, 5, 7, 11, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 
53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, 109]