[Edu-sig] Math + Python: reviewing some themes (long)

David MacQuigg macquigg at ece.arizona.edu
Tue Jan 26 11:53:58 CET 2010


kirby urner wrote:
> I've been hyping "digital mathematics" as a kind of niche marketing 
> term, as distinct from "discrete" but is this wise?  
>  
> Per math-thinking-l (another list), I'd say I'm in the distinct 
> minority in thinking "digital math" is a good term.  It's unexplored, 
> not conservative, whereas discrete math is already accepted and 
> entrenched.
>  
> To try going in with some "digital math" is just stacking the deck 
> against one's own efforts, increasing the odds against success.  
> Still, we need to call it something.   Computer Math?  Computational 
> Math?  Discrete Math?
I would call it "Computational Thinking".  There have been a series of 
articles on revising CS curricula in recent issues of Communications of 
the ACM.  I recommend the articles by Chris Stephenson and Peter Denning 
(December 2009).

> 3.d OBJECTS FIRST?
> ====================
>  
> Sorry this is being so long.  Let me just end with another take on the 
> "objects first" approach.
>  
> In order to make Python more accessible and the mathematics 
> correspondingly easier, we begin with very simple classes based around 
> animals (e.g. the Turtle class).  We encourage thinking about animals, 
> their attributes and behaviors.  Only later on will we try our had at 
> more generic "math objects" such as Rational Numbers. 
>  
> MFTDA actually includes a Rational number class, but doesn't give it 
> much focus.  It seems to be the only class definition in the entire 
> text.  I think this maybe mirrors an attitude among CS professors that 
> classes and objects are an advanced 2nd year topic.
>  
> My own view is somewhere in between:  I think a full blown treatment 
> of OO, including abstract classes, metaclasses, multiple inheritance, 
> is indeed advanced and probably not suitable for a one year or half 
> year high school math course. 
>  
> Or, if suitable, then mostly in the form a really primitive examples 
> of the Foo and Bar class variety, more to communicate the generic 
> design patterns and concepts than to develop full blown computer 
> programs such as one might use in production environments.
>  
> What examples do teachers wish to contribute?  What would be a good 
> introductory example of multiple inheritance I wonder?  I recall David 
> MacQuigg sharing some examples where __mro__ (method resolution order) 
> made an appearance.

MRO was an advanced topic in an advanced chapter on OOP, not anything I 
would include in an introductory course.  In fact, I wouldn't even make 
OOP a special topic.  It's just the most natural way to solve a lot of 
problems.  Students should be *using* objects (lists, etc.) from day 1.  
Then, if there is time later in the course, I would show how to *design* 
objects.  Even then, you really don't have to say much about 
inheritance, polymorphism, abstract classes, MRO, and all the stuff that 
professional programmers will get in later courses.

The thing you want to avoid is having students think "What is this 
crap?"  That's sometimes necessary in math.  You can't appreciate the 
utility of eigenvectors until you understand them.  It's totally 
unnecessary in programming.   Let real-world examples lead the way.  If 
you can't start with a simple example where multiple inheritance is 
needed, don't even introduce the topic.

> http://wikieducator.org/User:Macquigg  (I recommend reading Dr. 
> Macquigg's excellent testimonial here, with a link to his PyWhip).

PyWhip is the tool that is needed by math and science teachers who want 
to use computation in their classes, but feel uncomfortable trying to 
teach programming.  It will include problems in chemistry, physics, 
calculus, whatever someone wants to contribute.  All a teacher has to do 
is stay one step ahead of the students.  Anyone capable of teaching 
science or math can do that.

Unfortunately, our grand plans have been stalled for lack of a volunteer 
web programmer who can finish the hardest part of the job - the last 
10%.  We are considering applying for a grant, so we can hire a 
professional.  I wish I had more time.  Google App Engine, Django, 
Web2py... it all looks very interesting.

> So yes, the CS professors are right.  A full blown intro to classes is 
> too much to start off with.

Actually, CS professors, as a group, are more likely to want "full 
blown" tailored to the needs of future programmers.  Us industry types 
are more likely to say "Screw this.  I can write all the programs I need 
in BASIC and C."  That was my attitude from when I first learned about 
OOP (1992) until discovering Python (2002).  This was not for lack of 
trying.  I read a book on C++, and concluded that a better name would 
have been C--.

> The idea, then, is to build some awareness of classes and objects 
> using familiar analogies relating to every day life.  A class 
> definition is a blueprint (one needs to explain "blueprint" -- design, 
> plan) whereas an instance of the class has it's own place in memory, 
> its own "self" as it were (intro to Python "self" syntax). 
>  
> Do some animal classes.  Then note how dot notation is what's used to 
> access the attributes and behaviors of a user-defined object. 
>  
> Then note how Python's primitive objects are likewise instances of 
> various classes (e.g. the List class). 
>  
> It's dot notation itself that we're hoping to make second nature 
> (familiar, not too arcane).
>  
> 3.e  THE TIME DIMENSION
> ====================
>  
> That's the breakthrough in understanding we're seeking:  brief anatomy 
> lessons with user-defined classes provide enough background to anchor 
> an understanding of built-in classes and objects.  It's really "dot 
> notation" itself that we're seeking to anchor here.  noun.verb(args) 
> and noun.adjective provide a primitive grammar or logic.

I would use built-in objects first, then user-defined.  Students should 
be very comfortable with dot notation before we even suggest that you 
can do more than just use the built in objects in Python.  To introduce 
dot notation, I would just show examples.  It's kind of like learning to 
have a simple conversation in Spanish ("Hola, Isabel.  Como esta!!) 
before studying the grammar, or even learning the vocabulary.

See the section "Elegant Python" in 
http://pywhip.appspot.com/static/help/Using_Python.htm.  A student's 
first encounter with dot notation will be the line:

    workset.append(n)    # append n to the workset

Other than that comment, and a prior statement:  "... see if you can 
understand how this function works.  Practice using the dir() and help() 
functions on list objects and their methods.", there is no explanation 
of this grammar.  It's just a convenient way to say something  Later, in 
http://pywhip.appspot.com/static/help/Strings.txt we talk a little more 
about the grammar, and the equivalence of two different notations:

     >>> len('abcde')     # same as 'abcde'.__len__()

Putting too much emphasis on a topic can actually make it harder to 
understand.  I remember struggling with lambda functions for quite a 
while, even wasting time in a discussion of lambda calculus, then 
realizing it was nothing but a trivial bit of syntax, and I really 
wasn't missing something important.

Gary has a good point that we may be still putting too much emphasis on 
"objects first".  It's got me thinking whether I need to rewrite that 
section in Using_Python where I show that 2 is an object.  The 
fundamental point of this section is Python's unique relationship 
between variables and objects.  The rest is anecdotal.  Anecdotal 
information can distract from the main point.

PyWhip will have the ability for a teacher customize everything - 
problem sets, help files, whatever is needed for a particular group of 
students.  When a student logs in, he will see exactly what his teacher 
intends him to see.  The help files referenced above may be too brief 
for high school students.  My target audience is technical professionals 
who already know how to write a program, perhaps in BASIC.  I encourage 
others to submit alternatives better suited to whatever background your 
students may have.

-- Dave


More information about the Edu-sig mailing list