On Sat, Jan 17, 2009 at 5:40 PM, Gregor Lingl <gregor.li...@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) >>>>> >> >> .... >> > _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig