Mailman 3 January 2009 - Edu-sig

another "must have" generator
by kirby urner 27 Jan '09

27 Jan '09

This is just to get junior experimenting with convergence / divergence on the complex plane. c is our variable. Per this Wikipedia article (fine to project in class, why not, though "teacher reading from encyclopedia" shouldn't come off as mechanical): See: http://en.wikipedia.org/wiki/Mandelbrot_set Also: http://www.4dsolutions.net/ocn/fractals.html IDLE 3.0a2 >>> def mandelbrot(c): z = 0 + c while True: yield z z = z ** 2 + c >>> c1 = mandelbrot(1) >>> next(c1) 1 >>> next(c1) 2 >>> next(c1) 5 >>> next(c1) 26 >>> next(c1) 677 >>> ci = mandelbrot(1j) >>> next(ci) 1j >>> next(ci) (-1+1j) >>> next(ci) -1j >>> next(ci) (-1+1j) >>> next(ci) -1j >>> next(ci) (-1+1j) >>> Taking inventory of what I have so far in my Python toolkit: Figurate Numbers Pascal's Triangle (triangular and tetrahedral numbers) Fibonacci Numbers (converge to phi, pentagon math) Vectors (VPython -- xyz, spherical coordinates etc.) Prime Numbers (sieves) Prime Numbers (trials by division) Polyhedra (as Python objects: scale, rotate, translate) Polyhedral Numbers (icosahedral, geodesic spheres) Modulo Numbers (override __mul__, __add__) Finite Groups (Python module) Euclid's Algorithm (Guido's gcd) Euclid's Extended Algorithm (needed for inverses) Totient and Totative (gcd based) Fermat's Little Theorem (assert...) Euler's Theorem for Totients (assert...) Mandelbrot Set (chaotic sequences) Miller-Rabin (or Jython probablePrime) RSA.encrypt(m, N) RSA.decrypt(c, N, d=secretkey) ... I've ordered these roughly in sequence of first encounter, assuming numerous loop-backs and repetitions (Saxon a good model -- called spiraling with scaffolding), thinking roughly grades 9-12, though some adults will do this sequence as a refresher or first time exposure to basic numeracy. This is in no way a complete list, just a smattering of dots, curriculum "nodes" as it were. For some of it, I'd expect to switch more into a "music appreciation" mode i.e. we spend too little time explaining why on earth we do so much around polynomials, make them an in-depth vocational exercise without promising anything specific about their job relevance. When was the last time any of you needed to factor a polynomial for work, and couldn't use Mathematica? Time was, if you lived in Pisa and could factor a 3rd or 4th degree polynomial of a specific form, you could attract a patron for a kind of cerebral cockfighting that went on. """ In 1530, Niccolò Tartaglia (1500-1557) received two problems in cubic equations from Zuanne da Coi and announced that he could solve them. He was soon challenged by Fiore, which led to a famous contest between the two. Each contestant had to put up a certain amount of money and to propose a number of problems for his rival to solve. Whoever solved more problems within 30 days would get all the money. Tartaglia received questions in the form x3 + mx = n, for which he had worked out a general method. Fiore received questions in the form x3 + mx2 = n, which proved to be too difficult for him to solve, and Tartaglia won the contest. """ [ http://en.wikipedia.org/wiki/Cubic_equation ] The lack of an historical dimension in modern math teaching is just another symptom of out-of-control overspecialization, what we're seeking to counter with these more integrative approaches. Moving to executable notations is a clear sign of the times, ample evidence that "time marches on", so it makes sense that we're more time-aware, no longer supposing that the grade school math of our grandparents is the math of our children. Since when did time stand still? I've got more ideas for offering refresher numeracy courses to adults at the Math Forum. A lot of the focus will be instructional game playing on LCDs, sometimes with real money involved, definitely working towards credentialing i.e. adding scores to transcripts, which implies access to testing centers. The coffee shop may still be the best place to study, bone up for that job interview. http://www.youtube.com/watch?v=bfgO-LXGpTM Kirby

3 5

New Python book by J. Zelle and D. Reed (woo hoo!)
by kirby urner 24 Jan '09

24 Jan '09

On Fri, Jan 23, 2009 at 3:45 PM, jim leisy <jimleisy(a)fbeedle.com> wrote: > Hi there, Kirby--Happy 2009. Obama says it all. > > FYI--we have published a book that transitions from a first course using > Python to a data structures course using C++. > The title is Data Structures and Algorithms using Python and C++. David Reed > and John Zelle are the authors. Here is the > book's web page: www.fbeedle.com/2335.html > > Jim > > Jim Leisy > Publisher > Franklin, Beedle & Associates Incorporated > William, James & Company > www.fbeedle.com www.wmjasco.com > 503-682-7668 voice > 503-682-7638 fax > 800-322-2665 Toll Free in USA > > 8536 SW St Helens Drive, Suite D > Wilsonville, Oregon 97070 USA > Hi Jim -- Excellent, a promising approach to a language we'll be using for a long time to come (fast system languages won't be re-invented on a whim). I know John Zelle as one of the best Python teachers in the business, right up there with Bruce Eckel and Alex Martelli, but with a lot more Tk, an under-valued library -- so yes, a good 2 part sequence, core Python with Tk, then a CS2 dive into C++, the basis of wx and much other Pythonic collateral. Java and C# will seem easy in comparison, but won't always be the right tool for the job. I like the cover, reminds us that nature out-processes us all, data-wise -- glad we get a niche. We'll maybe see you at OS Bridge? I've been in on some of the meetings, don't know the publisher exhibiting angle yet, hoping to give Portlanders something to chew on, in the absence of a PDX OSCON. http://bridgepdx.org/ Also looking forward to the flying circus at Pycon again (no plane ticket yet): http://mybizmo.blogspot.com/2008/10/pythonic-math.html "Obama" sounds a lot like "Ubuntu" in translation (community spirit, hope). Kirby Urner 4dsolutions.net cc: edu-sig

1 0

Another lesson plan (Euler's Theorem) from OCN / CSN
by kirby urner 23 Jan '09

23 Jan '09

So here's more computer algebra, ready for phase-in, base camps in the Columbia Gorge (like computer camps for girl scouts, astronomy encouraged). You can project computer languages around the campfire if you have the right equipment, bed sheet between trees, but that's really a lot of work probably, thinking ahead to Montana (NPYM). Might just all download the same Podcasts and watch separately, when the time comes (still a group storytelling experience). OK, so here's the shell session, nothing spectacular, just another one of our "theorem checkers" using try/except around an assert, something we expect to always be true, provided stipulations get met. Here's what's interesting: the last example craps out, not because of the newly added __pow__ method, which is optimized internally for modulo powering (special algorithm per Knuth, Tim Peters confirming it's in Python) but because my totatives function is completely inefficient. The preferred pipeline for totient, memorialized in my ray-tracing of that formula for phi (Euler's preferred right?), in that paper with K. Iverson, was to show the prime factors approach, much more affordable (once you get those prime factors, let's not bleep over): http://www.4dsolutions.net/ocn/graphics/phistone.jpg http://www.4dsolutions.net/ocn/Jlang.html Ah, but getting prime factors is a hard problem, or can be, whereas my little engine starts up the Himalayas at a snail's speed, breaks before getting to the summit. But that's really OK. We're exploring the meme pool, and time/energy *is* a factor, as Gregor so eloquently riffed about. We accept that a conceptually clear algorithm may be impracticable in some real world situations, want students hip and alert to that fact. Let's be clear: sometimes we just *don't have* any algorithm for job x, that'll work in your life time. Because of proofs in mathematics we're able to be up front about that, tell the brat emperor when there's just no way (in theory anyway, gets dicey sometimes). The flip side of that shortcoming is we have pretty good privacy when we need it. So, without further ado: >>> from algebra import * >>> euler_checker(217, base=5) True!: pow(5, 180, 217) == 1 >>> euler_checker(17) True!: pow(2, 16, 17) == 1 >>> euler_checker(13452199029039023920, base=2) Pick a different base please >>> euler_checker(13452199029039023921, base=2) Traceback (most recent call last): File "<pyshell#47>", line 1, in <module> euler_checker(13452199029039023921, base=2) File "/home/kirby/algebra.py", line 37, in euler_checker totient = len(totatives(N)) File "/home/kirby/algebra.py", line 9, in totatives return [ x for x in range(1, n) if gcd(x, n) == 1] File "/home/kirby/algebra.py", line 9, in <listcomp> return [ x for x in range(1, n) if gcd(x, n) == 1] File "/home/kirby/algebra.py", line 5, in gcd a, b = b, a % b KeyboardInterrupt ============= from random import choice def gcd(a,b): while b: a, b = b, a % b return a def totatives(n): return [ x for x in range(1, n) if gcd(x, n) == 1] class Modulo: m = 12 def __init__(self, n): self.n = n % Modulo.m def __mul__(self, other): return Modulo(self * other) def __pow__(self, n): return Modulo(pow(self.n, n, Modulo.m)) def __eq__(self, other): return self.n == other.n def __repr__(self): return str(self.n) def closure_checker(pool): while True: a, b = choice(pool), choice(pool) result = a * b assert result in pool yield "%s * %s == %s" % (a, b, result) def euler_checker(N, base=2): """ a check (not a proof) of Euler's Theorem """ if gcd(base, N) == 1: # coprime? totient = len(totatives(N)) try: assert pow(base, totient, N) == 1 print("True!: pow(%s, %s, %s) == 1" % (base, totient, N)) except: print("False!: pow(%s, %s, %s) != 1" % (base, totient, N)) else: # (base, N) not coprime print("Pick a different base please.") Kirby Urner Abbreviations decoded: OCN: Oregon Curriculum Network (4dsolutions.net/ocn) CSN: Coffee Shops Network (YouTube commercial: http://www.youtube.com/watch?v=0Oad0libltM special thx to jimmlott.com, and csn.cto nirel) Here's another geeky YouTube commercial I like, for Ruby on Rails: http://www.youtube.com/watch?v=91C7ax0UAAc&feature=rec-HM-fresh+div (more from Python Nation? -- still needing judges for 'The Writhe' contest: http://mybizmo.blogspot.com/2008/10/ppug-20081014.html )

1 0

Re: [Edu-sig] Topics for CS2
by David MacQuigg 23 Jan '09

23 Jan '09

At 09:33 PM 1/22/2009 -0800, Edward Cherlin wrote: >On Thu, Jan 15, 2009 at 3:09 PM, David MacQuigg wrote: >> I'm putting together a list of topics for a proposed course entitled "Programming for Scientists and Engineers". See the link to CS2 under http://ece.arizona.edu/~edatools/index_classes.htm. This is intended as a follow-on to an introductory course in either Java or C, so the students will have some exposure to programming, but the Java students won't know machine-level programming, and the C students won't have any OOP. For the proposed course, we will use the example programs as a way to introduce these topics. > >Earth Treasury might be interested in working with you on this, if you >are willing to have it distributed under a Free license in multiple >languages. No problem. >We are working on teaching Computer Science ideas in an >age-appropriate manner on the OLPC XO starting in third grade, or if >possible earlier, using Smalltalk, Turtle Art, Logo, Python, and other >powerful tools, and continuing through 12th grade at least. We will >also be using the XO's digital oscilloscope capability (Measure >Activity) to teach science and engineering. I could see some of these CS2 programs being useful for high-school students, especially if they have already learned a computer language. No reason they can't be at the same level in programming as college students in the USA. >The outline of our project, with the names of our confirmed partners >and a few prospective partners we are talking with, is at >http://wiki.sugarlabs.org/go/Creating_textbooks. I had no idea these little laptops could run Linux. Cool. -- Dave

2 1

Re: [Edu-sig] Topics for CS2
by David MacQuigg 23 Jan '09

23 Jan '09

At 08:45 AM 1/20/2009 -0800, kirby urner wrote: >On Tue, Jan 20, 2009 at 1:52 AM, David MacQuigg wrote: >> There may be some misunderstanding as to my purpose in writing this chapter. >... > >On a scale of 1-10, overriding __del__ in the process of doing >subclass instance counting in a parent class, is like 8 or 9, >especially where you bring __mro__ into it. So yes, I see your desire >to include arcana. You're being respectful of your students' already >high level of initiation. All this is in the "Advanced Topics" section at the end. I probably should make that a separate chapter to avoid any distraction. The part I expect students at the CS2 level to understand is in the first 12 pages, and that should be free of arcana. ... >But in Python, everything is a snake, a live object, including numbers >like 1 and 2, and they have knowledge of addition and multiplication >"in their bones" (__ribs__). When you go 1 * 2, that's not a space >ship, bristling with static methods from on high, from the alien >"knows operations" land, that's invoking an innate ability of the >integer type. > >It's a change in gestalt, especially if you start with the old one. ... >> As for making OOP a "revelation", I think that is the wrong way to teach it, especially for non-CS students. I much prefer to treat it as just another way to encapsulate pieces of a program, a way that is very natural when you are modeling objects in the real world, and can be beneficial even when there is no parallel in the real world - the benefit flowing from the extra flexibility you have in encapsulation. That is something all engineers will understand. The "revelation" approach completely turned me off when I first read about OOP in the early 90's. As a skeptical engineer, I was left with the impression that OOP, polymorphism, etc., was a pile of hype, and there was nothing there I couldn't do in FORTRAN, BASIC, or C. It wasn't until I started using Python in 2002, that I saw the benefits. I like that Python doesn't mystify OOP, or push it the way Java does, but just makes it a natural thing to do. >> > >Yes, that transition to OOP was upsetting as a paradigm change. I >went through it on the xBase path, following dBase II (derived from >some JPL language) through its winged migration, fork off to Clipper, >FoxPro, buyout by Microsoft and Borland, FoxPro for Windows, Visual >FoxPro. The full OO paradigm came across, unlike for the VB crowd, >who didn't get that until later. This all happened in my little world >*before* I ever wrote a line of Python (plus I got to Java first). >APL was the first computer language I ever learned (loved it), then >FORTRAN (yawn). > >However, the real benefit of OO is it hooks to natural language, where >students in human languages, like Sumerian, like Greek, already know >about nouns, verbs and adjectives as parts of speech. OO is all about >noun.verb() and noun.adjective. Then with have these little cartoons >about sharing pointers (names) to objects and we're done, they're >convinced there's a real grammar here, a logic, and dive in, happy to >still be in the humanities, no talk of "computer hardware" need apply >(though it's handy to have). This isn't "hyping" so much as >"bridging". In industry, it's about town-gown relations, where "town" >is an administrative layer atop cube farmers, and "gown" is IT. With >ORM, we're finally starting to get admin enrolled in seeing it from >IT's point of view, whereas SQL by itself was just not friendly >enough. > >OO makes computing more personable. To have busy administrators see >'self' as like "a little ego with a personal __dict__ clipboard" is >not "dumbing it down" is rather taking advantage of well-worn patterns >in grammar, leveraging what we've already got. It's efficient. Don't >just say "is a", say "I am a". This isn't just cute, it's a >conceptually smart way to think about a hospital, school or airport >(objects all). But that's me to busy administrators, not you to >enrolled electrical engineers. Different audiences = different >patter, we both know that. I think many of us who grew up with the "old gestalt" had a hard time with the transition to OOP. Maybe the old gestalt still includes administrators, but I would be surprised if it includes high-school students. It did include engineering students a few years ago, when we had a junior-level course in OOP taught in Smalltalk, so the students would be forced to break out of their old habits and do everything in the style of OOP. We still have that course, but now the pre-requisite is a course in Java, and it has morphed to more software-engineering and less pounding on the necessity of OOP. It seems that the "new gestalt" should not require breaking old habits. Objects should be introduced early, the noun.verb syntax is simple, and there is little need for motivation, revelation, or elaborate analogies by the time the students get to crafting their own objects. That seems to be the approach taken by newer texts, and it would have been beneficial for me also. It really wasn't the difficulty of the OOP paradigm that held us back, but the awkwardness of the languages, which perhaps created a need to force-feed and over-sell the idea of OOP, which turned off pragmatic folks like myself. We still have that awkwardness in our intro Java courses, but it seems to have been accepted as a minor inconvenience ("Just memorize this stuff, we'll explain it later."). I put together a sequence of Python examples for the transition to OOP, and added them to my collection for CS2 ( http://ece.arizona.edu/~edatools/index_classes.htm ). The emphasis is practical benefits, not any attempt to sell OOP. The principle is that you chose the level of structure that is right for your problem, bearing in mind that real-world problems tend to grow, so a little extra structure at the beginning often saves time in the end. The final example shows how Python can do everything that Java does, including private parts, and interface definitions. >Thank you for making your work public and open source in this way. >You are kind to offer it up for comments and to handle the feedback >graciously, especially given my many different biases. And thank you for your constructive criticism, which is always appreciated. -- Dave

2 1

Re: [Edu-sig] Topics for CS2
by David MacQuigg 20 Jan '09

20 Jan '09

Hi Kirby, Many thanks for the thoughtful review of my PythonOOP chapter. I especially like the suggestions to put more emphasis on the role of over-rides in *specializing* the behavior of subclasses, and to at least mention commonly-used CS terms like "polymorphism". I'll keep your suggestions for the next time I do any revisions on this chapter. If you or anyone else wants to make more extensive modifications, target a different audience, etc., I'll be glad to work with you. No reason we can't have multiple versions targeted to different groups. There may be some misunderstanding as to my purpose in writing this chapter. It is not a CS1 introduction to OOP. I would recommend Zelle or Goldwasser for that. It was written before those texts, and specifically for engineers who already know some programming, understand very well the need for modular design (no need for motivation of OOP), and who have learned Python up through chapter 18 of Lutz and Ascher (no need to explain __notation__). It could be an alternative, or a supplement, to the OOP chapters in L&A. It could also be part of the CS2 class I am now proposing, for students who already know Java or C. Some of my choices on what topics to emphasize may be different. These choices were based on my own experience, which may be different than others, and is certainly different from those who have a less pragmatic approach to languages. Thus, I have relegated operator over-riding to "advanced topics" because of my perception that it will be used less often than say, static methods, which I have included in my first large example. I use static methods frequently. They are now (as of version 2.4) more "pythonic" than when this chapter was written, so I feel I made the right choice. If my Animals class hierarchy seems artificial, it may be because I tried to illustrate everything I considered important, and do it in the smallest example that would still be clear. The comparison of classes to modules is not motivated by any affinity to Perl. What little I know of Perl, I don't like. Rather, it is part of an answer to the question "Why do we need classes?" Modules are the closest thing to classes as a unit of encapsulation. With a simple function, you could generate instances of modules as easily as instantiating objects from classes. You could even change the language slightly, and allow multiple modules per file. As for making OOP a "revelation", I think that is the wrong way to teach it, especially for non-CS students. I much prefer to treat it as just another way to encapsulate pieces of a program, a way that is very natural when you are modeling objects in the real world, and can be beneficial even when there is no parallel in the real world - the benefit flowing from the extra flexibility you have in encapsulation. That is something all engineers will understand. The "revelation" approach completely turned me off when I first read about OOP in the early 90's. As a skeptical engineer, I was left with the impression that OOP, polymorphism, etc., was a pile of hype, and there was nothing there I couldn't do in FORTRAN, BASIC, or C. It wasn't until I started using Python in 2002, that I saw the benefits. I like that Python doesn't mystify OOP, or push it the way Java does, but just makes it a natural thing to do. Again, if anyone wants to modify this document for their own purposes, I'll be glad to help. -- Dave At 08:21 PM 1/17/2009 -0800, kirby urner wrote: >Hi David -- > >I've been looking at your PythonOOP. > >Why use classes? All programming aside, I think it's a fairly strong >grammatical model of how people think, basically in terms of >noun.adjective (data attribute) and noun.verb() (callable method). >All talk of computer languages aside, we're very noun-oriented, think >in terms of "things" and these things either "are" or "have" >attributes and "do" verby stuff. > >OOP is about making the language talk about the problem domain, help >us forget that under the hood nightmare of chips and registers, >needing to allocate memory... all that stupid computer stuff that >nobody cares about (smile). > >Of course I like your nomenclature of a Cat inheriting from Animal as >I'm always tying "hierarchy" back to "zoology" and "taxonomy" as those >were original liberal arts tree structures (class hierarchies, >kingdoms, domains, namespaces). We like "astral bodies" subclassed >into stars, planets, planetoids (like Pluto), and moons. We like >"Reptiles" including "Snakes" which of course includes "Pythons" >(everything is a python in Python, i.e. an object with a __rib__ >cage). > >Having a Dog and a Monkey motivates why ancestor classes are >important: generic shared stuff, like digestion, might be handled in >a shared eat() method, each with its own self.stomach of course. With >a younger set (pre-college), those parentheses connote lips, with args >as oral intake. In the class of classes though... we give birth. > >Per a recent PPUG, I'm these days thinking to use a collections.deque >for my digestive tract maybe: > >>>> class Animal: > def __init__(self): > self.stomach = deque() > def eat(self, item): > self.stomach.append(item) > def poop(self): > if len(self.stomach)>0: > return self.stomach.popleft() > > >>>> zebra = Animal() >>>> zebra.eat('straw') >>>> zebra.stomach >deque(['straw']) >>>> zebra.poop() >'straw' >>>> zebra.stomach >deque([]) >>>> > >Some will want to say digestive_tract instead of stomach. > >Now you can develop your Dog and Cat, inheriting eat() and __init__ >from Animal, yet each subclass providing its own __repr__ methods. >"Hello world, I'm a Cat at %s" % id(self). Yes, you could make the >__repr__ invoke __class__.__name__ and share it -- show that later.... >? > >>>> class Animal: > def __init__(self): > self.stomach = deque() > def eat(self, item): > self.stomach.append(item) > def poop(self): > if len(self.stomach)>0: > return self.stomach.popleft() > def __repr__(self): > return "I'm a %s at %s" % (self.__class__.__name__, id(self)) > > >>>> class Dog(Animal): > pass > >>>> class Cat(Animal): > pass > >>>> thing1 = Dog() >>>> thing2 = Cat() >>>> thing1 >I'm a Dog at 138223820 >>>> thing2 >I'm a Cat at 138223852 > >Students see how inheritance means specializing as you go down the >tree (consistent with most introductory treatments). > >Your spin seems to tilted towards Cats with not enough other >subclasses of Animal to make inheritance seem all that necessary. >Your ancestor is mostly for "herding cats" (counting instances), isn't >so much a "blueprint" for different subclasses of the Animal idea >(aardvark versus eel). > >More generally I think using an ancestor class to do instance counting >is a little on the "too difficult" side for a core introductory >running example. It leads you to introduce an interception of __del__ >as your first example of operator over-riding. This seems rather >unpythonic, as the __del__ method is rather rarely intercepted, >compared to say __set__ and __get__ (per Alex Martelli in this lecture >@ Google: http://controlroom.blogspot.com/2009/01/oop-in-hour.html >). > >I was also struck by how often you compare classes to modules (modules >in Chapter 16 right?), suggesting a Perlish upbringing -- as did your >suggestion to use '_' in place of 'self' for "maximal uncluttering" >(paraphrase). > >When Perl decided to make the leap to OO, it was "the module" that got >blessed for this purpose yes? Are you a closet Perl Monger then? > >I notice you tend to favor your private terminology and don't resort >to the CS vocabulary as often, e.g. "polymorphic" and "polymorphism" >are not included. If you're wanting your students to gain fluency >with the surrounding literature, I think at least that one deserves >more focus, in conjunction with inheritance. > >I think the a first class could be all data (like a C struct). Like, >this example says a lot: > >>>> class Foo: > bar = 1 > > >>>> f = Foo() >>>> g = Foo() >>>> f.bar = 1 >>>> f.bar = 2 >>>> g.bar >1 >>>> f.bar >2 >>>> f.__dict__ >{'bar': 2} >>>> g.__dict__ >{} >>>> g.bar >1 > >however once you start adding methods, I don't think postponing the >appearance of __init__ for so long is a good idea. I would focus on a >Dog and a Cat (or any other two animals), both with __init__ >constructors and eat methods, then (as a next step) introduce the >Animal superclass as a case of "refactoring" by inheritance -- a good >time to mention the "is a" abstraction (a Dog "is an" Animal). Show >how you're economizing on code by having an ancestor, make OO seem >like a revelation (which it is/was). > >I don't think you're alone in finding __ribs__ somewhat intimidating, >strange-looking (a hallmark of Python), but I think these should be >tackled right away, perhaps with built-in data types first, i.e. that >2 .__add__(2) example. How about a function call ribs() that prints >the special names in any object... > >>>> import re >>>> ex = re.compile("__[a-z]+__") > >>>> def ribs(it): > return re.findall(ex, " ".join(dir(it))) > >I think of __init__ as being triggered by a "birth syntax" i.e. to >call a class directly, as in Animal(), is to call for an instance of >that class, and that invokes __init__ (__new__ first though). > >>>> class Foo: > def __init__(self): > print("I am born!") > > @staticmethod > def __call__(): > print("What?") > > >>>> f = Foo() >I am born! >>>> f() >What? >>>> Foo.__call__() >What? > >I like your point that intercepting __add__ is just like >"intercepting" an Animal's 'talk' method in a subclass, i.e. >interception is happening in both cases, it's just that some names are >special (as you say) in being triggered by *syntax* rather than their >actual names -- although that form is also usable (as you point out >using __add__) -- plus some special names *don't* have special >triggering syntax, i.e. just use the __rib__ directly, as in "if >__name__ == '__main__':" > >I like this section: > >Background on Languages >- languages poster >- progression of languages 1 2 > - domain-specific (FORTRAN, COBOL) > - general-purpose, high-level (C) > - one step above assembler > - problem was complexity, one big pile of data > - object-oriented (C++) > - data now contained within independent objects > - human oriented (Java, Python) > - garbage collection > - dynamic typing > >... and your focus on Mandelbrot / fractals. > >Lots of substance. > >Kirby > >On Thu, Jan 15, 2009 at 3:09 PM, David MacQuigg ><macquigg(a)ece.arizona.edu> wrote: >> I'm putting together a list of topics for a proposed course entitled "Programming for Scientists and Engineers". See the link to CS2 under http://ece.arizona.edu/~edatools/index_classes.htm. This is intended as a follow-on to an introductory course in either Java or C, so the students will have some exposure to programming, but the Java students won't know machine-level programming, and the C students won't have any OOP. For the proposed course, we will use the example programs as a way to introduce these topics. >> >> As you can see from the very few links to completed examples, this is just a start. Many of the links are only to discussions on this list, and I really appreciate the suggestions I have received so far. Also, it is far from a representative survey or optimum sample, rather just a random sample of topics that I found interesting. Some of the topics may be out of reach for students at this level, but that is the challenge. Figure out a way to present a complex or theoretically difficult topic in a way that is simple and intuitive and will whet the students appetite for further study. >> >> Additional suggestions are welcome. >> >> -- Dave >> >> >> _______________________________________________ >> Edu-sig mailing list >> Edu-sig(a)python.org >> http://mail.python.org/mailman/listinfo/edu-sig

2 2

Pythonic Math must include...
by kirby urner 19 Jan '09

19 Jan '09

Candidates: "Must include" would be like an intersection of many sets in a Venn Diagram, where we all gave our favorite movies and a very few, such as 'Bagdad Cafe' or 'Wendy and Lucy' or... proved common to us all (no suggesting those'd be -- just personal favorites). In this category, three candidates come to mind right away: Guido's for the gcd: def gcd(a,b): while b: a, b = b, a % b return a Then two generics we've all seen many times, generators for Pascal's Triangle and Fibonacci Sequence respectively: def pascal(): """ Pascal's Triangle ** """ row = [1] while True: yield row row = [ a + b for a, b in zip( [0] + row, row + [0] ) ] and: def fibonacci(a=0, b=1): while True: yield a a, b = a + b, a IDLE 1.2.1 >>> from first_steps import * >>> gcd(51, 34) 17 >>> g = pascal() >>> g.next() [1] >>> g.next() [1, 1] >>> g.next() [1, 2, 1] >>> g.next() [1, 3, 3, 1] >>> f = fibonacci() >>> f.next() 0 >>> f.next() 1 >>> f.next() 1 >>> f.next() 2 >>> f.next() 3 >>> f.next() 5 Check 'em out in kid-friendly Akbar font (derives from Matt Groening of Simpsons fame): http://www.wobblymusic.com/groening/akbar.html http://www.flickr.com/photos/17157315@N00/3197681869/sizes/o/ ( feel free to link or embed in your gnu math website ) I'm not claiming these are the only ways to write these. I do think it's a feature, not a bug, that I'm eschewing recursion in all three. Will get to that later, maybe in Scheme just like the Scheme folks would prefer (big lambda instead of little, which latter I saw put to good use at PPUG last night, well attended (about 30)). http://mybizmo.blogspot.com/2009/01/ppug-2009113.html Rationale: In terms of curriculum, these belong together for a host of reasons, not just that we want students to use generators to explore On-Line Encyclopedia of Integer Sequences type sequences. Pascal's Triangle actually contains Fibonaccis along successive diagonals but more important we're laying the foundation for figurate and polyhedral ball packings ala The Book of Numbers, Synergetics, other late 20th century distillations (of math and philosophy respectively). Fibonaccis converge to Phi i.e. (1 + math.sqrt(5) )/2. gcd will be critical in our relative primality checks, leading up to Euler's Theorem thence RSA, per the review below (a literature search from my cube at CubeSpace on Grand Ave): http://cubespacepdx.com/ http://mathforum.org/kb/thread.jspa?threadID=1885121&tstart=0 http://www.flickr.com/photos/17157315@N00/3195148912/ Remember, every browser has SSL, using RSA for handshaking, so it's not like we're giving them irrelevant info. Number theory goes into every DirecTV box thanks to NDS, other companies making use of this powerful public method.^^ You should understand, as a supermarket manager or museum administrator, something about encryption, security, what's tough to the crack and what's not. The battle to make RSA public property was hard won, so it's not like our public school system is eager to surrender it back to obscurity. Student geek wannabes perk up at the thought of getting how this works, not hard to show in Javascript and/or Python. Makes school more interesting, to be getting the low-down. By the same token, corporate trainers not having the luxury of doing the whole nine yards in our revamped grades 8-12, have the ability to excerpt specific juicy parts for the walk of life they're in. Our maths have a biological flavor, thanks to Spore, thanks to Sims. We do a Biotum class almost right away ("Hello World" is maybe part of it's __repr__ ?). I'm definitely tilting this towards the health professions, just as I did our First Person Physics campaign (Dr. Bob Fuller or leader, University of Nebraska emeritus). The reason for using bizarre charactersets in the group theory piece is we want to get their attention off numbers and onto something more generic, could be pictograms, icons, pictures of vegetables... Feedback welcome, Kirby ** http://www.flickr.com/photos/17157315@N00/3198473850/sizes/l/ ^^ http://www.allbusiness.com/media-telecommunications/telecommunications/5923…

5 16

Gnu Geometry
by kirby urner 17 Jan '09

17 Jan '09

Awhile back I posted some scripts for defining and populating 'newgeom', a database of polyhedra in Sqlite.[1] The idea of a classroom database is not new. Enter http://myschool/ms_purky/geom/polyhedra/?poly=tetrahedron and get some view, courtesy of Django. http://myschool/mr_duffy/geography/usa/capitals/?state=OR and get whatever view of Salem (our state capital). What's somewhat intriguing about our Gnu Geometry approach is hinted at in this volumes column: sqlite> select greekname, shortname, volume from Polyhedra; Tetrahedron|tetra|1 Hexahedron|cube|3 Octahedron|octa|4 Rhombic Dodecahedron|cell|6 Cuboctahedron|cubocta|20 Through the close of the 20th century, most children were not exposed to such a simple treatment, continuing their entrapment in a "2D" (planar) world. Moving "beyond flatland" was one of the hallmarks of new millennium curricula, thanks in large degree to H.S.M Coxeter, aka the King of Geometry, who paved the way with his clear explorations and elucidations of the polytopal realm. [2] With the advent of powerful personal computers and their ability to render colorful, rotatable shapes in perspective, many teachers discovered exciting new ways to revive both geometry and geography as subjects of passionate interest. Fractal geometry and cellular automata (both branches of chaos mathematics) likewise fed this revival, as did the publication of global data for civilian use (a geographic application). Other news: We're continuing to plan for OS Bridge, a new open source conference in Portland where I will likely show off some XOs during one of my talks, still quite exotic in this neck of the woods). [3] Kirby [1] http://mail.python.org/pipermail/edu-sig/2008-September/008756.html [2] http://www.amazon.com/King-Infinite-Space-Coxeter-Geometry/dp/0802714994 http://www.rwgrayprojects.com/synergetics/intro/dedicate.html [3] http://controlroom.blogspot.com/2009/01/os-bridge.html http://worldgame.blogspot.com/2009/01/saving-children.html

1 0

Mercurial Book translated to spanish
by Igor Támara 17 Jan '09

17 Jan '09

Hi all, A good friend of mine and I have finished translating the Mercurial book to spanish. You can find it on PDF and 1-page HTML at http://devnull.li/libromercurial/index.es.html You can also find the sources for the book on http://mercurial.intuxication.org/hg/mercurial_book_es/ The translation still has some rough edges, and we are still working on it, but any external help (spelling, wrong translations, etc.) is really appreciated. Patches (to this mail address) would be excellent ;) We hope our work proves itself useful for you that speak spanish of have friends that does. -- Igor Tamara

1 0

Compiling Python 3 and 2.6 on Ubuntu
by Vern Ceder 15 Jan '09

15 Jan '09

If anyone is interested in running Python 3 or Python 2.6 on Ubuntu Intrepid and having all the bits work, like Tkinter, etc. I've written up the process and and the needed packages for compiling from source on a blog post here... http://learnpython.wordpress.com/2009/01/14/installing-python-30-on-ubuntu/ If you're used to building things from source, it's fairly obvious, but with the rise of Ubuntu, more and more users are not so familiar with the process. Cheers, Vern -- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder(a)canterburyschool.org; 260-436-0746; FAX: 260-436-5137

1 0