[Edu-sig] Functions & Generators (gnu math memo)
kirby urner
kirby.urner at gmail.com
Wed Sep 27 00:32:00 CEST 2006
On 9/26/06, kirby urner <kirby.urner at gmail.com> wrote:
> Functions and Generators (build directly off algebra, no need to harp
> on "variables", although most students will want a strong "types"
> discussion, as their earlier math was probably very weak in this area,
> especially around strings)
>
Which is where initial exploration at the shell prompt begins, with
dir() and help().
dir() at the shell returns a 3-element table of contents, with __doc__
referencing a None type and __name__ referencing a string '__main__'
(what's currently running). __builtins__ is where the action is:
lots of potential for Error, followed by lots of yummy stuff that's
NOT (repeat NOT) for "beginners" (we don't condescend -- yet good
teachers accommodate us).
> Building on the potential of Squeakland Creatures (the warmer fuzzier
> objects of a younger day), we make a big deal of the "arguments mouth"
> (except you don't really need arguments), i.e. those curved
> parentheses are like lips (optional link to fish lips in FS Coupler
> segment (not the same as Vesica Pices, though related)).**
Although not intended as a pun, ** is apropos, as *args, **kwargs is
Pythonic for "optional passables" e.g.:
>>> def funk(adelic, *ozmotic): return (adelic, ozmotic)
>>> funk("bump") # no optional tupuloids
('bump', ())
>>> funk("bump","grind") # one tupuloid
('bump', ('grind',))
>>> funk("bump","grind","doowah") # two tupuloids
('bump', ('grind', 'doowah'))
AND:
>>> def funk(adelic, *ozmotic, **chagum): return (adelic, ozmotic, chagum)
>>> funk("bump","grind","doowah",fanstastic="budda bum", shorty="digum")
('bump', ('grind', 'doowah'), {'fanstastic': 'budda bum', 'shorty': 'digum'})
i.e. named arguments, after the tupuloids, gather in a **kwargs dict
(kw means "key word" i.e. a "key word arguments" dictionary).
Don't feel obligated to use "tupuloid" to mean "member of a tuple" --
that's optional.
> Remember, DO NOT postpone Generators as an advanced topic. Every
A common pitfall among those who teach in the order learned.
So-called "regurgitation" style pedagogy (both LIFO and FIFO styles
suffer from this same inability to intelligently reorder topics into a
Sequence *other than* the one learned (a failing more common in other
disciplines outside of our Computer Science (probably because we've
got that "woman's touch" [tm] from our founders))).
> Early Functions:
> ============
> GCD
> Totatives
> Totient
> Triangular Numbers
> Tetrahedral Numbers
> Cuboctal/Icosahedral Numbers
Plus everyone'll want to do a Parabola, with higher degree Polynomials
to follow (Sine Waves etc.
-- Who Was Fourier?
http://www.amazon.com/Fourier-Transnational-College-Lex-Tokyo/dp/0964350408/
)
I generally save Polynomials until we know how to write our own
classes, and use __call__ to have any P-object evaluate for any "x"
(if a poly in one variable).
Example:
http://www.4dsolutions.net/ocn/python/simppoly.py
> Curriculum context:
>
> Difference between Composite and Prime, concept of Relatively Prime
> (strangers). Leading to: Integers Modulo N groups, germutation groups,
Hahah. Funny... "permutation groups" I meant.
> polyhedrally defined symmetry groups. Note that J has some primitives
> for generating cyclic notation, which you could use to motivate the
> need for a Python counterpart.
http://www.jsoftware.com/help/dictionary/dccapdot.htm
>
> Early Generators:
> =============
> Triangular Numbers
> Tetrahedral Numbers
> Cuboctal/Icosahedral Numbers
> Fibonacci Numbers
> Mandelbrot Set decider (convergent or not?)
I forgot Pascal's Triangle, duh. Also Pascal's Tetrahedron is a
worthy topic. I've got some original stuff on that here:
http://www.grunch.net/synergetics/pascal.html (I notice the
formatting has gotten out of control -- need to fix the XHTML).
> Curriculum context:
>
> Growing sphere packings per my OSCON 2005 and London Knowledge Lab
> presentations, i.e. divergence represented with polyhedral numbers ala
> 'Book of Numbers' (cites Martin Gardner), with volume expanding as a
> 3rd power rate of linear growth (expressed in the scale method of our
> Polyhedron parent class).
Per rbf.py:
def scale(self,factor):
"""
Resize shape by factor.
Translate to the origin, scale, translate back.
Multiply volume by 3rd power of scale factor.
"""
newself = copy.deepcopy(self)
current = newself.center
newself.move(-current) # go to origin
for label in newself.vertices.keys():
newself.vertices[label] = newself.vertices[label] * factor
newself.move(current) # return to current position
newself.volume = newself.volume * pow(factor,3)
return newself
This uses an old trick from computer graphics lore: when rotating or
scaling, move the object to the origin and apply simple vector tweaks,
then move it back where it came from.
Remember: we use the convention of Vectors tail-originating at the
Origin, with Edges being any segments between two vector-defined
endpoints.
http://www.4dsolutions.net/cgi-bin/py2html.cgi?script=/ocn/python/stickworks.py
> Of course list comprehension syntax is used from the get go, per the
> usual approach of using collection types to go over basic dot notation
> (per my EuroPython 2005 presentation).
>
http://www.4dsolutions.net/presentations/pythonicmath.pdf
> Followup (where to go from here):
>
> Once we're good at writing functions and generators, it'll be easy to
> define new classes, as methods are simply functions with a self
> argument (a basis for object instrospection). Remember the "two
> passes":
>
> First pass: treating the builtins as read-only givens (axiomatic)
>
E.g.:
>>> help({})
...
>>> help(1)
...
Lots of ribbing -- a sure sign we're exploring the internals of the
Python namespace. Make one feel clued in (not condescended to, not
treated like a know-nothing beginner, even if that's what one is).
> Second pass: rolling our own, coding up a namespace (interactively,
> with unit testing)
Good place for the Monkey, Dog, Human as subclasses of Mammal
conversation, per my presentation to the London Knowledge Lab (live,
on camera). I still hear from them (makes sense, given Portland's
eagerness to grow one locally (PKL thread)).
> Plus we might get back to the warm fuzzies by this route, now feeling
> more like puppetmasters or cartoon animators i.e. we *make* cartoons,
> don't just watch them (multi-track editing isn't just for others to do
> for us).
IronPython controlled Cartoon Creatures from the beginning.
http://blogs.msdn.com/hugunin/archive/2006/09/05/741605.aspx
> Also check "focal points" in my Bizmo Diaries around this time, if new
> to our curriculum and just trying to get some overview. And no, you
http://mybizmo.blogspot.com/2006/09/focal-points.html
> don't have to be a snake charmer. I'm relying on the other Open
> Source language communities to spin their own distros.
>
> ** might be able to do something around teeth when treating of default
> and/or optional arguments, per Tow Mater example.
>
> Re Coupler "fish lips":
> http://groups.yahoo.com/group/synergeo/message/29178
>
Picture of a coupler:
http://mybizmo.blogspot.com/2006/09/more-compositions.html
Kirby
More information about the Edu-sig
mailing list