[Edu-sig] Functions & Generators (gnu math memo)

[kirby urner]

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