> It would be a huge help in promoting
> Python's use in education if we could make use of such a potentially
> fine module as the turtle module, but I'm finding it very difficult to
> write curriculum materials that use it since students don't have
> control over the turtle's screen in any easy to use way.
I understand the advantage of using something that
is included in the default install, but I found using
the included turtle module to be unsatisfactory.
For me, one of the biggest problems was the whole
multiple windows thing. It's not too bad on linux
where you can set up focus follow mouse and no
raise on click, but explaining that to someone else
and expecting them to set it up is not reasonable.
Anyhow, that's why I started Pynguin:
http://pynguin.googlecode.com/
With this, I find it extremely easy to get the students
started with writing their own code.
Getting back to the turtle module; I did look at
extending the turtle module when I started pynguin.
It explicitly says in the module that it is designed for
extending with another toolkit, but it also imports
Tk at the top level.
I think what I am going to do is implement a subclass
of Pynguin that implements all of the Turtle methods
and then make turtle-compatibility a configuration
option.
One user sent me a py2exe'd version of Pynguin, so
getting it running on windows should not be too
difficult. I was not comfortable posting the exe,
though, since I have no way of knowing what is
in it.
Hey Jeff, your question about controlling the turtle's screen
might have been just the ticket in my attempts to control
chaos, namely G. Lingl's chaos.py, which demonstrates
sensitivity to initial conditions is a plus if you want your
algebra to stay on the same page as itself, per equalities
that won't be equal in the real world. I'm hoping to throw
that into site-packages on the back end at OST, along with
all those baseball stats in SQL. It's all done with turtles
(Gregor's thing) and is brilliant, here's a link:
http://www.4dsolutions.net/ocn/python/OST/chaos.py
What I've been up to lately, besides teaching Python 24/7,
is debating with the Egyptologists whether computer science
really has an algorithm for "Egyptian Fractions". Milo is
arguing it doesn't and the consensus seems to be with
him for now. Fibonacci published what's today often called
"the greedy algorithm" (though that's more the genre than
the specimen) and I'm including that in Python below.
At first I though my job would be to subclass the Fraction
class in fractions, delegating the nuts and bolts to an
internal Fraction but adding this .egyptian( ) method
(really pseudo). With that in mind, I storyboarded this
science fiction session (not yet real) which is another
way of saying I applied the "agile" principle of "test
driven development":
>>> from unitfractions import Fraction
>>> p = Fraction(5,121)
>>> type(p)
<class 'unitfractions.Fraction'>
>>> p
Fraction(5, 121)
>>> r = p.egyptian( ) # pseudo-egyptian results of Fibonacci-published
algorithm
>>> r
(Fraction(1,25), Fraction(1,757), Fraction(1,763309),
Fraction(1,873960180913), Fraction(1,1527612795642093418846225))
>>> sum(r)
Fraction(5, 121)
I later decided there was no point trying to maintain the
appearance of a whole new class, and that existing
Fraction objects should just be fed to this greedy algorithm
directly, giving a tuple of Fraction outputs.
Not much code involved. Keep it Simple (another
"agile" precept).
>From the original thread:
"""
On second thought, I think subclassing a fractions.Fraction is overkill. As
soon
as said subclass participates in numeric relations with its fellow Fractions
(of the ordinary kind), it's going to spawn ordinary Fractions (ancestor
class).
Maintaining an entirely new type just for this one feature is not worth the
effort,
given likely arithmetic relations with peers.
Also, I'm not a huge fan of recursion where iteration is just as
straightforward.
In the case of Fibonacci's greedy algorithm, there's like nothing to it:
"""
OST Skunkworks:
Pseudo-Egyptian Fractions
See:
http://scienceblogs.com/goodmath/2006/11/egyptian_fractions.phphttp://groups.google.com/group/mathfuture/browse_thread/thread/97511940cccd…
"""
from fractions import Fraction
from math import ceil
def greedy(q):
"""return unit fraction expansion of fractions.Fraction q,
using Fibonacci's 'greedy algorithm' -- non-recursive"""
results = []
while q > 0:
if q.numerator == 1:
results.append(q)
break
x = Fraction(1,ceil(q.denominator / q.numerator))
q = q - x
results.append(x)
return tuple(results)
def _test( ):
"""
>>> greedy(Fraction(5,121))
(Fraction(1, 25), Fraction(1, 757), Fraction(1, 763309), Fraction(1,
873960180913), Fraction(1, 1527612795642093418846225))
>>> greedy(Fraction(4,5))
(Fraction(1, 2), Fraction(1, 4), Fraction(1, 20))
>>> greedy(Fraction(9,31))
(Fraction(1, 4), Fraction(1, 25), Fraction(1, 3100))
>>> greedy(Fraction(21,50))
(Fraction(1, 3), Fraction(1, 12), Fraction(1, 300))
>>> greedy(Fraction(1023, 1024))
(Fraction(1, 2), Fraction(1, 3), Fraction(1, 7), Fraction(1, 44),
Fraction(1, 9462), Fraction(1, 373029888))
"""
print("testing complete")
if __name__ == "__main__":
import doctest
doctest.testmod()
_test()
Note that I'm calling these "pseudo Egyptian" -- not claiming there's any
simple
algorithmic solution that'll work best in all cases. Computer scientists
and
Milo appear to be on the same side on this one.
"""
The threads on all this may be dredged up from an obscure Google
group named mathfuture, one of the Droujkova facilities, and as
usual productive.
Kirby