[Edu-sig] CTL: Computer Thinking Language

[michel paul]

On Tue, Mar 3, 2009 at 2:27 PM, David MacQuigg <macquigg at ece.arizona.edu>wrote:

> At 10:00 AM 3/2/2009 -0800, michel paul wrote:
>
> >>Before I discovered Python a couple of years ago I was experimenting with
> a pseudo-code approach for expressing math concepts.  I had this kind of
> stuff in mind:
> >>
> >>factorial(n):
> >>    if n < 2 ---> 1
> >>    else ---> n*factorial(n-1)
>
> >I like the feeling of action in --->, but I also like the self-explanatory
> "return".  Any other suggestions?  Strong preferences?


Oh no, not at all.  My only point in even bringing this up was that I had
been trying to formulate something like a CTL awhile ago, and then I
discovered Python.  Wow!  What I found so delightful is that the kind of
pseudo-code I was contemplating looked a whole lot like Python!  I thought
that was a really good sign.  Yeah, Python is pseudo-code that runs!  It
already is a CTL.

I think the most useful CTL for integration in math education should be as
close to ordinary algebra as possible.  That's what I had been trying to get
at.  Kids in algebra classes initially get confused by this 'return'.  It
doesn't look like what they usually see in math.  So I thought an arrow
might correspond to mapping notation for functions:  f: x ---> y vs. Euler
notation: f(x) = y.  So that's why I originally opted for the arrow.
However, once they've had even a little experience, the use of 'return'
isn't all that strange to them.  And then, the other day when I had them
create generators for their HW assignment on sequences, wow!  I was really
pleased that they got the idea that 'yield' just meant that the function was
on hold until called again.  They seemed OK with that.


> >It would be nice to avoid in CTL the complexities of precedence and
> associativity rules (very non-fundamental knowledge).  How about we just do
> all operations in the order they occur, unless you force a different order
> with parens.
>

In terms of integration into math classes, I think it would be better to
maintain the traditional order of operations.  (I realize here that I'm
emphasizing math/CS fusion at a secondary level, and you're talking about
CS0.)  But using parentheses to clarify order - definitely!  And then from
there, it's easy to create functional compositions.  Now, I wouldn't
emphasize functional composition for ALL simple arithmetic expressions -
that would just be silly.  But I think doing that is an excellent kind of
exercise.  And then beyond that - turn the functional compositions into
binary expression trees!  I've had kids do that in math classes as exercises
in order of operations.  Take a typical arithmetic expression that has
several things going on and turn it into a binary expression tree.

>>By the way, we started studying sequences today in class.  What's a really
> good Pythonic tool for studying sequences ---> generators!
>
> >Should we include generators in CTL?  Seems like students at this level
> should have graduated to a full-featured language.


Right, I'm not sure generators would need to be in a CTL.  Again, in terms
of math education, I would see the role of a CTL simply as providing a
bridge between traditional static algebra and a more dynamic computational
algebra.  Since Python is already so close to a CTL, by the time we started
including generators, we might as well just be using Python.


> ># function returning a tuple (sneaky introduction to objects)
> >f(a,b): (a, (a+b)/2, b)


Yes, tuples as proto-objects!  I've thought about that a lot.  I think that
would be very practical in the math curriculum.  Tuples, ordered lists, can
very easily represent all kinds of mathematical objects.  I think a good
computational math route starting in traditional algebra would be to develop
the idea of tuples as representing various kinds of mathematical objects and
to write functions that operate on these tuples and then to integrate this
functionality into the 'tuples' themselves.

- Michel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20090303/89f9d000/attachment-0001.htm>