[Edu-sig] Pythonic Math must include...

[kirby urner]

On Sat, Jan 17, 2009 at 5:40 PM, Gregor Lingl <gregor.lingl at aon.at> wrote:
>
>
> kirby urner schrieb:
>>
>> Yes thank you I completely agree.  A stash of sieves, plus data mine
>> this very archive for our earlier work on this topic.
>>
>> My only suggestion is you include a generator version e.g.:
>>
>
> At first this seems an attractive idea, but in my opinion the
> idea of sieves is fairly antagonistic to that of generators.
> A sieve  is used  to eliminate  from a given set elements
> that have not some desired property, while generators
> (ideally) create  objects, one at atime,  with that desired
> property. Drastically: you cannot sieve at first all even
> numbers from an infinite set or sequence. For educational
> purposes I'd prefer examples that display a single concept
> in a small and simple way. :-*  A prime number generater
> based on some different algorithm of course may be
> interesting and useful.

Yes sir!  Excellent clarification.  The goal is to have a worthy
generator that always gives the next prime.  "Trial by division" is
the simplest approach I can think of...

>>> def primes():
	sofar = [-1, 2,3] # a running start, -1 proposed by J.H. Conway
	yield sofar[0] # get these out of the way
	yield sofar[1] # the only even prime
	yield sofar[2] # and then 3
	candidate = 5 # we'll increment from here on
	while True: # go forever
		for factor in sofar[1:]: # skip -1 (or don't use it in the first place)
			if factor ** 2 > candidate:  # did we pass?
				yield candidate # woo hoo!
				sofar.append(candidate) # keep the gold
				break  # onward!
			if not candidate % factor: # oops, no remainder
				break  # this is a composite
		candidate += 2 # next odd number please

		
>>> g = primes()
>>> next(g)
-1
>>> next(g)
2
>>> next(g)
3
>>> next(g)
5
>>> next(g)
7
>>> next(g)
11
>>> next(g)
13
>>> next(g)
17
>>> next(g)
19
>>> next(g)
23
>>> next(g)
29
>>> next(g)
31
>>> next(g)
37
>>> next(g)
41

I think you're correct that the sieve best works with a pre-specified
finite domain:  sieve it completely, using divisors <
math.sqrt(len(domain)) then iterate over it maybe, but the array is
already populated, taking up memory.  The above generator, in
contrast, gradually takes up more memory (shows what generators are
good for then: saving state between cycles).

> To continue work in this area one (or at least me) has to have
> some criteria to judge the solutions.
> Clearly it was advantageous if there was some consensus about
> these criteria in the community.

Fortunately, we have hundreds of years of math pedagogy, so in terms
of avoiding quarrels, start with what's already on the books are "must
have" and just render it Pythonically.

So, for example, every pre-college math curriculum I'm aware of makes
the distinction between prime and composite numbers.

On the other hand, few include the Fermat test or Fermat's Little
Theorem, don't have RSA as a goal.  So whereas generators for primes,
fibonaccis, pascal's triangle, would seem non-controversial, anything
having to do with Fermat's Little Theorem would seem an uphill battle,
especially without buy in on the RSA bit.

What makes a lot of this stuff more accessible than before is we have
the ability to work with large numbers of digits.  Both text books and
calculators tend to crap out at more that 15 significant figures.  Not
so in Python or any significantly endowed language.  2 ** 10000 is no
problem for us, is for the paper and pencil crowd, or the TI crowd
(both pitiable).

I don't think there's a way to avoid quarrels.  People have different
leadings, throw their hats in the ring, and we see what synergies
develop.  My goal is to keep the process open and participatory, not
to close it down.  The sight of people debating is far less disturbing
than the sight of everyone in lockstep (the Borg).

>
> There should be some criteria concerning
> (a) the choice of problems and themes,
>    e.g. to prefer small problems that expose a single idea  -  or rather not
> ...   etc.,
> as well as some
> (b) code related criteria, like clarity, conciseness, efficiency, beauty (!)
> etc., ranked according to
> their priorities.

This will be up to each professional teacher in whatever walk of life
-- to judge what to include and what to exclude.  Each teacher will
find her or himself in agreement with some, disagreement with others,
over what to include.  Twas ever thus.

What to avoid, in my book, is a restrictive environment which takes a
one size fits all approach and dictates to all teachers how it must
be, removing much individual freedom.

Reduction in biodiversity is dangerous in my estimation.

That's why I fight against "national curriculum" ideologues on the
Math Forum, other places.

> Once I had the following idea: there are so many renowned pythonistas
> in the developers community, many of them also interested to promote
> Python in the educational area (see for instance the protagonists in
> Jeffrey Elkners "Introducing Python"). How about to ask them to make
> a personal donation to the educators and learners: a piece of code,
> 10 to 12 lines at most, that they individually consider  to  show most
> convincingly the power or the beauty of programming with Python -
> or the fun they have with it. Young people like role models ;-)
>

That's a fun idea.

Another approach is to start some schools in which Python is defacto
included as an important tool in the math curriculum, and compete with
other schools that make different choices, see how that goes.

Don't try to "convince the world" before starting your experiment.

You need no one's permission to take the initiative.

Individuals make all the difference in this world, alone and in groups.

> Regrettably I didn't persue that idea further. What do you think of it. Ok,
> the days of the early pioneers are over, but perhaps it's still worth a try?
>

I think the first generation of Pythoneers, counting myself as one of
them, should be collecting momentos and souvenirs, as soon enough our
generation will no longer be heard from, in terms of contributing new
material.

Your idea reminds me of the recipe book they made for Bucky Fuller,
his many friends contributing their favorites.

Looking back at 2008, random geek viewpoint:
http://www.iht.com/articles/2008/12/22/arts/design22.php

Kirby


> Regards,
> Gregor
>
>
>
>
>
>>
>> Using Python 3:
>>
>>
>>>>>
>>>>> g = Primes()
>>>>> next(g)
>>>>>
>>
>> -1
>>
>>>>>
>>>>> next(g)
>>>>>
>>
>> ....
>>
>