From dblank at brynmawr.edu Wed Feb 1 20:05:20 2006 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Wed, 01 Feb 2006 14:05:20 -0500 Subject: [Edu-sig] rur-ple: pre-release of new lessons (long) In-Reply-To: References: <7528bcdd0601281953g472db53ep77f8dddc36fb63d@mail.gmail.com> Message-ID: <1138820720.32460.161.camel@mightymouse.brynmawr.edu> I was asleep at the wheel during this last bit of discussion of RUR-PLE, and just now catching up. Some comments below: On Sun, 2006-01-29 at 09:56 -0800, Dethe Elza wrote: > > My longer term hope is to see some physical robot offerings on the > > market (in addition to the screen based ones) with some kind of > > Python capability -- perhaps just a module with pre-defined motions > > the user might resequence or trigger based on events (sensor > > inputs), per Lego Mindstorms example. Python is catching on in many places, including real robotics and AI research. Many low-level systems have Python wrappers. I'll be presenting at SIGCSE (http://www.cs.rit.edu/~sigcse06/) in a month with two other colleagues. We all three do robotics, but all use Python in different ways. For example, Python now runs natively on Sony's AIBO. It used to be the case that one would write C++ code, compile it, reboot, upload, run, in order to program the AIBO. Now, it can be all Python (and the award winning CMU team is doing just that). As a side note, the AIBO was just canceled by Sony. Bummer. It was a great platform. And as Dethe mentioned: > Pyro (http://pyrorobotics.org/) does exactly this. It provides an > environment for programming physical robots, but you can also run > them in a simulator which uses OpenGL to create both the robot and a > world for the robot to interact with. Could be interesting to bring > something like this to RUR-PLE. As one of the developers of Pyro, I wonder about going the other way too, bringing RUR-PLE pieces to Pyro. In fact, not only can Pyro control OpenGL robots, AIBO, 2d simulators, but it can also be used to play checkers, chess, and the like. Also, we have a "wumpus world" that operates much like RUR-PLE's world. I co-wrote a paper a couple of years ago, "Avoiding the Karel-the-Robot Paradox: A framework for making sophisticated robotics accessible" [1]. The point was that instead of teaching a pseudo-language in a pseudo-world, we should teach a real language/system which remains constant across all robot platforms. It is an extreme position (and largely aimed at real robotics systems), but does raise some real questions: - Does RUR-PLE limit the student too much? Or is does hiding some parts of the complexity of Python and real robots make it easier to learn? - Does learning to rely on the hidden bits make it harder to learn real Python as the student continues? - Is it easy to move to Pyro from RUR-PLE, or would it be easier to have a RUR-PLE world in Pyro? - Would having to deal with real world issues (like time, inaccurate sensors, inaccurate wheels) cloud the environment, or does it excite the student and teach other valuable lessons? - Do kids see RUR-PLE as silly and too simple? Do kids see Pyro as too complex? Is there a preferred age for both systems? - Can kids explore "emergent phenomena" with RUR-PLE? Or is it just too constrained? Students can have control many robots in Pyro, but is this too much for them to handle? (Pokemon is vast, and yet not that interesting because there aren't any interaction effects. Even The Sims has limited interaction effects.) - Having real sensors in Pyro allows students to hook up input directly to output. In RUR-PLE you have to use symbol names (left, right, beeper_to_left, etc). How does this affect what we learn? Are these biases put in place when we are young and hard to overcome later? The programs are more similar than one might guess: In RUR-PLE: move() move() turn_left() There are some subtle points in this program: how do you know when you have gone one grid space? can you move .5 grid spaces? how do you know when you have turned exactly 90 degrees? In Pyro (talking to a symbolic, discrete world): class MyBrain(Brain): def step(self): self.robot.move("forward") self.robot.move("forward") self.robot.move("left") The same questions apply here, and we answer them by going to a continuous world. In Pyro (talking to a real or simulated, continuous world): class MyBrain(Brain): def step(self): self.robot.move(0, 1) # translate amt, rotate amt time.sleep(1.0) self.robot.move(1, 0) # values go from -1 to 1 time.sleep(3.0) self.robot.move(0, 1) time.sleep(1.0) A complete intro lesson can be seen here: http://pyrorobotics.org/?page=PyroModuleDirectControl Some of these points may be non-issues because RUR-PLE isn't attempting to teach robotics. But what if it were? Some of these points we could explore by making RUR-PLE talk to the Pyro 2D simulators (one is written in pure-Python) and by having Pyro connect to the simulator in RUR-PLE. I'd be interested in sharing lessons learned from that software which is designed "for kids" versus "for young adults." BTW, I use do use Pyro to teach cognitive science students how to program. Questions of intelligence make a great way to motivate the learning of programming, and of course Python is great for that. Would young kids benefit from this same motivation? -Doug [1] http://dangermouse.brynmawr.edu/~dblank/papers/aaaiss04-pyro.pdf -- Douglas S. Blank Computer Science Assistant Professor Bryn Mawr College (610)526-6501 http://cs.brynmawr.edu/~dblank From delza at livingcode.org Thu Feb 2 04:31:15 2006 From: delza at livingcode.org (Dethe Elza) Date: Wed, 1 Feb 2006 19:31:15 -0800 Subject: [Edu-sig] rur-ple: pre-release of new lessons (long) In-Reply-To: <1138820720.32460.161.camel@mightymouse.brynmawr.edu> References: <7528bcdd0601281953g472db53ep77f8dddc36fb63d@mail.gmail.com> <1138820720.32460.161.camel@mightymouse.brynmawr.edu> Message-ID: <82652088-00C3-458B-AFBA-51697653E410@livingcode.org> On 1-Feb-06, at 11:05 AM, Douglas S. Blank wrote: > For example, Python now runs natively on Sony's AIBO. It used to be > the > case that one would write C++ code, compile it, reboot, upload, > run, in > order to program the AIBO. Now, it can be all Python (and the award > winning CMU team is doing just that). As a side note, the AIBO was > just > canceled by Sony. Bummer. It was a great platform. Wow, that alone sounds like a great reason to get an AIBO (python is a great selling point for me--I never wanted a smartphone until Nokia ported python to theirs). > As one of the developers of Pyro, I wonder about going the other way > too, bringing RUR-PLE pieces to Pyro. In fact, not only can Pyro > control > OpenGL robots, AIBO, 2d simulators, but it can also be used to play > checkers, chess, and the like. Also, we have a "wumpus world" that > operates much like RUR-PLE's world. Mixing RUR-PLE and Pyro sounds like a good idea to me. My daughter likes to push things past their limits (she's a good beta tester for me), so if she was using RUR-PLE and found that it "unfolded" into a bigger, more complicated, but more powerful world, I think that would really get her involved. Does Pyro yet run natively on OS X (without requiring X windows/Gnome/ fink)? > Some of these points may be non-issues because RUR-PLE isn't > attempting > to teach robotics. But what if it were? Some of these points we could > explore by making RUR-PLE talk to the Pyro 2D simulators (one is > written > in pure-Python) and by having Pyro connect to the simulator in RUR- > PLE. > I'd be interested in sharing lessons learned from that software > which is > designed "for kids" versus "for young adults." Using robotics to teach programming, vs. using programming to teach robotics. Two sides of the same coin, IMHO. I think you've raised some good points to consider, but I know I'd like to see this combination work out (especially if it runs on OS X). > BTW, I use do use Pyro to teach cognitive science students how to > program. Questions of intelligence make a great way to motivate the > learning of programming, and of course Python is great for that. Would > young kids benefit from this same motivation? Not directly questioning their intelligence, but praising them for being smart when they figure something out, yeah, that's a heady motivator. --Dethe "Any idea that couldn't stand a few decades of neglect is not worth anything." --Gabriel Garcia Marquez From kirby.urner at gmail.com Thu Feb 2 19:25:38 2006 From: kirby.urner at gmail.com (kirby urner) Date: Thu, 2 Feb 2006 10:25:38 -0800 Subject: [Edu-sig] rur-ple: pre-release of new lessons (long) In-Reply-To: <1138820720.32460.161.camel@mightymouse.brynmawr.edu> References: <7528bcdd0601281953g472db53ep77f8dddc36fb63d@mail.gmail.com> <1138820720.32460.161.camel@mightymouse.brynmawr.edu> Message-ID: > > For example, Python now runs natively on Sony's AIBO. My daughter just got her new I-Cybie via UPS yesterday. She's very excited about it. The battery is still charging and I've yet to see it perform. We're working up to an affordable Pythonic robot eventually, as she's just about the right age to find programming of interest. Especially if there's pet robot at the other end of it. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060202/20b1b26f/attachment.html From dblank at brynmawr.edu Thu Feb 2 19:29:08 2006 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Thu, 02 Feb 2006 13:29:08 -0500 Subject: [Edu-sig] rur-ple: pre-release of new lessons (long) In-Reply-To: <82652088-00C3-458B-AFBA-51697653E410@livingcode.org> References: <7528bcdd0601281953g472db53ep77f8dddc36fb63d@mail.gmail.com> <1138820720.32460.161.camel@mightymouse.brynmawr.edu> <82652088-00C3-458B-AFBA-51697653E410@livingcode.org> Message-ID: <1138904948.32460.216.camel@mightymouse.brynmawr.edu> On Wed, 2006-02-01 at 19:31 -0800, Dethe Elza wrote: > Mixing RUR-PLE and Pyro sounds like a good idea to me. My daughter > likes to push things past their limits (she's a good beta tester for > me), so if she was using RUR-PLE and found that it "unfolded" into a > bigger, more complicated, but more powerful world, I think that would > really get her involved. Yes, I think it would be good to think about making it easy to move from rur-ple to pyro. > Does Pyro yet run natively on OS X (without requiring X windows/Gnome/ > fink)? In a word, yes. It is still the case that if you want to use the advanced 3D simulator (gazebo) you'll need X (I suspect that someone will eventually write a front end to gazebo in native Mac). But, we now have a simulator written in 100% Python that simulates vision, grippers, and range sensors. You can see some images and the interface here: http://pyrorobotics.org/?page=The_20Pyrobot_20Simulator > > Some of these points may be non-issues because RUR-PLE isn't > > attempting > > to teach robotics. But what if it were? Some of these points we could > > explore by making RUR-PLE talk to the Pyro 2D simulators (one is > > written > > in pure-Python) and by having Pyro connect to the simulator in RUR- > > PLE. > > I'd be interested in sharing lessons learned from that software > > which is > > designed "for kids" versus "for young adults." > > Using robotics to teach programming, vs. using programming to teach > robotics. Two sides of the same coin, IMHO. I think you've raised > some good points to consider, but I know I'd like to see this > combination work out (especially if it runs on OS X). Very well said. I hope we can discuss this further. > > BTW, I use do use Pyro to teach cognitive science students how to > > program. Questions of intelligence make a great way to motivate the > > learning of programming, and of course Python is great for that. Would > > young kids benefit from this same motivation? > > Not directly questioning their intelligence, but praising them for > being smart when they figure something out, yeah, that's a heady > motivator. Actually, I meant that students can question where intelligence comes from, and *that* motivates them to learn about robots. These questions are subtle, and I don't think we have an answer. It doesn't (necessarily) have anything to do with logic. It is akin to "what does it mean to be alive?" and "how can non-living material give rise to life?" How can intelligence come from non-intelligent things? These are some of the great questions of our time. I think Python can help explore them. -Doug > --Dethe > > "Any idea that couldn't stand a few decades of neglect is not worth > anything." --Gabriel Garcia Marquez > > -- Douglas S. Blank Computer Science Assistant Professor Bryn Mawr College (610)526-6501 http://cs.brynmawr.edu/~dblank From ajudkis at verizon.net Fri Feb 3 04:06:24 2006 From: ajudkis at verizon.net (Andy Judkis) Date: Thu, 02 Feb 2006 22:06:24 -0500 Subject: [Edu-sig] my RUR-PLE experiences References: Message-ID: <007f01c6286e$d16f1730$6401a8c0@Gandalf> I have used RUR-PLE in my classroom for two semesters now. I teach a group of generally above-average 10th graders. My course is a required part of the curriculum, so the group includes many kids who are not big computer fans. I've found RUR-PLE to be a very constructive way to approach programming. I use it to teach the basics of looping and branching and defining subroutines, and we do about 6 of Andre's exercises. (We spend about 4 1/2 hours of class time on it before moving on to Python, using modified versions of the LiveWires and a little bit from How To Think Like a Computer Scientist.) RUR-PLE is a very constrained environment, but it ramps up nicely into "real" Python. It shelters beginners from the ugly stuff like num=int(raw_input("number?")) but it retains enough complexity so that the behavior of programs is not all that predictable to the kids. They still have to do a considerable amount of thinking in order to get things to work. After the time with RUR-PLE, I found that only 2 or 3 kids out of 34 could write a trivial program that would send the robot counter-clockwise around the edge of a rectangular world of unspecified size until it hit a beeper. The kids could understand a solution like: while not next_to_a_beeper(): if front_is_clear(): move() else: turn_left() turn_off() when they saw it, but most could not synthesize it themselves. This is after we discussed this -specific- problem in class, and after all the kids had done similar things with the exercises. When we moved on to Python, they were still struggling with similar very simple problems. I think programming is much harder for "normal" (not self-selected) kids than most of us seem to acknowledge. One of my kids said "It's so totally logical, and yet it's so frustrating. . . " I think kids are turned off when we tell them how easy it is, and then they discover otherwise. It just serves to make them feel stupid. We'd be better off saying "It's hard at first, but it's really worthwhile. Here, let us help you get started." I think RUR-PLE is a great tool for this. Regards, Andy Judkis Academy of Allied Health and Science Neptune, NJ From ajsiegel at optonline.net Fri Feb 3 16:02:11 2006 From: ajsiegel at optonline.net (Arthur) Date: Fri, 03 Feb 2006 10:02:11 -0500 Subject: [Edu-sig] whitespace and newlines and seperators ... oh my Message-ID: <43E37073.5050803@optonline.com> More (semi-IMO) irrelevancy .... Trying to get to a presentable, announceable alpha release of PyGeo... and ending up confronting new complexities of the kind I want to just wish away. Alan Kay hasn't gotten there yet, so I am stuck with the prospect of understanding things and thinking things through. OK - watch my directory separators in HTML. HTML that works on my local Windows box breaks on the server. Think Unix separators. Got it.. Then there is of course the cross platform newline issue - CRLF, CR, LF which gets me doing search and replace in ascii hex (geeky) and screwing up working code. What's the standard way to deal with this issue in a cross platform distribution?. Still don't know. But then it gets hairy, and Python specific: Trying to use the pre-alpha pudge document generator for the portion of PyGeo I consider to be the underlying "framework". http://pudge.lesscode.org/ Choosing pudge because it supports embedded reStructured text, and it supports "code as text" - which I see as part of PyGeo at a basic level - by automating the linking of documentation to colorized, html versions of the actual code. Very cool. There seems to be a group of heavyweights behind it. And the code base is small, I can follow it - so when it breaks when confronting a Boost-wrapped cvisual function I can find the work around.. First bigger problem is that pudge chokes on what I think is valid reStructured text - finding tables that pass reStructured scrutiny in stand-alone files to be malformed when embedded in triple quoted doc comments. I am assuming this is some kind of whitespace parsing issue, but haven't dug into the code far enough to verify. I am hoping it is something I can solve and feed back into the pudge project. Remains to be seen. More surprising was the html colorizing problem. The colorizing code relies on tokenize.py from the standard library - which keeps choking on code that compiles and runs fine by Python. So I go to tabnanny.py, which is seems to be there exactly to diagnose these kinds of issues. But one of the symptoms of the problem is that tabnanny (i.e tokenize) is parsing the file in such a way that it is reporting back line numbers that don't correspond to the code when viewed in a text editor. So its hard to pinpoint the problem. Turns out (I think) - this took be a while - that tokenize seems to be trying to parse things between triple quoted strings, and since there is a lot of code intended to output to Povray SDL and formatted for that purpose - it is choking on whitespace issues (that IMO shouldn't be issues) in that code. Is it fair to think that all rules should be off between """ ...and... """ - and that if I am right that this is where the choke is, that I should file a bug report. OTOH, seems unlikely that this has not been confronted before. Any clues to what I may be missing is appreciated. Art From ajsiegel at optonline.net Fri Feb 3 16:28:50 2006 From: ajsiegel at optonline.net (Arthur) Date: Fri, 03 Feb 2006 10:28:50 -0500 Subject: [Edu-sig] whitespace and newlines and seperators ... oh my In-Reply-To: <43E37073.5050803@optonline.com> References: <43E37073.5050803@optonline.com> Message-ID: <43E376B2.1020000@optonline.com> Arthur wrote: >More surprising was the html colorizing problem. The colorizing code >relies on tokenize.py from the standard library - which keeps choking on >code that compiles and runs fine by Python. So I go to tabnanny.py, >which is seems to be there exactly to diagnose these kinds of issues. >But one of the symptoms of the problem is that tabnanny (i.e tokenize) >is parsing the file in such a way that it is reporting back line numbers >that don't correspond to the code when viewed in a text editor. > > More positive note - finding tabnanny.py. Never understood what it was and why it was there before. But when I find myself putting print statements into tokenize.py library code, I just sense - having been around a while - that Python doesn't want me to be resorting to this and probably has a battery included that is more appropriate. Which is when I backed off and found tabnanny. Art From ajsiegel at optonline.net Fri Feb 3 18:03:42 2006 From: ajsiegel at optonline.net (Arthur) Date: Fri, 03 Feb 2006 12:03:42 -0500 Subject: [Edu-sig] whitespace and newlines and seperators ... oh my In-Reply-To: <43E37073.5050803@optonline.com> Message-ID: <000801c628e3$c99c9fd0$1702a8c0@BasementDell> > >Turns out (I think) - this took be a while - that tokenize > >seems to be trying to parse things between triple quoted > >strings, and since there is a lot of code intended to output > >to Povray SDL and formatted for that purpose - it is choking > >on whitespace issues (that IMO shouldn't be > >issues) in that code. > > Probably more accurate to think of it as readline reporting to tokenizer in some unanticipated way. Originally thought this had to do with the way I tried to play with newlines. Now not so sure - as playing some within the Povray SDL output code sees to have fixed things. For example I had a line with nothing more on it than } On purpose. Moving that to the end of the previous line (I'll live) seemed to get me past the tokenizer problem for that file. But of course in moving it up I was also effecting newlines. So maybe that is what solved it. ???? Art From smiles at worksmail.net Sun Feb 12 19:44:51 2006 From: smiles at worksmail.net (Smith) Date: Sun, 12 Feb 2006 12:44:51 -0600 Subject: [Edu-sig] nice() Message-ID: <038701c63004$733603c0$132c4fca@csmith> I've been thinking about a function that was recently proposed at python-dev named 'areclose'. It is a function that is meant to tell whether two (or possible more) numbers are close to each other. It is a function similar to one that exists in Numeric. One such implementation is def areclose(x,y,abs_tol=1e-8,rel_tol=1e-5): diff = abs(x-y) return diff <= ans_tol or diff <= rel_tol*max(abs(x),abs(y)) (This is the form given by Scott Daniels on python-dev.) Anyway, one of the rationales for including such a function was: When teaching some programming to total newbies, a common frustration is how to explain why a==b is False when a and b are floats computed by different routes which ``should'' give the same results (if arithmetic had infinite precision). Decimals can help, but another approach I've found useful is embodied in Numeric.allclose(a,b) -- which returns True if all items of the arrays are ``close'' (equal to within certain absolute and relative tolerances) The problem with the above function, however, is that it *itself* has a comparison between floats and it will give undesired result for something like the following test: ### >>> print areclose(2, 2.1, .1, 0) #see if 2 and 2.1 are within 0.1 of each other False >>> ### Here is an alternative that might be a nice companion to the repr() and round() functions: nice(). It is a combination of Tim Peter's delightful 'case closed' presentation in the thread, "Rounding to n significant digits?" [1] and the hidden magic of "prints" simplification of floating point numbers when being asked to show them. It's default behavior is to return a number in the form that the number would have when being printed. An optional argument, however, allows the user to specify the number of digits to round the number to as counted from the most significant digit. (An alternative name, then, could be 'lround' but I think there is less baggage for the new user to think about if the name is something like nice()--a function that makes the floating point numbers "play nice." And I also think the name...sounds nice.) Here it is in action: ### >>> 3*1.1==3.3 False >>> nice(3*1.1)==nice(3.3) True >>> x=3.21/0.65; print x 4.93846153846 >>> print nice(x,2) 4.9 >>> x=x*1e5; print nice(x,2) 490000.0 ### Here's the function: ### def nice(x,leadingDigits=0): """Return x either as 'print' would show it (the default) or rounded to the specified digit as counted from the leftmost non-zero digit of the number, e.g. nice(0.00326,2) --> 0.0033""" assert leadingDigits>=0 if leadingDigits==0: return float(str(x)) #just give it back like 'print' would give it leadingDigits=int(leadingDigits) return float('%.*e' % (leadingDigits,x)) #give it back as rounded by the %e format ### Might something like this be useful? For new users, no arguments are needed other than x and floating points suddenly seem to behave in tests made using nice() values. It's also useful for those computing who want to show a physically meaningful value that has been rounded to the appropriate digit as counted from the most significant digit rather than from the decimal point. Some time back I had worked on the significant digit problem and had several math calls to figure out what the exponent was. The beauty of Tim's solution is that you just use built in string formatting to do the work. Nice. /c [1] http://mail.python.org/pipermail/tutor/2004-July/030324.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060212/1792bf6b/attachment.html From chuck at freshsources.com Mon Feb 13 05:20:17 2006 From: chuck at freshsources.com (Chuck Allison) Date: Sun, 12 Feb 2006 21:20:17 -0700 Subject: [Edu-sig] nice() In-Reply-To: <038701c63004$733603c0$132c4fca@csmith> References: <038701c63004$733603c0$132c4fca@csmith> Message-ID: <113575776.20060212212017@freshsources.com> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060212/e19c43f5/attachment-0001.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ulps.h Url: http://mail.python.org/pipermail/edu-sig/attachments/20060212/e19c43f5/attachment-0001.pot -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: prog1.cpp Url: http://mail.python.org/pipermail/edu-sig/attachments/20060212/e19c43f5/attachment-0001.asc From smiles at worksmail.net Mon Feb 13 18:10:28 2006 From: smiles at worksmail.net (Smith) Date: Mon, 13 Feb 2006 11:10:28 -0600 Subject: [Edu-sig] nice() References: Message-ID: <004f01c630c0$f051e1f0$5f2c4fca@csmith> | From: Josiah Carlson | "Alan Gauld" wrote: || However I do dislike the name nice() - there is already a nice() in || the || os module with a fairly well understood function. perhaps trim(), nearly(), about(), defer_the_pain_of() :-) I've waited to think of names until after writing this. The reason for the last name option may become apparent after reading the rest of this post. || But I'm sure some || time with a thesaurus can overcome that single mild objection. :-) | | Presumably it would be located somewhere like the math module. I would like to see it as accessible as round, int, float, and repr. I really think a round-from-the-left is a nice tool to have. It's obviously very easy to build your own if you know what tools to use. Not everyone is going to be reading the python-dev or similar lists, however, and so having it handy would be nice. | From: Greg Ewing | Smith wrote: | || When teaching some programming to total newbies, a common || frustration is how to explain why a==b is False when a and b are || floats computed by different routes which ``should'' give the || same results (if arithmetic had infinite precision). | | This is just a special case of the problems inherent | in the use of floating point. As with all of these, | papering over this particular one isn't going to help | in the long run -- another one will pop up in due | course. | | Seems to me it's better to educate said newbies not | to use algorithms that require comparing floats for | equality at all. I think that having a helper function like nice() is a middle ground solution to the problem, falling short of using only decimal or rational values for numbers and doing better than requiring a test of error between floating values that should be equal but aren't because of alternate methods of computation. Just like the argument for having true division being the default behavior for the computational environment, it seems a little unfriendly to expect the more casual user to have to worry that 3*0.1 is not the same as 3/10.0. I know--they really are different, and one should (eventually) understand why, but does anyone really want the warts of floating point representation to be popping up in their work if they could be avoided, or at least easily circumvented? I know you know why the following numbers show up as not equal, but this would be an example of the pain in working with a reasonably simple exercise of, say, computing the bin boundaries for a histogram where bins are a width of 0.1: ### >>> for i in range(20): ... if (i*.1==i/10.)<>(nice(i*.1)==nice(i/10.)): ... print i,repr(i*.1),repr(i/10.),i*.1,i/10. ... 3 0.30000000000000004 0.29999999999999999 0.3 0.3 6 0.60000000000000009 0.59999999999999998 0.6 0.6 7 0.70000000000000007 0.69999999999999996 0.7 0.7 12 1.2000000000000002 1.2 1.2 1.2 14 1.4000000000000001 1.3999999999999999 1.4 1.4 17 1.7000000000000002 1.7 1.7 1.7 19 1.9000000000000001 1.8999999999999999 1.9 1.9 ### For, say, garden variety numbers that aren't full of garbage digits resulting from fp computation, the boundaries computed as 0.1*i are not going to agree with such simple numbers as 1.4 and 0.7. Would anyone (and I truly don't know the answer) really mind if all floating point values were filtered through whatever lies behind the str() manipulation of floats before the computation was made? I'm not saying that strings would be compared, but that float(str(x)) would be compared to float(str(y)) if x were being compared to y as in x<=y. If this could be done, wouldn't a lot of grief just go away and not require the use of decimal or rational types for many users? I understand that the above really is just a patch over the problem, but I'm wondering if it moves the problem far enough away that most users wouldn't have to worry about it. Here, for example, are the first values where the running sum doesn't equal the straight multiple of some step size: ### >>> def go(x,n=1000): ... s=0;i=0 ... while snice(i*x): ... return i,s,i*x,`s`,`i*x` ... >>> for i in range(1,100): ... print i, go(i/1000.) ... print ... 1 (60372 60.3719999999 60.372 60.371999999949999 60.372) 2 (49645 99.2899999999 99.29 99.289999999949998 99.290000000000006) ### The soonest the breakdown occurs is at the 22496th multiple of 0.041 for the range given above. By the time someone starts getting into needs of iterating so many times, they will be ready to use the more sophisticated option of nice()--the one which makes it more versatile and less of a patch--the option to round the answers to a given number of leading digits rather than a given decimal precision like round. nice() gives a simple way to think about making a comparison of floats. You just have to ask yourself at what "part per X" do you no longer care whether the numbers are different or not. e.g., for approximately 1 part in 100, use nice(x,2) and nice(y,2) to make the comparison between x and y. Replacing nice(*) with nice(*,6) in the go() defined above produces no discrepancy in values computed the two different ways. Since the cost of str() and '%.*e' is nearly the same, perhaps a default value of leadingDigits=9 would be a good default value, and the float(str()) option could be eliminated from nice. Isn't nice() sort of a poor-man's decimal-type without all the extra baggage? | In my opinion, if you ever find | yourself trying to do this, you're not thinking about | the problem correctly, and your algorithm is simply | wrong, even if you had infinitely precise floats. | As for real world examples of when this would be nice I will have to rely on others to justify this more heavily. Some quick examples that come to mind are: * Creating histograms of physical measurements with limited significant digits (i.e., not lots of digits from computation) * Collecting sets of points within a certain range of a given value (all points within 10% of a given value) * Stopping iterations when computed errors have fallen below a certain threshold. (For this, getting the stopping condition "right" is not so critical because doing one more iteration usually isn't a problem if an error happens to be a tiny bit larger than the required tolerance. However, the leadingDigits option on nice() allows one to even get this stopping condition right to a limited precision, something like ### tol = 1e-5 while 1: #do something and compute err if nice(err,3)<=nice(tol,3): break ### By specifying the leadingDigits value of 3, the user is saying that it's fine to quit when the err >= 0.9995. Since there is no additional cost in specifying more digits, a value of 9 could be used as well. | Ismael at tutor wrote: | How about overloading Float comparison? I'm not so adept at such things--how easy is this to do for all comparisions in a script? in an interactive session? For the latter, if it were easy, perhaps it could be part of a "newbie" mode that could be loaded. I think that some (one above has said so) would rather not have an issue pushed away, they would want to leave things as they are and just learn to work around it, not be given a hand-holding device that is eventually going to let them down anyway. I'm wondering if just having to use the function to make a comparison will be like putting your helmet on before you cycle--a reminder that there may be hazards ahead, proceed with caution. If so, then overloading the Float comparision would be better not done, requiring the "buckling" of the floats within nice(). | | If I have understood correctly, float to float comparison must be done | comparing relative errors, so that when dealing with small but rightly | represented numbers it won't tell "True" just because they're | "close". I | think your/their solution only covers the case when dealing with "big" | numbers. Think of two small numbers that you think might fail the nice test and then use the leadingDigits option (set at something like 6) and see if the problem doesn't disappear. If I understand you correctly, is this such a case: x and y defined below are truly close and nice()'s default comparison would say they are different, but nice(*,6) would say they are the same--the same to the first 6 digits of the exponential representation: ### >>> x=1.234567e-7 >>> y=1.234568e-7 >>> nice(x)==nice(y) False >>> nice(x,6)==nice(y,6) True ### | Chuck Allison wrote on edu-sig: | There is a reliable way to compute the exact number of floating-point | "intervals" (one less than the number of FP numbers) between any two | FP numbers. It is a long-ago solved problem. I have attached a C++ | version. You can't define closeness by a "distance" in a FP system - | you should use this measure instead (called "ulps" - units in the | last place). The distance between large FP numbers may always be | greater than the tolerance you prescribe. The spacing between | adjacent FP numbers at the top of the scale for IEEE double precision | numbers is 2^(972) (approx. 10^(293))! I doubt you're going to make | your tolerance this big. I don't believe newbies can grasp this, but | they can be taught to get a "feel" for floating-point number systems. | You can't write reliable FP code without this understanding. See | http://uvsc.freshsources.com/decimals.pdf. A very readable 13 page introduction to some floating point issues. Thanks for the reference. The author concludes with, "Computer science students don't need to be numerical analysts, but they may be called upon to write mathematical software. Indeed, scientists and engineers use tools like Matlab and Mathematica, but who implements these systems? It takes the expertise that only CS graduates have to write such sophisticated software. Without knowledge of the intricacies of floating-point computation, they will make a mess of things. In this paper I have surveyed the basics that every CS graduate should have mastered before they can be trusted in a workplace that does any kind of computing with real numbers." So perhaps this brings us back to the original comment that "fp issues are a learning opportunity." They are. The question I have is "how soon do they need to run into them?" Is decreasing the likelihood that they will see the problem (but not eliminate it) a good thing for the python community or not? /c From lac at strakt.com Thu Feb 16 10:25:36 2006 From: lac at strakt.com (Laura Creighton) Date: Thu, 16 Feb 2006 10:25:36 +0100 Subject: [Edu-sig] This showed up in my mailbox Message-ID: <200602160925.k1G9PaLK030642@theraft.strakt.com> Possibly of interest. ------- Forwarded Message Return-Path: python-logic-bounces at www.logilab.org Delivery-Date: Thu Feb 16 09:59:44 2006 Date: Wed, 15 Feb 2006 16:34:58 -0600 From: Ralph Miller User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en PyIE, Python Inference Engine, is now available at "DFWPython.org", under "Our Source Repository", thanks to Jeff Rush. The current revision is 0.9.10. What's PyIE ? - ------------- PyIE is an hypothesis based, agenda driven, object oriented inference engine written in Python. Inferencing modes include back chaining, opportunistic forward chaining and explicit forward chaining. The object base supports classes, first-class objects and multiple, dynamic inheritance. PyIE uses a TMS (truth maintenance system) for non-monotonic reasoning. All objects are first class objects and all values are slot values, i.e. data members attached to some object. The GUI uses TKinter and consists of a main control panel and seven editors for the agenda, classes, objects, slots, rules, methods and commands. The knowledge base file types are currently XML and an older Python-like text format. A version is associated with all .py files and when the KBs are saved, this current version number is saved within the knowledge base source files. Only the XML format supports methods and is the default file type. Knowledge is usually, but not always, expressed in rules and the sequencing of the inferencing is controlled by a structure called an agenda. The current truth-values of each clause and each rule are kept in an hypothesis. Rules typically contain the main expression of knowledge and experience. Every rule must be associated with a hypo. Every rule has one or more antecedent clauses, usually termed the 'left hand side' (lhs). Rules may also have one or more consequent clauses; usually termed the 'right hand side' (rhs). In order to prove the associated hypo true, a rule must prove all antecedent clauses true. A hypothesis is simply a truth-value, in PyIE one of four possible values: True, False, Not Known or Unknown. 'Unknown' indicates that the hypo has not been tested, while 'Not Known' specifies that the hypo has been tested but proven neither 'True' nor 'False'. The engine proves hypotheses taken from an agenda. The agenda is hypothesis driven, that is, only hypotheses are contained in the agenda, not rules. The engine selects the relevant hypothesis to be proved and follows a specific set of steps to prove the hypo. Firing rules is only one method for proving a hypothesis. Download - -------- The current PyIE may be exported from the subversion repository: https://python.taupro.com/repo/Projects/PyIE/trunk Compressed gzip and zip files will be available from time to time from: https://python.taupro.com/repo/Projects/PyIE/downloads External Dependencies - --------------------- PyIE relies on Python 2.3 and later and also TKinter. No other modules need be installed. License - ------- The license is MIT. Caveats - ------- This is a research project. The documenetation is woefully incomplete. 'Eval' and 'compile' are used in the "KBsXML.py" module to process rules and methods. The underlying assumption is that there will be no malicious use. Author - ------ Ralph S. Miller miller_ralph at sbcglobal.net Regards, Ralph _______________________________________________ Python-logic mailing list Python-logic at lists.logilab.org http://lists.logilab.org/mailman/listinfo/python-logic ------- End of Forwarded Message From adam at monkeez.org Fri Feb 17 09:52:09 2006 From: adam at monkeez.org (adam) Date: Fri, 17 Feb 2006 08:52:09 +0000 Subject: [Edu-sig] leave Message-ID: <43F58EB9.9080701@monkeez.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature Url : http://mail.python.org/pipermail/edu-sig/attachments/20060217/a79b4b97/attachment.pgp From kirby.urner at gmail.com Fri Feb 24 01:03:17 2006 From: kirby.urner at gmail.com (kirby urner) Date: Thu, 23 Feb 2006 16:03:17 -0800 Subject: [Edu-sig] More Python in the Classroom Message-ID: So I taught Python to 8th graders again this morning, as I've been doing for the last 10-11 weeks. I used the "dog theme", introducing a simple Dog class, per recent thread with Andre, in IDLE: class Dog: def __init__(self, name): self.name = name and using it to create instances dog1, dog2 (Fido and Rover). Then I went back and added a bark method. The point was to introduce the class/instance distinction. I use this wrap about a house blueprint, and an architect using it to build an instance in Beaverton and Mt. Tabor (local neighborhoods): one blueprint, two actual houses (or house objects). Then I go back to my dogs. All this is a prelude to reinforcing "dot notation" i.e. now that we have dog.name and dog.bark(1), it makes more sense to discuss a first collection type: lists. We gradually build up the following function, in several iterations, with kids entering at their workstations, watching my projected version up front: def askme(howmany=3): dogs = [] for i in range(howmany): thedog = raw_input("Dog's name? ") dogs.append(thedog) dogs.sort() return dogs I was thinking of Arthur's suggesting to reinforce the distinction between 'print' and 'return'. A first draft of the above function simply prints, doesn't sort. Then I talk about returning a value versus echoing it to screen (essentially what 'print' does -- not to a printer (one girl asked me about that)). Also, we start without any argument, looping 3 times. Adding howmany is a separate step, making it default to 3 yet another iteration. I like the way IDLE lets me "copy down" i.e. continually re-edit a given function, gradually adding to it. I'm projecting in 20 pt type or so, using Comic Sans (looks friendly). This is all very basic stuff, not breaking much new ground. I'm experimenting with how to introduce "dot notation" which I regard as very important. Really, it should be incorporated into standard math notations in a more integral way. object.verb(args) and object.property just makes a lot of sense as a standard way to notate. """ In my view, the mathematicians have been too slow to acknowledge dot notation as a legitimate contribution to mathematics proper. The math books don't allow that A.b(z) is a good way to organize thinking, A being an object of some type, perhaps inheriting from parent types, and b being a method, accepting argument(s) z. v1.add(v2) is as smart a way to signify vector addition as v1 + v2, plus makes it clear where the methods belong: in the class definitions. When math students are asked to actually number crunch with these mathematical objects (quaternions say), dot notation is what they encounter, more often than not. And yet there's this artificial line that gets drawn: "that's just the computer's way of expressing things, not really a math notation" is the party line (I'm not in that party). """ Source: http://mail.geneseo.edu/pipermail/math-thinking-l/2006-February/000982.html Another recent mention of Python in education (today, by me): http://mathforum.org/kb/thread.jspa?threadID=1337652&tstart=0 Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060223/0a70bde5/attachment.html From ajsiegel at optonline.net Fri Feb 24 04:14:22 2006 From: ajsiegel at optonline.net (ajsiegel at optonline.net) Date: Thu, 23 Feb 2006 22:14:22 -0500 Subject: [Edu-sig] More Python in the Classroom Message-ID: Kirby writes - >I was thinking of Arthur's suggesting to reinforce the distinction between 'print' and 'return'. The only thing I recall is an exchange with John Brawley that I reported here. If I remember correctly, he was creating a VPython sphere in a fucntion, assigning a variable to the function call, and couldn't unerstand why he was getting an attribute error when trying to change the sphere's color. It was simply a matter of explaining to him that since he was not explicity asking the function to return anything, it was returning Nothing - which is Something. So that the Something which he was trying to color was actually exactly the Nothing Something. Not the Sphere Something. ;) Art From kirby.urner at gmail.com Fri Feb 24 04:18:44 2006 From: kirby.urner at gmail.com (kirby urner) Date: Thu, 23 Feb 2006 19:18:44 -0800 Subject: [Edu-sig] More Python in the Classroom In-Reply-To: References: Message-ID: On 2/23/06, ajsiegel at optonline.net wrote: > > Kirby writes - > > >I was thinking of Arthur's suggesting to reinforce the distinction > between 'print' and 'return'. > > The only thing I recall is an exchange with John Brawley that I reported > here. A long time ago I posted an URL to an essay on the theory of OO in Python. You suggested something about 'print' vs 'return' might be in order (at least such is my memory). Here's the essay in question if curious (the PDF in this directory): http://www.4dsolutions.net/satacad/background/ If I remember correctly, he was creating a VPython sphere in a fucntion, > assigning a variable to the > function call, and couldn't unerstand why he was getting an attribute > error when trying to > change the sphere's color. I think I dimly recall this too. Not sure. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060223/08d58ee7/attachment.html From radenski at chapman.edu Fri Feb 24 04:25:24 2006 From: radenski at chapman.edu (Atanas Radenski) Date: Thu, 23 Feb 2006 19:25:24 -0800 (PST) Subject: [Edu-sig] Python as a CS1 Language: Updated List of Responses Message-ID: <3276.206.211.137.87.1140751524.squirrel@manitoba.chapman.edu> Hello all, Back in December 2005, I asked for a list of schools that use Python as a CS1/CS2 language. A list is now posted in a Moodle installation that I maintain, http://studypack.com. The list is here: http://studypack.com/comp/mod/glossary/view.php?id=2835 This list is not limited to school names only, but offers a few details, in case details are available. The list is not limitted to CS1/CS2 courses. I will be glad to receive suggestions, corrections, and additional information. Actually, anyone can create an account, login and insert new records, or insert comments on existing records. One can also edit own records. Contributions will be appreciated. Atanas Atanas Radenski mailto:radenski at chapman.edu http://www.chapman.edu/~radenski/ I find television very educating. Every time somebody turns on the set, I go into the other room and read a book - Groucho Marx From pchase at sulross.edu Fri Feb 24 21:29:21 2006 From: pchase at sulross.edu (Peter Chase) Date: Fri, 24 Feb 2006 14:29:21 -0600 Subject: [Edu-sig] Textbooks Message-ID: <43FF6CA1.5050804@sulross.edu> I'm teaching some prospective K-12 teachers this summer and propose to introduce them to Python. Reasons are numerous - It's the least weird language I know. - It offers so many programming styles. - And not least, it's free SO: Any recommendations as to course textbooks? Or just go with Zelle and/or O'Reilly's latest wood rat book? - The students presumably have had programming courses already. - I would think that K-12 students would be happier if they could generate some graphics. - This is a 6-weeks course. Little leisure time. Appreciate any advice. Peter Chase Sul Ross State University From wescpy at gmail.com Fri Feb 24 22:06:09 2006 From: wescpy at gmail.com (w chun) Date: Fri, 24 Feb 2006 13:06:09 -0800 Subject: [Edu-sig] Textbooks In-Reply-To: <43FF6CA1.5050804@sulross.edu> References: <43FF6CA1.5050804@sulross.edu> Message-ID: <78b3a9580602241306n1a6fc085i2b2c3e68e64fad56@mail.gmail.com> On 2/24/06, Peter Chase wrote: > I'm teaching some prospective K-12 teachers this summer and propose to > introduce them to Python. peter, i've been teaching programming to people (kids, adults, everywhere in between) for 24 years now. when i learned python back in 1997, i didn't find a good enough book meant to LEARN *and* TEACH Python with. so.... i wrote my own: Core Python. Prentice Hall/Pearson published by book in 2001... http://corepython.com it's the best book for teaching, and it's not just because i'm a programmer and the author, but more importantly, a technical trainer. there are more exercises (easy, hard, everywhere in between) in Core Python that in all other Python books combined. it is targeted towards secondary schools, universities, and vocational and professional continuing education institutations. i'm currently working on a 2nd edition of the book, to be released late summer, somewhat too late for you, but the 1st edition is still around (but out-of-print), and the material is still relevant and not obsolete, even if it came out in the 2.0 timeframe. one weakness that i would like to address in future editions is to have more of the fun, graphics stuff that i've seen recently. it would be a great addition for those like yourself considering it for the younger crowd. if you're interested in it, let me know, and if you would like to review the 2nd ed or *be* a reviewer for 2nd ed, let me know, and i'll put you in touch with the folks from Prentice Hall. cheers, -- wesley - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "Core Python Programming", Prentice Hall, (c)2006,2001 http://corepython.com wesley.j.chun :: wescpy-at-gmail.com cyberweb.consulting : silicon valley, ca http://cyberwebconsulting.com From andre.roberge at gmail.com Fri Feb 24 22:43:54 2006 From: andre.roberge at gmail.com (Andre Roberge) Date: Fri, 24 Feb 2006 17:43:54 -0400 Subject: [Edu-sig] Textbooks In-Reply-To: <43FF6CA1.5050804@sulross.edu> References: <43FF6CA1.5050804@sulross.edu> Message-ID: <7528bcdd0602241343u650704e9g9d8434548d59dbf6@mail.gmail.com> On 2/24/06, Peter Chase wrote: > I'm teaching some prospective K-12 teachers this summer and propose to > introduce them to Python. Reasons are numerous > - It's the least weird language I know. > - It offers so many programming styles. > - And not least, it's free > > SO: Any recommendations as to course textbooks? Or just go with Zelle > and/or O'Reilly's latest wood rat book? > - The students presumably have had programming courses already. > - I would think that K-12 students would be happier if they could > generate some graphics. > - This is a 6-weeks course. Little leisure time. I imagine that the final goal is to leave them with tools that they can use to teach Python themselves. I would suggest looking at two different approaches, possibly including them both: 1) http://www.livewires.org.uk/python/. 2) either gvr.sourceforge.net or rur-ple.sourceforge.net gvr (Guido van Robot) is the more mature of the two ... but is not really Python (although it is a good introduction that leads to Python programming). rur-ple is an introduction to Python programming. It is still in development and will eventually include an introduction to graphics programming (in the context of simple games); this may not be included by the beginning of this summer though. It has more teaching material included than GvR - but has not been as thoroughly tested. All of the above are free to use. Andr? > > Appreciate any advice. > > Peter Chase > Sul Ross State University > > > > > > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > From Scott.Daniels at Acm.Org Fri Feb 24 23:45:00 2006 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Fri, 24 Feb 2006 14:45:00 -0800 Subject: [Edu-sig] Textbooks In-Reply-To: <43FF6CA1.5050804@sulross.edu> References: <43FF6CA1.5050804@sulross.edu> Message-ID: Peter Chase wrote: > I'm teaching some prospective K-12 teachers this summer and propose to > introduce them to Python.... > SO: Any recommendations as to course textbooks? Or just go with Zelle > and/or O'Reilly's latest wood rat book? > - The students presumably have had programming courses already. > - I would think that K-12 students would be happier if they could > generate some graphics. > - This is a 6-weeks course. Little leisure time. For the weirdest suggestion you'll get, at least take a look at Ruth Chabay & Bruce Sherwood's book, "Matter and Interactions" http://www4.ncsu.edu/~rwchabay/mi They teach both physics and "enough" programming to do 3-d programming on the way to teaching physics. You might be able to make a short course out of the "how to program" part of the books. --Scott David Daniels Scott.Daniels at Acm.Org From gerry.lowry at abilitybusinesscomputerservices.com Sat Feb 25 01:00:29 2006 From: gerry.lowry at abilitybusinesscomputerservices.com (gerry_lowry{905~825'9582}abilityBusinessComputerServices) Date: Fri, 24 Feb 2006 19:00:29 -0500 Subject: [Edu-sig] Textbooks References: <43FF6CA1.5050804@sulross.edu> Message-ID: <012f01c6399e$7e9c5b30$f95cb7d8@D6K8M491> You may want to teach J first, in addition, or instead. http://www.jsoftware.com/ Also FREE. J is the creation of Turing Award winner Ken Iverson and his colleague Roger Hui. "J is a modern, high-level, general-purpose, high-performance programming language. J is portable and runs on Windows, Unix, Mac, and PocketPC handhelds, both as a GUI and in a console. True 64-bit J systems are available for XP64 or Linux64, on AMD64 or Intel EM64T platforms. J systems can be installed and distributed for free." Examples: 5 + 5 10 ADD =. + 5 ADD 5 10 +/ 3 4 5 8 12 45 77 ADDtheseNumbers =. +/ ADDtheseNumbers 3 4 5 8 12 45 77 2 + 5 6 7 7 8 9 i. 6 0 1 2 3 4 5 power =: ^ x power 2 x =. 3 4 5 6 x power 2 9 16 25 36 2 power x 8 16 32 64 J comes with many tutorial labs as part of the IDE. J processes vectors and arrays with ease. J forums have many J'ers willing to guide. regards, gerry "If your only tool is a hammer, all of your problems tend to look like nails". (author unknown) ----- Original Message ----- From: "Peter Chase" To: Sent: Friday, February 24, 2006 3:29 PM Subject: [Edu-sig] Textbooks I'm teaching some prospective K-12 teachers this summer and propose to introduce them to Python. Reasons are numerous - It's the least weird language I know. - It offers so many programming styles. - And not least, it's free SO: Any recommendations as to course textbooks? Or just go with Zelle and/or O'Reilly's latest wood rat book? - The students presumably have had programming courses already. - I would think that K-12 students would be happier if they could generate some graphics. - This is a 6-weeks course. Little leisure time. Appreciate any advice. Peter Chase Sul Ross State University _______________________________________________ Edu-sig mailing list Edu-sig at python.org http://mail.python.org/mailman/listinfo/edu-sig From andre.roberge at gmail.com Sat Feb 25 01:47:10 2006 From: andre.roberge at gmail.com (Andre Roberge) Date: Fri, 24 Feb 2006 20:47:10 -0400 Subject: [Edu-sig] Textbooks In-Reply-To: <012f01c6399e$7e9c5b30$f95cb7d8@D6K8M491> References: <43FF6CA1.5050804@sulross.edu> <012f01c6399e$7e9c5b30$f95cb7d8@D6K8M491> Message-ID: <7528bcdd0602241647kc9541daj414fd41aad0d1b3c@mail.gmail.com> On 2/24/06, gerry_lowry{905~825'9582}abilityBusinessComputerServices wrote: > You may want to teach J first, in addition, or instead. http://www.jsoftware.com/ > > Also FREE. J is the creation of Turing Award winner Ken Iverson and his colleague Roger Hui. > Is it only me that finds this post "offensive". This is a mailing list about using Python in education. The original poster asked for resources to teach Python to teachers. (Granted, I provided one reference [out of 3] to GvR which is not *quite* Python ... but is considered by many to be very close). Andr? > > regards, > gerry > > "If your only tool is a hammer, all of your problems tend to look like nails". (author unknown) > > > From gerry.lowry at abilitybusinesscomputerservices.com Sat Feb 25 04:21:55 2006 From: gerry.lowry at abilitybusinesscomputerservices.com (GerryLowry1(905)825-9582{AbilityBusinessComputerServices}) Date: Fri, 24 Feb 2006 22:21:55 -0500 Subject: [Edu-sig] Textbooks References: <43FF6CA1.5050804@sulross.edu> <012f01c6399e$7e9c5b30$f95cb7d8@D6K8M491> <7528bcdd0602241647kc9541daj414fd41aad0d1b3c@mail.gmail.com> Message-ID: <000001c639bc$af837260$6d02a8c0@dr3sz11> Andre ... before you take offense, you might want to ask Kirby his opinion of J. g. From: "Andre Roberge" Cc: Sent: Friday, February 24, 2006 7:47 PM wrote: > You may want to teach J first, in addition, or instead. http://www.jsoftware.com/ > > Also FREE. J is the creation of Turing Award winner Ken Iverson and his colleague Roger Hui. > Is it only me that finds this post "offensive". This is a mailing list about using Python in education. The original poster asked for resources to teach Python to teachers. (Granted, I provided one reference [out of 3] to GvR which is not *quite* Python ... but is considered by many to be very close). Andr? > regards, > gerry > > "If your only tool is a hammer, all of your problems tend to look like nails". (author unknown) From chuck at freshsources.com Sat Feb 25 06:18:16 2006 From: chuck at freshsources.com (Chuck Allison) Date: Fri, 24 Feb 2006 22:18:16 -0700 Subject: [Edu-sig] Textbooks In-Reply-To: <012f01c6399e$7e9c5b30$f95cb7d8@D6K8M491> References: <43FF6CA1.5050804@sulross.edu> <012f01c6399e$7e9c5b30$f95cb7d8@D6K8M491> Message-ID: <14710641812.20060224221816@freshsources.com> J is a reincarnation of Iverson's APL, an array processing language (witness the example below). It has its nice features, but is off topic for this list. Friday, February 24, 2006, 5:00:29 PM, you wrote: g99a> You may want to teach J first, in addition, or instead. http://www.jsoftware.com/ g99a> Also FREE. J is the creation of Turing Award winner Ken g99a> Iverson and his colleague Roger Hui. g99a> "J is a modern, high-level, general-purpose, high-performance g99a> programming language. J is portable and runs on Windows, Unix, Mac, g99a> and PocketPC handhelds, both as a GUI and in a console. True g99a> 64-bit J systems are available for XP64 or Linux64, on AMD64 or Intel g99a> EM64T platforms. J systems can be installed and distributed for free." g99a> Examples: g99a> 5 + 5 g99a> 10 g99a> ADD =. + g99a> 5 ADD 5 g99a> 10 g99a> +/ 3 4 5 8 12 45 g99a> 77 g99a> ADDtheseNumbers =. +/ g99a> ADDtheseNumbers 3 4 5 8 12 45 g99a> 77 g99a> 2 + 5 6 7 g99a> 7 8 9 g99a> i. 6 g99a> 0 1 2 3 4 5 g99a> power =: ^ g99a> x power 2 g99a> x =. 3 4 5 6 g99a> x power 2 g99a> 9 16 25 36 g99a> 2 power x g99a> 8 16 32 64 g99a> J comes with many tutorial labs as part of the IDE. g99a> J processes vectors and arrays with ease. g99a> J forums have many J'ers willing to guide. g99a> regards, g99a> gerry g99a> "If your only tool is a hammer, all of your problems tend to g99a> look like nails". (author unknown) g99a> ----- Original Message ----- g99a> From: "Peter Chase" g99a> To: g99a> Sent: Friday, February 24, 2006 3:29 PM g99a> Subject: [Edu-sig] Textbooks g99a> I'm teaching some prospective K-12 teachers this summer and propose to g99a> introduce them to Python. Reasons are numerous g99a> - It's the least weird language I know. g99a> - It offers so many programming styles. g99a> - And not least, it's free g99a> SO: Any recommendations as to course textbooks? Or just go with Zelle g99a> and/or O'Reilly's latest wood rat book? g99a> - The students presumably have had programming courses already. g99a> - I would think that K-12 students would be happier if they could g99a> generate some graphics. g99a> - This is a 6-weeks course. Little leisure time. g99a> Appreciate any advice. g99a> Peter Chase g99a> Sul Ross State University g99a> _______________________________________________ g99a> Edu-sig mailing list g99a> Edu-sig at python.org g99a> http://mail.python.org/mailman/listinfo/edu-sig g99a> _______________________________________________ g99a> Edu-sig mailing list g99a> Edu-sig at python.org g99a> http://mail.python.org/mailman/listinfo/edu-sig -- Best regards, Chuck From kirby.urner at gmail.com Sat Feb 25 16:11:36 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 25 Feb 2006 07:11:36 -0800 Subject: [Edu-sig] Textbooks In-Reply-To: <14710641812.20060224221816@freshsources.com> References: <43FF6CA1.5050804@sulross.edu> <012f01c6399e$7e9c5b30$f95cb7d8@D6K8M491> <14710641812.20060224221816@freshsources.com> Message-ID: Yeah J is fun. If Python is the least weird, J is maybe the most weird language I know ("know"). J is one of those languages that rewards cleverness -- the kind of cleverness that leaves other coders in the dust sometimes (or oneself, when feeling less inspired). I've got some writings on it linked from my CP4E page: http://www.4dsolutions.net/ocn/cp4e.html Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060225/92638cfd/attachment.htm From kirby.urner at gmail.com Sat Feb 25 16:20:09 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 25 Feb 2006 07:20:09 -0800 Subject: [Edu-sig] Textbooks In-Reply-To: <43FF6CA1.5050804@sulross.edu> References: <43FF6CA1.5050804@sulross.edu> Message-ID: > SO: Any recommendations as to course textbooks? Or just go with Zelle > and/or O'Reilly's latest wood rat book? > - The students presumably have had programming courses already. > - I would think that K-12 students would be happier if they could > generate some graphics. > - This is a 6-weeks course. Little leisure time. > > Appreciate any advice. > > Peter Chase > Sul Ross State University I still like Zelle's best and includes some graphics (Tk-based, using his own graphics.py). Some of the online tutorials are quite worthwhile as well: http://diveintopython.org/ is freely downloadable. Or roll your own (that's what I've been doing). Another way to get graphics is to write scene description language (POV-Ray) or even VRML from Python. I've used this approach successfully, but only because I give students access to prewritten modules. Like, we might build our own vector class, with a module that already expects to use vectors. VPython is still more graphically exciting. If you're teaching people who're going to be in turn teaching Python, then I think the job is more to showcase what's possible, often in demo mode. Give a sense of the possibilities. Mastery of all these options needn't be the goal of the course. I'd focus on enough mastery of basic core Python to leave students with a sense of "hey, this ain't so hard, I could really be productive with this!" Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060225/cb3c3f4e/attachment.htm From pebarrett at gmail.com Sat Feb 25 18:18:47 2006 From: pebarrett at gmail.com (Paul Barrett) Date: Sat, 25 Feb 2006 12:18:47 -0500 Subject: [Edu-sig] Textbooks In-Reply-To: <012f01c6399e$7e9c5b30$f95cb7d8@D6K8M491> References: <43FF6CA1.5050804@sulross.edu> <012f01c6399e$7e9c5b30$f95cb7d8@D6K8M491> Message-ID: <40e64fa20602250918k78f74c1eybc36f33d780d8d68@mail.gmail.com> The multidimensional array modules in their various incarnations, Numeric, Numarray and Numpy - with the Numpy being the latest and hopeful last - are based on J's array semantics and behaviour. So in some sense, you can teach J programming concepts by using Numpy. Have you you tried Numpy? -- Paul On 2/24/06, gerry_lowry{905~825'9582}abilityBusinessComputerServices < gerry.lowry at abilitybusinesscomputerservices.com> wrote: > > You may want to teach J first, in addition, or instead. > http://www.jsoftware.com/ > > Also FREE. J is the creation of Turing Award winner Ken Iverson and his > colleague Roger Hui. > > "J is a modern, high-level, general-purpose, high-performance programming > language. J is portable and runs on Windows, Unix, Mac, > and PocketPC handhelds, both as a GUI and in a console. True 64-bit J > systems are available for XP64 or Linux64, on AMD64 or Intel > EM64T platforms. J systems can be installed and distributed for free." > > Examples: > > 5 + 5 > 10 > > ADD =. + > > 5 ADD 5 > 10 > > +/ 3 4 5 8 12 45 > 77 > > ADDtheseNumbers =. +/ > > ADDtheseNumbers 3 4 5 8 12 45 > 77 > > 2 + 5 6 7 > 7 8 9 > > i. 6 > 0 1 2 3 4 5 > > power =: ^ > x power 2 > > > x =. 3 4 5 6 > x power 2 > 9 16 25 36 > 2 power x > 8 16 32 64 > > > J comes with many tutorial labs as part of the IDE. > > J processes vectors and arrays with ease. > > J forums have many J'ers willing to guide. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060225/68b9d369/attachment.html From ajsiegel at optonline.net Sat Feb 25 18:55:50 2006 From: ajsiegel at optonline.net (Arthur) Date: Sat, 25 Feb 2006 12:55:50 -0500 Subject: [Edu-sig] Textbooks In-Reply-To: References: <43FF6CA1.5050804@sulross.edu> Message-ID: <44009A26.80206@optonline.com> kirby urner wrote: > > SO: Any recommendations as to course textbooks? Or just go with > Zelle > and/or O'Reilly's latest wood rat book? > - The students presumably have had programming courses already. > - I would think that K-12 students would be happier if they could > generate some graphics. > - This is a 6-weeks course. Little leisure time. > > Appreciate any advice. > > Peter Chase > Sul Ross State University > > > I still like Zelle's best and includes some graphics (Tk-based, using > his own graphics.py). > > Some of the online tutorials are quite worthwhile as well: > http://diveintopython.org/ is freely downloadable. > > Or roll your own (that's what I've been doing). > > Another way to get graphics is to write scene description language > (POV-Ray) or even VRML from Python. I've used this approach > successfully, but only because I give students access to prewritten > modules. Like, we might build our own vector class, with a module > that already expects to use vectors. > > VPython is still more graphically exciting. My fun this week in some sense involved some synthesis of these approaches - having come to a "what is possible" revelation. PyGeo uses VPython for vector graphics, and exports to POV-Ray - producing a high quality "still" of what one is observing on the screen. Except that I hadn't been able to find a way to reliably reproduce a representation of a flat plane in POV-Ray that closely resembled the PyGeo plane - which is just a mesh of thin lines (the vpytbon curve object)- exported to POV-Ray the lines showed too much of their thickness, and the illusion of flatness, essential to a plane was lost. I realized what *does* work is a image map of a line mesh - with appropriate transparencies - applied to a flat polygon, scaled and oriented appropriately in POV-Ray. But PyGeo allows one to apply any color to a plane. I would lose that in POV-Ray if I used a particular image map, or even some collection of them. Ah-ha. I now have PIL creating a the image map - transparencies and all - on the fly. One can have an unlimited number of plane objects represented in an unlimited number of colors created in POV_Ray, pretty reliably representing what one is seeing in the on screen rendering. There is about 10 lines of easy to follow code involved. Too much fun. Art From ajsiegel at optonline.net Sat Feb 25 19:11:56 2006 From: ajsiegel at optonline.net (Arthur) Date: Sat, 25 Feb 2006 13:11:56 -0500 Subject: [Edu-sig] Textbooks In-Reply-To: <40e64fa20602250918k78f74c1eybc36f33d780d8d68@mail.gmail.com> References: <43FF6CA1.5050804@sulross.edu> <012f01c6399e$7e9c5b30$f95cb7d8@D6K8M491> <40e64fa20602250918k78f74c1eybc36f33d780d8d68@mail.gmail.com> Message-ID: <44009DEC.6060808@optonline.com> Paul Barrett wrote: > The multidimensional array modules in their various incarnations, > Numeric, Numarray and Numpy - with the Numpy being the latest and > hopeful last - are based on J's array semantics and behaviour. So in > some sense, you can teach J programming concepts by using Numpy. > > Have you you tried Numpy? I am glad to see the Numeric, NumArray, Numpy line mentioned in the context of Python and education. It is, was and has been essential for me in the learning experience I have undertaken with Python. No question that I would have passed Python by early in the game if it was not there. (JIm Huginin, late of IronPython (i.e. .Net Python started the processs, if I understand correctly) And I am routing for its eventual inclusion in the standard Python distribution. Art > -- Paul > > On 2/24/06, *gerry_lowry{905~825'9582}abilityBusinessComputerServices* > < gerry.lowry at abilitybusinesscomputerservices.com > > wrote: > > You may want to teach J first, in addition, or instead. > http://www.jsoftware.com/ > > Also FREE. J is the creation of Turing Award winner Ken Iverson > and his colleague Roger Hui. > > "J is a modern, high-level, general-purpose, high-performance > programming language. J is portable and runs on Windows, Unix, Mac, > and PocketPC handhelds, both as a GUI and in a console. True > 64-bit J systems are available for XP64 or Linux64, on AMD64 or Intel > EM64T platforms. J systems can be installed and distributed for free." > > Examples: > > 5 + 5 > 10 > > ADD =. + > > 5 ADD 5 > 10 > > +/ 3 4 5 8 12 45 > 77 > > ADDtheseNumbers =. +/ > > ADDtheseNumbers 3 4 5 8 12 45 > 77 > > 2 + 5 6 7 > 7 8 9 > > i. 6 > 0 1 2 3 4 5 > > power =: ^ > x power 2 > > > x =. 3 4 5 6 > x power 2 > 9 16 25 36 > 2 power x > 8 16 32 64 > > > J comes with many tutorial labs as part of the IDE. > > J processes vectors and arrays with ease. > > J forums have many J'ers willing to guide. > > >------------------------------------------------------------------------ > >_______________________________________________ >Edu-sig mailing list >Edu-sig at python.org >http://mail.python.org/mailman/listinfo/edu-sig > > From gerry.lowry at abilitybusinesscomputerservices.com Sat Feb 25 19:43:29 2006 From: gerry.lowry at abilitybusinesscomputerservices.com (GerryLowry1(905)825-9582{AbilityBusinessComputerServices}) Date: Sat, 25 Feb 2006 13:43:29 -0500 Subject: [Edu-sig] NumPy (was: Textbooks) References: <43FF6CA1.5050804@sulross.edu> <012f01c6399e$7e9c5b30$f95cb7d8@D6K8M491> <40e64fa20602250918k78f74c1eybc36f33d780d8d68@mail.gmail.com> Message-ID: <005901c63a3b$5fe5b950$6d02a8c0@dr3sz11> Paul, no, I have not tried NumPy (Numerical Extensions To Python). The only Python (yet to be read) book that I own is Andre Lessa's "Python Developer's Handbook", 2001, SAMS. Lessa mentions briefly (p. 15, last paragraph) NumPy and again later (pp. 364-367). Lessa shows not a line of NumPy on those pages, although he gives URL's. Lessa fails to mention the connection to J, perhaps for fear of frightening us away. Calling Java::Python "JPython" further dooms J to anonymity. I.e., it leads one to think of "J" as implying Java. Likewise, the Evil Empire's J++ and J# products. Kirby is correct about the ability to write really weird looking code in J. (I assume that is what is meant by "J is maybe the most weird language I know"). Paul, thank you ... NumPy is now on my list of future investigations. regards, gerry "If your only tool is a hammer, all of your problems tend to look like nails". (author unknown) From: "Paul Barrett" Sent: Saturday, February 25, 2006 12:18 PM Subject: Re: [Edu-sig] Textbooks The multidimensional array modules in their various incarnations, Numeric, Numarray and Numpy - with the Numpy being the latest and hopeful last - are based on J's array semantics and behaviour. So in some sense, you can teach J programming concepts by using Numpy. Have you you tried Numpy? From gerry.lowry at abilitybusinesscomputerservices.com Sat Feb 25 20:00:46 2006 From: gerry.lowry at abilitybusinesscomputerservices.com (GerryLowry1(905)825-9582{AbilityBusinessComputerServices}) Date: Sat, 25 Feb 2006 14:00:46 -0500 Subject: [Edu-sig] Textbooks References: <43FF6CA1.5050804@sulross.edu><012f01c6399e$7e9c5b30$f95cb7d8@D6K8M491> <14710641812.20060224221816@freshsources.com> Message-ID: <005f01c63a3d$cc0714b0$6d02a8c0@dr3sz11> Chuck, based on the relation of J to NumPy as expressed by Paul and the context of Peter's opening message of this thread, to which I originally replied, imho, my reply was on topic ... of course, biased am I. MORE INFORMATION ---------------- While this -sig is primarily about Python, it appears also to be about education. I have been learning about programming since 1967 and truly think the more programming languages to which one is exposed, the better programmer she/he will become. q.v.: "Ken's life was based on the importance of education and teaching" http://www.vector.org.uk/?area=kei&page=iverson regards, gerry "If your only tool is a hammer, all of your problems tend to look like nails". (author unknown) From: "Peter Chase" Sent: Friday, February 24, 2006 3:29 PM I'm teaching some prospective K-12 teachers this summer and propose to introduce them to Python. Reasons are numerous - It's the least weird language I know. - It offers so many programming styles. - And not least, it's free SO: Any recommendations as to course textbooks? Or just go with Zelle and/or O'Reilly's latest wood rat book? - The students presumably have had programming courses already. - I would think that K-12 students would be happier if they could generate some graphics. - This is a 6-weeks course. Little leisure time. Appreciate any advice. Peter Chase Sul Ross State University From christian.mascher at gmx.de Sat Feb 25 20:53:48 2006 From: christian.mascher at gmx.de (Christian Mascher) Date: Sat, 25 Feb 2006 20:53:48 +0100 Subject: [Edu-sig] First things first (Re: Python in the Classroom) In-Reply-To: References: Message-ID: <4400B5CC.5080809@gmx.de> Hi, I'm currently introducing 9th graders (15-16 year-old) with no prior coding experience (apart from a little bit of HTML/CSS) to basic programming with Python. We have only just started in this group. Some background: We meet twice a week, on mondays for 90 minutes (two lesson hours, one of them not in the computer lab, so only demonstration possible)), on thursday for 45 minutes. @ Kirby: 8th-graders are 14 year-olds, right? (That is: do you count classes from primary school grade 1 (like we do here)? How many lesson hours do you have? When starting with total newbies, you have to decide very carefully, what to explain in what order. Python being so "easy" (for someone who already knows what programming is about), it is also easy to go too fast. And you will always want to introduce quite a lot of ideas pretty soon, in order do to something interesting. On the other hand: Learners will probably appreciate a common solution (say: loops) better, if they have noticed the tediousness of programming without such a means _first_. I have looked at two books which address these items in a similar way: Gregor Lingls German Book "Python f?r Kids" and the new book from Stephane Ducasse: Squeak - Learn programming with Robots (doing it the smalltalk way). Both take a Logo-like approach with turtle graphics as a first start. Something which always seems to work with children of all ages in my experience (besides producing nice graphics as a visual feedback and reward). Differences (in the mentioned books) of course concern the syntax and the environment. For Python you have to explain the difference between interacting with Python via the Idle Shell-Window and using a File-Window (for saving the work properly) soon. These are "first things" you can't leave out. Then Ducasse produces turtles as Objects and calls methods on these to draw simple pictures. No problem. Rather than using turtle.py directly, I have always put an extra file named turtlegraphics in a reachable directory on the network (in my pythonpath). I have now modified it to include no module-level functions but only a Turtle class - of course just an interface to turtle.py. I also like it, when the method names are German - you see at a glance the difference between Python keywords and simple methods of an Object. So the standard interaction is (translated back to English): >>> from turtlegraphics import Turtle >>> joe=Turtle() # I don't really explain this much >>> joe.forward(80) >>> joe.color('red') So right from the start, we have dot-notation calling methods on instances we first have to create by calling a "factory" Turtle. Another good thing is also that >>> dir(joe) will only deliver the known methods, wheras the module turtle.py (where all the real programming was done for me) contains all sorts of things, and no class Turtle, but a Pen. This is quite the way Ducasse does it in Smalltalk/Squeak. I only can't exchange turtle joe's shape with my own drawing (like in squeak)- but I have found Python Tkinter runs a lot faster on my old machines than the fullblown squeak environment. And why not stay simple, when teaching simple, beginner things? How do we start? I try to introduce only _one_ *big idea* at once. On top of this there is still a lot of small bits (syntax, file saving, using the IDLE-Shell, correcting errors etc.) they have to learn along the way. Some first *big* ideas in my sequence are: 1. Code as a linear flow of statements as "commands" 2. Functions without parameters as abbreviation for longer parts of reuseable code 3. Loops on a list We actually did some "Using Python as a Calculator" in the Idle-Shell in the first lesson (Big Idea #1: Shell commands). Long Integers are a motivating factor (which pocket calculator could really tell you the result of 2**100?). I also introduced math.sqrt() because luckily they have just learned sqrt in maths, and it gives a first impression of "functions". More than one of them stumbled over some "wrong" results (float representation): To explain this properly, I would have needed another lesson, but I guess at this stage it is not that they are _that_ interested in the question (just wanted a _short_ answer). In a second lesson we defined some own mathematical functions in an informal way: Just like a function in maths with an x between the brackets and "return" something to deliver the result. No further treatment of this at this stage - I want turtlegraphics now. In the first lesson with turtlegraphics, pupils drew simple pictures (and had to use pythagoras a**2+b**2=c**2 to compute the length of a diagonal) using turtles they gave a funny name first. Then we defined a function triangle() (deliberately without parameters first time) to draw *many* triangles, reusing code by calling "subprograms". I let them figure out how to draw a "color wheel" with six triangles, using our triangle() function. This, they should do in a file, so they know about saving modules: -----start file----- from turtlegrphics import Turtle t=Turtle() def triangle(): # main program: t.color('red') t.fill(1) triangle() t.fill(0) t.left(60) t.color('orange') t.fill(1) triangle() t.fill(0) --------------- I hope this tedious repetition with only the color changing is motivation enough to call for a loop on a list: for colorname in ['red','orange','yellow','green','blue','purple']: t.color(colorname) t.fill(1) ... you get the impression From there on I will develop the loop for drawing a square: >>> for sidenumber in [1,2,3,4]: ... actually we don't need sidenumber here >>> for sidenumber in [0,1,2,3]: ... because computer scientists start counting with a zero >>> for sidenumber in range(4): ... made it to range() at last. Now we can do quite neat things looping with one or more turtles, exercising for-loops (and without much talk, lists on the way) >>> for i in range(18): for i in range(4): joe.forward(50) jack.forward(50) joe.left(90) jack(right(90) joe.left(10) jack.right(10) Sorry for the rather long post, but you didn't have to read it, did you ;-) Cheers, Christian From ajsiegel at optonline.net Sat Feb 25 21:05:08 2006 From: ajsiegel at optonline.net (Arthur) Date: Sat, 25 Feb 2006 15:05:08 -0500 Subject: [Edu-sig] NumPy In-Reply-To: <005901c63a3b$5fe5b950$6d02a8c0@dr3sz11> References: <43FF6CA1.5050804@sulross.edu> <012f01c6399e$7e9c5b30$f95cb7d8@D6K8M491> <40e64fa20602250918k78f74c1eybc36f33d780d8d68@mail.gmail.com> <005901c63a3b$5fe5b950$6d02a8c0@dr3sz11> Message-ID: <4400B874.90709@optonline.com> GerryLowry1(905)825-9582{AbilityBusinessComputerServices} wrote: >Paul, no, I have not tried NumPy (Numerical Extensions To Python). > >The only Python (yet to be read) book that I own is Andre Lessa's >"Python Developer's Handbook", 2001, SAMS. > >Lessa mentions briefly (p. 15, last paragraph) NumPy and >again later (pp. 364-367). Lessa shows not a line of NumPy >on those pages, although he gives URL's. Lessa fails to >mention the connection to J, perhaps for fear of frightening us away. > > I don't know the book, but it doesn't sound very oriented toward education. But I would say that there seems to be a strange consensus of irreconcilable positions in books that *are* educationally oriented - especially in those oriented toward younger people - that computer graphics are a good and primary way to introduce things, and that the mathematics is frightening and should be avoided. One thing, I think, to appreciate about J is that it would have no part of this. I have a J book which fully appreciates the fun and motivating force of creating graphics, mathematically. With the "mathematically" being to the essence. But I have personally found that there is in the Python world actually a more complete set of tools to use to explore this "space" of the connection between mathematics and graphics (we can call it "art" if we want) than is true in the J world. The Numeric /Numpy line central to almost all of them. In my little POV-ray story, I need to be able to take the 1 unit square polygon on the XY plane and orient it precisely to some distinct (but arbitrary) position in 3d space. There are no buttons to push to do so. Except for the matrix "button". Nobody could stop me from finding that button. To someone like myself, the connection between the art and the mathematics is the more interesting and educational part of the story - the computing language syntax, the less. Art Art >Calling Java::Python "JPython" further dooms J to anonymity. >I.e., it leads one to think of "J" as implying Java. Likewise, >the Evil Empire's J++ and J# products. > >Kirby is correct about the ability to write really weird looking code in J. >(I assume that is what is meant by "J is maybe the most weird language I know"). > >Paul, thank you ... NumPy is now on my list of future investigations. > >regards, > gerry >"If your only tool is a hammer, all of your problems tend to look like nails". (author unknown) > >From: "Paul Barrett" >Sent: Saturday, February 25, 2006 12:18 PM >Subject: Re: [Edu-sig] Textbooks > >The multidimensional array modules in their various incarnations, Numeric, >Numarray and Numpy - with the Numpy being the latest and hopeful last - are >based on J's array semantics and behaviour. So in some sense, you can teach >J programming concepts by using Numpy. > >Have you you tried Numpy? > >_______________________________________________ >Edu-sig mailing list >Edu-sig at python.org >http://mail.python.org/mailman/listinfo/edu-sig > > > > From jeff at elkner.net Sat Feb 25 23:43:17 2006 From: jeff at elkner.net (Jeffrey Elkner) Date: Sat, 25 Feb 2006 22:43:17 +0000 Subject: [Edu-sig] edupy bof at pycon2006 In-Reply-To: Message-ID: <20060225224317.6122.959266395.divmod.quotient.7797@ohm> Hi All! We had a "Python in Education" BOF at PyCon2006 last night that was both productive and exciting. The wiki page describing goals we discussed as well as providing contact information for the attendees can be found here: http://edupy.pbwiki.com Andrew Harrington offered to look into providing us with web space (and perhaps a place to move our wiki) when he gets back to Loyola University. Michael Tobis kindly offered to help me make the next edition of "How to Think Like a Computer Scientist: Learning with Python" into a "live" textbook. I've already approached Cannonical about getting help with hosting for bzr repositories for software and educational materials. Question: Is everyone who attended the BOF and/or who is interested in the project on the edu-sig mailing list? We agreed that the edu-sig list is the natural place to for emails concerning our efforts. I'll be back soon with more information... jeff elkner open book project http://ibiblio.org/obp From bmiller at luther.edu Sun Feb 26 00:31:16 2006 From: bmiller at luther.edu (Brad Miller) Date: Sat, 25 Feb 2006 17:31:16 -0600 Subject: [Edu-sig] SIGCSE 2006 - Special Session on Teaching with Python Message-ID: <131679A9-9459-4A5E-9EAE-9ACAD1D138EB@luther.edu> The last note about the Python in Education BOF at PyCon inspired me to send this out. John Zelle, Mark Guzdial, David Ranum, and myself will be hosting a special session on teaching introductory computer science with Python at SIGCSE this week. I hope that this will be an opportunity to meet some of you folks on the list face to face and have some great discussion about teaching with Python. Hope to see you there! Brad -- Brad Miller, PhD Assistant Professor Luther College http://www.cs.luther.edu/~bmiller jabber: bnmnetp at jabber.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060225/27702598/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/edu-sig/attachments/20060225/27702598/attachment.pgp From DAjoy at openworldlearning.org Sun Feb 26 05:47:33 2006 From: DAjoy at openworldlearning.org (Daniel Ajoy) Date: Sat, 25 Feb 2006 21:47:33 -0700 Subject: [Edu-sig] Textbooks Message-ID: On 25 Feb 2006 at 20:01, edu-sig-request at python.org wrote: > Date: Sat, 25 Feb 2006 12:18:47 -0500 > From: "Paul Barrett" > > The multidimensional array modules in their various incarnations, Numeric, > Numarray and Numpy - with the Numpy being the latest and hopeful last - are > based on J's array semantics and behaviour. So in some sense, you can teach > J programming concepts by using Numpy. > > Have you you tried Numpy? > > -- Paul Really_ can any of those tools be used to program tacitly? That is without the need to use variables (with the help of "forks", "hooks" and the like)? Daniel ***************************** OpenWorld Learning http://www.openworldlearning.org From kirby.urner at gmail.com Sun Feb 26 11:52:44 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 26 Feb 2006 02:52:44 -0800 Subject: [Edu-sig] First things first (Re: Python in the Classroom) In-Reply-To: <4400B5CC.5080809@gmx.de> References: <4400B5CC.5080809@gmx.de> Message-ID: > > @ Kirby: 8th-graders are 14 year-olds, right? (That is: do you count > classes from primary school grade 1 (like we do here)? How many lesson > hours do you have? Yes, about 14. I have 'em for about an hour, once a week, for about 9 weeks. When starting with total newbies, you have to decide very carefully, > what to explain in what order. Python being so "easy" (for someone who > already knows what programming is about), it is also easy to go too > fast. And you will always want to introduce quite a lot of ideas pretty > soon, in order do to something interesting. On the other hand: Learners > will probably appreciate a common solution (say: loops) better, if they > have noticed the tediousness of programming without such a means _first_. Given this is 8th grade, I look at it as first exposure or a first pass. Some stuff will go over their heads, some will stick. It's not necessary that they be complete masters of everything they see. I think a lot of education is previewing. What I dislike about most math curricula is how it's taboo to look ahead and see where we're going. I have looked at two books which address these items in a similar way: > Gregor Lingls German Book "Python f?r Kids" and the new book from > Stephane Ducasse: Squeak - Learn programming with Robots (doing it the > smalltalk way). Both take a Logo-like approach with turtle graphics as a > first start. Something which always seems to work with children of all > ages in my experience (besides producing nice graphics as a visual > feedback and reward). I think this robots approach is valid, works, is likely to remain popular. That being said, I'm not using it these days (I leave the door open to using it in future -- I expect my daughter will like it (she owns 2 robot dogs). Other approaches work too. I understand the Sony robot dog has Python bindings but have no details. Sony should send me a sample. :-D Differences (in the mentioned books) of course concern the syntax and > the environment. For Python you have to explain the difference between > interacting with Python via the Idle Shell-Window and using a > File-Window (for saving the work properly) soon. These are "first > things" you can't leave out. Yes, I tend to agree. We use the shell for awhile, interacting. Then , after we've developed some function worth saving, using repeated edits in the shell (debugging as we go), I show 'em how to cut and paste to a file window, to save as a .py in site-packages. > So the standard interaction is (translated back to English): > >>> from turtlegraphics import Turtle > >>> joe=Turtle() # I don't really explain this much > >>> joe.forward(80) > >>> joe.color('red') > > So right from the start, we have dot-notation calling methods on > instances we first have to create by calling a "factory" Turtle. This looks good to me. Last week, we programmed a simple Dog class. Maybe we'll use the turtle before the 8 weeks is done. Another good thing is also that > >>> dir(joe) > will only deliver the known methods, wheras the module turtle.py (where > all the real programming was done for me) contains all sorts of things, > and no class Turtle, but a Pen. Yes, I make use of dir() as well, including on primitive types e.g. dir(2). I started out talking about types e.g. type(2), type(2.0) and type('hello'). Thinking in terms of types makes plenty of sense, because what Python provides is "an extensible type system" i.e. you get the primitive types out of the box, then you build your own, adding to the types ( = classes) available. Some first *big* ideas in my sequence are: > > 1. Code as a linear flow of statements as "commands" > 2. Functions without parameters as abbreviation for longer parts of > reuseable code > 3. Loops on a list Looks good. I use a projector, boost IDLE to like 20 point (Comic Sans these days) and have kids follow along at their own workstations as I "doodle" i.e. write simple functions and stuff. Other times I hand out stuff on paper and walk around the room, helping where needed. We actually did some "Using Python as a Calculator" in the Idle-Shell in > the first lesson (Big Idea #1: Shell commands). Long Integers are a > motivating factor (which pocket calculator could really tell you the > result of 2**100?). I also introduced math.sqrt() because luckily they > have just learned sqrt in maths, and it gives a first impression of > "functions". Yes, I very much agree with advertising Python's better-than-calculator powers (leaving aside that we're not using a computer algebra system, which high end calculators provide). More than one of them stumbled over some "wrong" results (float > representation): To explain this properly, I would have needed another > lesson, but I guess at this stage it is not that they are _that_ I get into this pretty early, explaining quickly that floats go into base 2 behind the scenes, then back to base 10 for display, and this introduces some unexpected wrinkles. Nothing to worry about. They get there's an explanation. I'm mainly reassuring, acknowledging that I see what they see. interested in the question (just wanted a _short_ answer). > In a second lesson we defined some own mathematical functions in an > informal way: Just like a function in maths with an x between the > brackets and "return" something to deliver the result. No further > treatment of this at this stage - I want turtlegraphics now. > > In the first lesson with turtlegraphics, pupils drew simple pictures > (and had to use pythagoras a**2+b**2=c**2 to compute the length of a > diagonal) using turtles they gave a funny name first. > > Then we defined a function triangle() (deliberately without parameters > first time) to draw *many* triangles, reusing code by calling > "subprograms". > > I let them figure out how to draw a "color wheel" with six triangles, > using our triangle() function. This, they should do in a file, so they > know about saving modules: > -----start file----- > from turtlegrphics import Turtle > t=Turtle() > def triangle(): > > > # main program: > t.color('red') > t.fill(1) > triangle() > t.fill(0) > t.left(60) > t.color('orange') > t.fill(1) > triangle() > t.fill(0) > > --------------- > I hope this tedious repetition with only the color changing > is motivation enough to call for a loop on a list: > > for colorname in ['red','orange','yellow','green','blue','purple']: > t.color(colorname) > t.fill(1) > ... you get the impression > > From there on I will develop the loop for drawing a square: > >>> for sidenumber in [1,2,3,4]: > ... actually we don't need sidenumber here > >>> for sidenumber in [0,1,2,3]: > ... because computer scientists start counting with a zero > >>> for sidenumber in range(4): > ... made it to range() at last. Now we can do quite neat things looping > with one or more turtles, exercising for-loops (and without much talk, > lists on the way) > > >>> for i in range(18): > for i in range(4): > joe.forward(50) > jack.forward(50) > joe.left(90) > jack(right(90) > joe.left(10) > jack.right(10) > > Sorry for the rather long post, but you didn't have to read it, > did you ;-) > > Cheers, Christian All good stuff. I continue to think programming is a very motivating way to get into mathematics. In the pre-college years, I wouldn't be unhappy to see programming move into the foreground. To make it sound radical and provoke anxiety, I'd say my position is: drop math completely as traditionally taught, and teach computer science instead -- but in a different way that preserves most of the old math content (plus adds a lot of new stuff). A less radical position: offer this as an alternative "track" running in parallel and let it compete with traditional math. That's actually a crueler option (means slow death of traditional math vs. a quick transition to these better methods). Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060226/867ef0e1/attachment-0001.htm From kirby.urner at gmail.com Sun Feb 26 12:01:20 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 26 Feb 2006 03:01:20 -0800 Subject: [Edu-sig] NumPy (was: Textbooks) In-Reply-To: <005901c63a3b$5fe5b950$6d02a8c0@dr3sz11> References: <43FF6CA1.5050804@sulross.edu> <012f01c6399e$7e9c5b30$f95cb7d8@D6K8M491> <40e64fa20602250918k78f74c1eybc36f33d780d8d68@mail.gmail.com> <005901c63a3b$5fe5b950$6d02a8c0@dr3sz11> Message-ID: > > Kirby is correct about the ability to write really weird looking code in > J. > (I assume that is what is meant by "J is maybe the most weird language I > know"). E.g. http://www.4dsolutions.net/ocn/graphics/phistone.jpg Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060226/cfa82d61/attachment.html From ajsiegel at optonline.net Sun Feb 26 15:04:17 2006 From: ajsiegel at optonline.net (Arthur) Date: Sun, 26 Feb 2006 09:04:17 -0500 Subject: [Edu-sig] Textbooks In-Reply-To: Message-ID: <002e01c63add$88ac1440$1702a8c0@BasementDell> > > > >Really_ can any of those tools be used to program tacitly? > >That is without the need to use variables (with the help of > >"forks", "hooks" and the like)? Expressed as someone in touch with esoteric knowledge. I am guessing it's a Logo thing. Are you willing to expand? What is the importance of being able to program "tacitly"? More basic - what do you mean by programming tacitly? Does the fact that I don't find your explanation adequate indicate some problem in my knowledge base? My worldview? Art From ajsiegel at optonline.net Sun Feb 26 15:23:34 2006 From: ajsiegel at optonline.net (Arthur) Date: Sun, 26 Feb 2006 09:23:34 -0500 Subject: [Edu-sig] SIGCSE 2006 - Special Session on Teaching with Python In-Reply-To: <131679A9-9459-4A5E-9EAE-9ACAD1D138EB@luther.edu> References: <131679A9-9459-4A5E-9EAE-9ACAD1D138EB@luther.edu> Message-ID: <4401B9E6.4030208@optonline.com> Brad Miller wrote: > The last note about the Python in Education BOF at PyCon inspired me > to send this out. > > John Zelle, Mark Guzdial, David Ranum, and myself will be hosting a > special session on teaching introductory computer science with Python > at SIGCSE this week. I hope that this will be an opportunity to meet > some of you folks on the list face to face and have some great > discussion about teaching with Python. > > Hope to see you there! > > Brad-- Brad has been quiet about his publication Problem Solving with Algorithms and Data Structures Using Python http://www.fbeedle.com/053-9.html It's certainly of interest to me. Of course Alan Kay expressed this week that the teaching of algorithms and data structures in CS is a problem: that: """nothing exciting about computing today has to do with data structures and algorithms""" (Kay being paraphrased at http://www.windley.com/archives/2006/02/alan_kay_is_com.shtml) I don't think people actually understand how easy it is to talk in the voice of a Visionary- like Kay does. That's the only way he seems to talk in public - perhaps because that is what people have come to expect from him. . What he tends to say seems to me almost mundane, excepting its Grandiose Tone. And I can only assume that people are impressed with the Balls it Takes to talk in such tones. It can't really believe it's the content. Art > Brad Miller, PhD > Assistant Professor > Luther College > http://www.cs.luther.edu/~bmiller > jabber: bnmnetp at jabber.org > > > > >------------------------------------------------------------------------ > >_______________________________________________ >Edu-sig mailing list >Edu-sig at python.org >http://mail.python.org/mailman/listinfo/edu-sig > > From dajoy at openworldlearning.org Sun Feb 26 15:52:10 2006 From: dajoy at openworldlearning.org (Daniel Ajoy) Date: Sun, 26 Feb 2006 09:52:10 -0500 Subject: [Edu-sig] Textbooks In-Reply-To: <002e01c63add$88ac1440$1702a8c0@BasementDell> References: Message-ID: <44017A4A.11968.1C4FA5A4@dajoy.openworldlearning.org> On 26 Feb 2006 at 9:04, Arthur wrote: > > >Really_ can any of those tools be used to program tacitly? > > >That is without the need to use variables (with the help of > > >"forks", "hooks" and the like)? > > > Expressed as someone in touch with esoteric knowledge. > > I am guessing it's a Logo thing. > > Are you willing to expand? I just wanted to verify the claim that some Python modules really incorporate J semantics. > What is the importance of being able to program "tacitly"? You don't need to worry about variables or function parameters if you do. > More basic - what do you mean by programming tacitly? The concept is also called Function-level programming http://en.wikipedia.org/wiki/Function-level_programming http://www.jsoftware.com/books/help/jforc/tacit_programs.htm > Does the fact that I don't find your explanation adequate indicate some > problem in my knowledge base? My worldview? Who am I to judge what is a problem to you? Daniel ***************************** OpenWorld Learning http://www.openworldlearning.org From ajsiegel at optonline.net Sun Feb 26 16:18:22 2006 From: ajsiegel at optonline.net (Arthur) Date: Sun, 26 Feb 2006 10:18:22 -0500 Subject: [Edu-sig] Textbooks In-Reply-To: <44017A4A.11968.1C4FA5A4@dajoy.openworldlearning.org> References: <44017A4A.11968.1C4FA5A4@dajoy.openworldlearning.org> Message-ID: <4401C6BE.80806@optonline.com> Daniel Ajoy wrote: >On 26 Feb 2006 at 9:04, Arthur wrote: > > > >>>>Really_ can any of those tools be used to program tacitly? >>>>That is without the need to use variables (with the help of >>>>"forks", "hooks" and the like)? >>>> >>>> >>Expressed as someone in touch with esoteric knowledge. >> >>I am guessing it's a Logo thing. >> >>Are you willing to expand? >> >> > >I just wanted to verify the claim that some Python modules >really incorporate J semantics. > > Perhaps the problem is I didn't understand that such a claim was being made. I thought it was a reference to access to extensive array processing functionality. I am happily lost in the discussion beyond that. Function-level, value-level, whatever. I am the last to claim that Python is easy. I do claim that it is not effete. These distinctions, to me, fall into the realm of the effete - and are not where I prefer to spend my time or energy. So I perhaps wasted your time by asking you to expand. Art From kirby.urner at gmail.com Sun Feb 26 17:55:33 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 26 Feb 2006 08:55:33 -0800 Subject: [Edu-sig] Textbooks In-Reply-To: <44017A4A.11968.1C4FA5A4@dajoy.openworldlearning.org> References: <002e01c63add$88ac1440$1702a8c0@BasementDell> <44017A4A.11968.1C4FA5A4@dajoy.openworldlearning.org> Message-ID: > > I just wanted to verify the claim that some Python modules > really incorporate J semantics. numpy incorporates the idea of 'rank' and 'axes' much the way J or other array based languages do i.e. you can shape numbers to have however many axes in some multidimensional box. Then you can do operations on entire boxes, including in ways which combine them with each other. To be array based, and to use a semantics of tacit programming, appear to me as separable capabilities. Numpy doesn't try to be like J in this latter sense. APL isn't quite like J in this sense either, yet is array-based as well. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060226/7375f3cb/attachment.html From dajoy at openworldlearning.org Sun Feb 26 19:16:20 2006 From: dajoy at openworldlearning.org (Daniel Ajoy) Date: Sun, 26 Feb 2006 13:16:20 -0500 Subject: [Edu-sig] Textbooks In-Reply-To: References: <44017A4A.11968.1C4FA5A4@dajoy.openworldlearning.org> Message-ID: <4401AA24.6650.1D0A8E46@dajoy.openworldlearning.org> On 26 Feb 2006 at 8:55, kirby urner wrote: > > > > I just wanted to verify the claim that some Python modules > > really incorporate J semantics. > > > numpy incorporates the idea of 'rank' and 'axes' much the way J or other > array based languages do i.e. you can shape numbers to have however many > axes in some multidimensional box. Then you can do operations on entire > boxes, including in ways which combine them with each other. I got this from a J document: http://jsoftware.com/books/help/learning/07.htm > In J, every verb has what might be called a natural, or > intrinsic, rank for its argument(s). Here are some examples > to illustrate. For the first example, consider: *: 2 4 *: 2 3 4 4 9 16 > Here, the arithmetic function "square" naturally applies to > a single number(a 0-cell). When a rank-1 array (a list) is > supplied as argument, the function is applied separately to > each 0-cell of the argument. In other words, the natural > rank of (monadic) *: is 0. are you saying that functions in numpy also have intrinsic rank for its arguments. Do some numpy functions have 0 rank regardless of the rank of their arguments? > To be array based, and to use a semantics of tacit programming, appear to me > as separable capabilities. Numpy doesn't try to be like J in this latter > sense. APL isn't quite like J in this sense either, yet is array-based as > well. > > Kirby > I agree, but Paul talked about J "semantics and behaviour". J has tacit semantics so I was wondering if numpy also has this feature. You are saying that numpy doesn't use tacit programming semantics. Here is something I got from: http://www.unb.ca/web/transpo/mynet/Iverson_APL.htm > Tacit programming offers several advantages, including the following: > > 1. It is concise. > 2. It allows significant formal manipulation of definitions. > 3. It greatly simplifies the introduction of programming into any topic. Daniel ***************************** OpenWorld Learning http://www.openworldlearning.org From kirby.urner at gmail.com Sun Feb 26 21:26:14 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 26 Feb 2006 12:26:14 -0800 Subject: [Edu-sig] Textbooks In-Reply-To: <4401AA24.6650.1D0A8E46@dajoy.openworldlearning.org> References: <44017A4A.11968.1C4FA5A4@dajoy.openworldlearning.org> <4401AA24.6650.1D0A8E46@dajoy.openworldlearning.org> Message-ID: > > Here is something I got from: > > http://www.unb.ca/web/transpo/mynet/Iverson_APL.htm Thanks Daniel, interesting paper. Teaching resources around J have grown since that 1991 date. Roger Hui's 'idiosyncratic introduction to J' is one of my favorites. The ability to write 'labs' in J, interactive tutorials that work from the shell, is something I'd like to see better developed in Python. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060226/aa8e6b90/attachment.html From christian.mascher at gmx.de Sun Feb 26 21:19:55 2006 From: christian.mascher at gmx.de (Christian Mascher) Date: Sun, 26 Feb 2006 21:19:55 +0100 Subject: [Edu-sig] Programming in the Classroom In-Reply-To: References: Message-ID: <44020D6B.9030204@gmx.de> Hi Kirby, > Given this is 8th grade, I look at it as first exposure or a first pass. > Some stuff will go over their heads, some will stick. It's not necessary > that they be complete masters of everything they see. I think a lot of > education is previewing. What I dislike about most math curricula is how > it's taboo to look ahead and see where we're going. "Looking ahead" is an underdeveloped strain in most curricula, I'm sure. It's partly in the (traditional use) of the word curriculum: a path from a defined outset to a well-defined goal. Given limited time and the pressure of written examinations teachers tend to shorten those interesting but time-consuming overview sessions in favor of more exercises (at least it happens to me often enough, learning _my_ lessons as a teacher, ). Another thing: Only an expert will be able to do a meaningful preview, so it's a lecture which mainly reaches the more interested students (who will appreciate it and learn from listening) but leaves the rest with nothing to _do_. So I don't think it is a taboo that these connections with future themes are understressed. It is just hard to do this right for larger audiences (classes). Still, I think you are right: It is a good thing to (quietly) stick in more than the linear curriculum stuff, even things which will go over their heads. I _am_ doing this here, for instance using the words 'object' or 'method' without "explaining it", only introducing a vocabulary through usage. On the other hand, I want to have a very clear picture in my head of _those_ ideas which will be spelled out step by step and which will be in the tests. > I understand the Sony robot dog has Python bindings but have no details. > Sony should send me a sample. :-D If they send samples, I want one too... ;-)) > I started out talking about types e.g. type(2), type(2.0) and > type('hello'). Thinking in terms of types makes plenty of sense, because > what Python provides is "an extensible type system" i.e. you get the > primitive types out of the box, then you build your own, adding to the types > ( = classes) available. Having looked at smalltalk (squeak) a little in the past year: in this aspect Python is not nearly as uniform (difference between primitive types/user classes) as smalltalk is. I understand that much work is going on to address this issue... > I use a projector, boost IDLE to like 20 point (Comic Sans > these days) and have kids follow along at their own workstations as I > "doodle" i.e. write simple functions and stuff. Other times I hand out > stuff on paper and walk around the room, helping where needed. I often use the projector in exactly the same way (apart from the Comic Sans, will try that out next time) > I continue to think programming is a very motivating way to get into > mathematics. Yes. And Python together with Idle (doodling up functions) is a wonderful tool. > In the pre-college years, I wouldn't be unhappy to see > programming move into the foreground. To make it sound radical and provoke > anxiety, I'd say my position is: drop math completely as traditionally > taught, and teach computer science instead -- but in a different way that > preserves most of the old math content (plus adds a lot of new stuff). I could imagine that, too. But in a centralized school system it doesn't look like anything like this is going to happen here soon. > A > less radical position: offer this as an alternative "track" running in > parallel and let it compete with traditional math. That's actually a > crueler option (means slow death of traditional math vs. a quick transition > to these better methods). In our system pupils are obliged to choose an optional subject (with 3 lesson-hours a 45 min per week) in grade nine and ten. This can be another foreign language or a combination like biology/chemistry or maths/computer. The latter is chosen rather often with different motivations: a) I like playing around with computers ('cause I like computer games) and it sounds less dull and less hard than, say French b) Computers will be important in a later professional life (often the parents' view) c) I like maths and want more of that So some have this on top of their regular maths-class (also 3 lesson-hours per week). Although many have chosen it with motive a) rather than c) I think one can say that all profit from getting exposed to more maths. (Nearly all of them will go on to high-school-level later, where maths (calculus, vectors, probability) is obligatory for everyone.) I can't help but think that 3 weekly lesson-hours (from around 32) for maths is not enough. The German system has always promoted _many_ different subjects at the same time on the grounds that only general education is the goal of the schools. I liked this as a pupil (with many different interests). But as a teacher I feel that today just too many pupils get only very superficial bits of knowledge here and there. Zapping through school subjects like checking through 30 TV channels. Concentrating hard on less subjects could turn out to be more educating. Cheers, Christian From bmiller at luther.edu Mon Feb 27 00:03:51 2006 From: bmiller at luther.edu (Brad Miller) Date: Sun, 26 Feb 2006 17:03:51 -0600 Subject: [Edu-sig] SIGCSE 2006 - Special Session on Teaching with Python Message-ID: <17E2BE5A-D3B1-4EEE-8F8B-472C672BC72D@luther.edu> On Feb 26, 2006, at 8:23 AM, Arthur wrote: > > Brad has been quiet about his publication > > > Problem Solving > with Algorithms > and Data Structures > Using Python > > Thanks for the plug. > http://www.fbeedle.com/053-9.html > > It's certainly of interest to me. > > Of course Alan Kay expressed this week that the teaching of > algorithms and data structures in CS is a problem: > > that: > """nothing exciting about computing today has to do with data > structures and algorithms""" (Kay being paraphrased at > > http://www.windley.com/archives/2006/02/alan_kay_is_com.shtml) > I don't know how accurate the paraphrasing is of what Kay said but the analogy doesn't work very well for me. To quote from the above link: One of Alan?s undergraduate degrees is in molecular biology. He can?t understand it anymore despite having tried to review new developments every few years. That?s not true in computer science. The basics are still mostly the same. If you go to most campuses, there is a single computer science department and the first course in computer science is almost indistinguishable from the first course in 1960. They?re about data structures and algorithms despite the fact that almost nothing exciting about computing today has to do with data structures and algorithms. I can go over and check with my biology colleagues tomorrow, but I'm pretty sure they still teach undergrads about molecules and cells in introductory biology. Sure the latest developments are hard to understand but I doubt they are being taught at the introductory level. Data structures and algorithms may not be exciting (for Kay), but they are as fundamental to computing as cells are to biology. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060226/5808f7e5/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/edu-sig/attachments/20060226/5808f7e5/attachment.pgp From kirby.urner at gmail.com Mon Feb 27 05:23:57 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 26 Feb 2006 20:23:57 -0800 Subject: [Edu-sig] SIGCSE 2006 - Special Session on Teaching with Python In-Reply-To: <17E2BE5A-D3B1-4EEE-8F8B-472C672BC72D@luther.edu> References: <17E2BE5A-D3B1-4EEE-8F8B-472C672BC72D@luther.edu> Message-ID: On 2/26/06, Brad Miller wrote: > > > Data structures and algorithms may not be exciting (for Kay), but they are > as fundamental to computing as cells are to biology. > I think the goal is to get into these quickly and painlessly (Python helps!) but not make 'em the "be all end all" i.e. these are tools, means to an end, but the object is to get work done on some project of immediate import and interest. That's unlikely to be either data structures or algorithms UNLESS you're a CS major or other kind of math nerd. Nothing wrong with that, but we're not prejudiced. We're *happy* to equip students with a lot of CS savvy and send them on their merry way: to be graphic designers, to be cartoonists, to be vampire slayers or what have you. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060226/21107e8f/attachment.html From shannon at centre.edu Mon Feb 27 14:18:12 2006 From: shannon at centre.edu (Christine A. Shannon) Date: Mon, 27 Feb 2006 08:18:12 -0500 Subject: [Edu-sig] textbooks Message-ID: <0D6F3677FF3C0045BBEE54DB65C4EE4D016AD5DC@exchange.centre.edu> Let me just add a couple notes ... I have used Zelle's book for teaching and I think it is great. My students were doing some pretty exciting graphics by week three. One thing I like about it is its size. It has an appropriate amount of material for a single course and is clearly at the introductory level. I also have a copy of Chun's book "Core Programming" and I use it a lot for my own information. I have not used it as the text but have recommended it to many students who are looking for a more comprehensive text. I look forward to the next edition. From ajsiegel at optonline.net Mon Feb 27 15:34:13 2006 From: ajsiegel at optonline.net (Arthur) Date: Mon, 27 Feb 2006 09:34:13 -0500 Subject: [Edu-sig] SIGCSE 2006 - Special Session on Teaching with Python In-Reply-To: References: <17E2BE5A-D3B1-4EEE-8F8B-472C672BC72D@luther.edu> Message-ID: <44030DE5.6070104@optonline.com> kirby urner wrote: > On 2/26/06, *Brad Miller* > wrote: > > > Data structures and algorithms may not be exciting (for Kay), but > they are as fundamental to computing as cells are to biology. > > > > I think the goal is to get into these quickly and painlessly (Python > helps!) but not make 'em the "be all end all" i.e. these are tools, > means to an end, but the object is to get work done on some project of > immediate import and interest. That's unlikely to be either data > structures or algorithms UNLESS you're a CS major or other kind of > math nerd. Nothing wrong with that, but we're not prejudiced. We're > *happy* to equip students with a lot of CS savvy and send them on > their merry way: to be graphic designers, to be cartoonists, to be > vampire slayers or what have you. > Well we are talking about CS courses. So I hear you reluctantly agreeing that there this it is appropriately core curricula. The first 2 words of the title of Brad's book is 'Problem Solving' - implying a "means to an ends". What else? Kay? You admire him. I judge his public persona harshly. He is paraphrases by an admirer: ""nothing exciting about computing today has to do with data structures and algorithms""" I don't think there is *nothing* to that statement. But his way is to overstate things, not state things. I don't think that is appropriate for someone claiming to represent the high order of any branch of science - as he so claims. Art >------------------------------------------------------------------------ > >_______________________________________________ >Edu-sig mailing list >Edu-sig at python.org >http://mail.python.org/mailman/listinfo/edu-sig > > From kirby.urner at gmail.com Mon Feb 27 15:53:09 2006 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 27 Feb 2006 06:53:09 -0800 Subject: [Edu-sig] SIGCSE 2006 - Special Session on Teaching with Python In-Reply-To: <44030DE5.6070104@optonline.com> References: <17E2BE5A-D3B1-4EEE-8F8B-472C672BC72D@luther.edu> <44030DE5.6070104@optonline.com> Message-ID: > > Well we are talking about CS courses. So I hear you reluctantly > agreeing that there this it is appropriately core curricula. The first > 2 words of the title of Brad's book is 'Problem Solving' - implying a > "means to an ends". What else? Not really reluctantly. When learning scuba, it's good to learn about Boyle's law. And why does a bottle of coke fizz when you open it? That's part of an explanation for something too (if you run out of air, rise to the surface slowly, exhaling as you go, and you'll find you keep having enough air -- but god help you if you didn't obey the navy dive tables in the first place). But is the point of scuba to fill your head with this stuff? Not really. The point is to go down there and admire all the pretty fish, to find nemo if you will. I'm into helping students find their private nemos, whatever that means in special case -- which entails learning algorithms and data structures along the way. Re 2 words ("problem solving"): I'm not disagreeing with Brad in any way that I know of. Kay? You admire him. I judge his public persona harshly. He is > paraphrases by an admirer: ""nothing exciting about computing today has to do with data structures > and algorithms""" I do admire Kay, more for his track record of good inventions in CS (e.g. OO/SmallTalk). That's what entitles him to rub people the wrong way with deliberately provocative statements. If he were just some guy off the street who'd read a few CS books, the effect wouldn't be the same. That being said, if *all* he does is rub people the wrong way, then I'd consider him a has been, a once great star who should now step aside and introduce us to whom he considers most promising going forward. Kay's students deserve my attention, perhaps more than Kay himself. Kay reminds me of Ted Nelson. Ted is notoriously a contrarian and likes to use the podium to decry, to broadcast his dismay with this or that dominant paradigm in computing (like, don't get him started on spreadsheets). Personal note: I've never met either Kay or Ted in person, nor even attended a live talk or lecture or presentation by either. I'd like to have that privilege sometime. In the meantime, there's streaming video and journalistic accounts. I don't think there is *nothing* to that statement. But his way is to > overstate things, not state things. I don't think that is appropriate > for someone claiming to represent the high order of any branch of > science - as he so claims. > > Art A root meaning of 'geek' is circus performer of some kind. Sometimes you need front men and women who rile, provoke, stir things up. You may sense in my defense of Kay an implicit defense of my own possible role going forward: as someone who deliberately sparks controversy, by saying things repeatable in cocktail parties, with lots of tittering, with others going home offended to bash their pillows late into the night: take THAT you Kirby guy, and THAT, and THAT.... Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060227/325c7450/attachment.htm From ajsiegel at optonline.net Mon Feb 27 16:34:20 2006 From: ajsiegel at optonline.net (Arthur) Date: Mon, 27 Feb 2006 10:34:20 -0500 Subject: [Edu-sig] SIGCSE 2006 - Special Session on Teaching with Python In-Reply-To: References: <17E2BE5A-D3B1-4EEE-8F8B-472C672BC72D@luther.edu> <44030DE5.6070104@optonline.com> Message-ID: <44031BFC.4000206@optonline.com> kirby urner wrote: > A root meaning of 'geek' is circus performer of some kind. Fun observation. Art From ajsiegel at optonline.net Mon Feb 27 16:48:53 2006 From: ajsiegel at optonline.net (Arthur) Date: Mon, 27 Feb 2006 10:48:53 -0500 Subject: [Edu-sig] SIGCSE 2006 - Special Session on Teaching with Python In-Reply-To: References: <17E2BE5A-D3B1-4EEE-8F8B-472C672BC72D@luther.edu> <44030DE5.6070104@optonline.com> Message-ID: <44031F65.5030901@optonline.com> kirby urner wrote: > A root meaning of 'geek' is circus performer of some kind. Sometimes > you need front men and women who rile, provoke, stir things up. Personally I have a "been there, done that" sense on this score. San Francisco 1969, Leary, Kesey and the Merry Pranksters. Visions, visionaries, and psycho wards. Do as you will. And the truth is, I think I do understand a lot of what drives Kay, which is perhaps why he is such a Moriarty to me. Considering the gap in our technical understandings, I would expect to not understand a word he says. The problem is, I think I understand more of it than I should - too much of it in fact. Too me he is guy who took one too many hits of some kind of digital acid. Whatever. Art From kirby.urner at gmail.com Mon Feb 27 17:32:40 2006 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 27 Feb 2006 08:32:40 -0800 Subject: [Edu-sig] SIGCSE 2006 - Special Session on Teaching with Python In-Reply-To: <44031F65.5030901@optonline.com> References: <17E2BE5A-D3B1-4EEE-8F8B-472C672BC72D@luther.edu> <44030DE5.6070104@optonline.com> <44031F65.5030901@optonline.com> Message-ID: > Do as you will. And the truth is, I think I do understand a lot of what > drives Kay, which is perhaps why he is such a Moriarty to me. > Considering the gap in our technical understandings, I would expect to > not understand a word he says. The problem is, I think I understand > more of it than I should - too much of it in fact. Too me he is guy who > took one too many hits of some kind of digital acid. > > Whatever. > > > Art > > I'm not insensitive to your intuitions on that score. I'm leaving the door open to reaching a more negative assessment in good time. For now, I'm open minded and eager for entertainment. Of the young who made it to middle age and beyond, I've so far found many of the acid heads to be worthy candidates for my attention (maybe you *shouldn't* think of running for president, if you've never tried LSD). The grownups who rigorously eschewed anything so depraved: their reward is in heaven I suppose. Some of them are even top geeks. Bottom line: I welcome diversity, and since Kay is one voice among many, I'm not especially concerned if he's off on some "wrong track" in some way (maybe he'll say so himself at some point -- we all zig zag through life, some with greater amplitude than others). I'm a liberal after all: people should have the freedom to make stupid mistakes, as long as the real costs are mostly to themselves (not the case with the neocons). Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060227/a2e0e6ae/attachment.html From pchase at sulross.edu Mon Feb 27 17:52:02 2006 From: pchase at sulross.edu (Peter Chase) Date: Mon, 27 Feb 2006 10:52:02 -0600 Subject: [Edu-sig] Textbooks Message-ID: <44032E32.7000900@sulross.edu> Thanks to all for the discussion. I think I'm going with Zelle, with some Tk handouts for the graphics. Regards to all, Peter Chase Sul Ross State University From kirby.urner at gmail.com Mon Feb 27 20:02:23 2006 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 27 Feb 2006 11:02:23 -0800 Subject: [Edu-sig] Textbooks In-Reply-To: <44032E32.7000900@sulross.edu> References: <44032E32.7000900@sulross.edu> Message-ID: Good choice. I also like courses where no text book is required (in the sense of buying some thick heavy thing made of wood pulp). Publishers are moving to electronic formats. True, reading on a screen is sometimes a drag. On the other hand, with 7 billion teachers and students, it's asking too much to always have hardcopy. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060227/0b9b9912/attachment.htm From vceder at canterburyschool.org Mon Feb 27 20:31:30 2006 From: vceder at canterburyschool.org (Vern Ceder) Date: Mon, 27 Feb 2006 14:31:30 -0500 Subject: [Edu-sig] Any suggestions about turlte.py Message-ID: <44035392.6020402@canterburyschool.org> Hello everyone, As a consequence of my complaining about it in my PyCon talk, I have been invited to submit some patches for turtle.py. To my mind, turtle.py should be something that one could actually use for some very simple "programming with graphics" lessons, with NO tweaking or additional software. So I think the following would be handy: 1. equally usable with either "import * from turtle" or "import turtle" imports 2. should open with a window covering at least half the screen (the current default is too small to be useful) 3. should offer some simple configuration choices for things like initial size and shape, but mostly rely on reasonable defaults 4. should offer a class wrapper so that that one could easily instantiate different turtles for a first experience with objects. 5. some minor tweaks to make it better behaved when run from IDLE Does anyone have any feedback on these ideas or any other suggestions about how turtle.py might be improved without being fundamentally changed? Note: this is about turtle.py only, for all its deficiencies. Any suggestions to try another library, system, or language will be cheerfully, but resolutely, ignored. ;) Cheers, Vern Ceder -- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder at canterburyschool.org; 260-436-0746; FAX: 260-436-5137 From vceder at canterburyschool.org Tue Feb 28 00:22:33 2006 From: vceder at canterburyschool.org (Vern Ceder) Date: Mon, 27 Feb 2006 18:22:33 -0500 Subject: [Edu-sig] Any suggestions about turtle.py In-Reply-To: References: <44035392.6020402@canterburyschool.org> Message-ID: <440389B9.5020901@canterburyschool.org> Brad, I agree on both counts. In fact my current implementation does the first already and I was just thinking today about doing the second. Thanks for the suggestions - I'm glad to hear I'm on the right track. Vern Brad Miller wrote: > Vern, > > Thanks for taking this on. I have my students implement a turtle class > as a programming assignment, but I also like to use turtle graphics for > some fun recursion problems. > > A couple of suggestions: > 1. Make Turtle an alias for Pen. I always find it weird that we are > importing the Turtle module but instantiating a Pen. > > 2. Have an option to make the turtle go fast. Its too slow for complex > stuff as it is. > > Brad > > > On Feb 27, 2006, at 1:31 PM, Vern Ceder wrote: > >> Hello everyone, >> >> As a consequence of my complaining about it in my PyCon talk, I have >> been invited to submit some patches for turtle.py. To my mind, turtle.py >> should be something that one could actually use for some very simple >> "programming with graphics" lessons, with NO tweaking or additional >> software. >> >> So I think the following would be handy: >> >> 1. equally usable with either "import * from turtle" or "import turtle" >> imports >> 2. should open with a window covering at least half the screen (the >> current default is too small to be useful) >> 3. should offer some simple configuration choices for things like >> initial size and shape, but mostly rely on reasonable defaults >> 4. should offer a class wrapper so that that one could easily >> instantiate different turtles for a first experience with objects. >> 5. some minor tweaks to make it better behaved when run from IDLE >> >> Does anyone have any feedback on these ideas or any other suggestions >> about how turtle.py might be improved without being fundamentally >> changed? >> >> Note: this is about turtle.py only, for all its deficiencies. Any >> suggestions to try another library, system, or language will be >> cheerfully, but resolutely, ignored. ;) >> >> Cheers, >> Vern Ceder >> >> >> -- >> This time for sure! >> -Bullwinkle J. Moose >> ----------------------------- >> Vern Ceder, Director of Technology >> Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 >> vceder at canterburyschool.org; 260-436-0746; FAX: 260-436-5137 >> _______________________________________________ >> Edu-sig mailing list >> Edu-sig at python.org >> http://mail.python.org/mailman/listinfo/edu-sig -- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder at canterburyschool.org; 260-436-0746; FAX: 260-436-5137 From andre.roberge at gmail.com Tue Feb 28 03:22:26 2006 From: andre.roberge at gmail.com (Andre Roberge) Date: Mon, 27 Feb 2006 22:22:26 -0400 Subject: [Edu-sig] Any suggestions about turlte.py In-Reply-To: <44035392.6020402@canterburyschool.org> References: <44035392.6020402@canterburyschool.org> Message-ID: <7528bcdd0602271822s3a80e007p44a8c320da5435c6@mail.gmail.com> On 2/27/06, Vern Ceder wrote: > Hello everyone, > > As a consequence of my complaining about it in my PyCon talk, I have > been invited to submit some patches for turtle.py. To my mind, turtle.py > should be something that one could actually use for some very simple > "programming with graphics" lessons, with NO tweaking or additional > software. > Good idea! > So I think the following would be handy: > [snip] > 4. should offer a class wrapper so that that one could easily > instantiate different turtles for a first experience with objects. Definitely! > 5. some minor tweaks to make it better behaved when run from IDLE > > Does anyone have any feedback on these ideas or any other suggestions > about how turtle.py might be improved without being fundamentally changed? Yes, but .... (see below) > > Note: this is about turtle.py only, for all its deficiencies. Any > suggestions to try another library, system, or language will be > cheerfully, but resolutely, ignored. ;) > It would be nice if turtle.py could have methods that would be independent of Tkinter. However, I suspect that this falls under the category of "fundamentally changing it". have been thinking of including a version of turtle graphics inside rur-ple (a Python Learning Environment I designed); however, rur-ple is based on wxPython. So, I guess, I will have to write my own... One thing that, to my mind, is even more important than changing turtle.py is to write "lessons" on how to use it. If, at the very least, you include some example programs, I think it would be greatly appreciated. Best of luck! Andr? > Cheers, > Vern Ceder > From radenski at chapman.edu Tue Feb 28 05:57:47 2006 From: radenski at chapman.edu (Radenski, Atanas) Date: Mon, 27 Feb 2006 20:57:47 -0800 Subject: [Edu-sig] Any suggestions about turlte.py Message-ID: Hi, Thank you for taking care of the turtle.py module. Here are tow suggestions. [1] I would suggest a correction of a bug in the fill function of turtle.py. The statement: # self._canvas.lower(item) should be removed. As it is now, it lowers polygons when filled. This causes inconsistent behavior because nothing else is lowered. Here is a suggested the statement in context: def fill(self, flag): if self._filling: path = tuple(self._path) smooth = self._filling < 0 if len(path) > 2: item = self._canvas._create('polygon', path, {'fill': self._color, 'smooth': smooth}) self._items.append(item) # Should be removed, because # nothing else is lowered but filled polygons: # self._canvas.lower(item) if self._tofill: for item in self._tofill: self._canvas.itemconfigure(item, fill=self._color) self._items.append(item) self._path = [] self._tofill = [] self._filling = flag if flag: self._path.append(self._position) self.forward(0) [2] A nuisance with this otherwise quite useful module is its behavior in Windows systems: It tends to *stop responding*. This happens when the canvas is covered by other graphics for a while, especially in cases when execution is triggered form the interactive prompt. It would be great if this problem can be fixed (although I am not sure what can be done about it.) Atanas Atanas Radenski mailto:radenski at chapman.edu http://www.chapman.edu/~radenski/ I find television very educating. Every time somebody turns on the set, I go into the other room and read a book - Groucho Marx > -----Original Message----- > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > Behalf Of Vern Ceder > Sent: Monday, February 27, 2006 11:32 AM > To: Edu-sig at python.org > Subject: [Edu-sig] Any suggestions about turlte.py > > Hello everyone, > > As a consequence of my complaining about it in my PyCon talk, I have > been invited to submit some patches for turtle.py. To my mind, turtle.py > should be something that one could actually use for some very simple > "programming with graphics" lessons, with NO tweaking or additional > software. > > So I think the following would be handy: > > 1. equally usable with either "import * from turtle" or "import turtle" > imports > 2. should open with a window covering at least half the screen (the > current default is too small to be useful) > 3. should offer some simple configuration choices for things like > initial size and shape, but mostly rely on reasonable defaults > 4. should offer a class wrapper so that that one could easily > instantiate different turtles for a first experience with objects. > 5. some minor tweaks to make it better behaved when run from IDLE > > Does anyone have any feedback on these ideas or any other suggestions > about how turtle.py might be improved without being fundamentally changed? > > Note: this is about turtle.py only, for all its deficiencies. Any > suggestions to try another library, system, or language will be > cheerfully, but resolutely, ignored. ;) > > Cheers, > Vern Ceder > > > -- > This time for sure! > -Bullwinkle J. Moose > ----------------------------- > Vern Ceder, Director of Technology > Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 > vceder at canterburyschool.org; 260-436-0746; FAX: 260-436-5137 > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig From vceder at canterburyschool.org Tue Feb 28 14:49:03 2006 From: vceder at canterburyschool.org (Vern Ceder) Date: Tue, 28 Feb 2006 08:49:03 -0500 Subject: [Edu-sig] Any suggestions about turlte.py In-Reply-To: References: Message-ID: <440454CF.1050604@canterburyschool.org> Atanas, Thanks for the input - I wasn't aware of the first problem you mention. I'm not sure about the secnond issue - do you mean that a turtle program that is *running* will hang if covered by other graphics? Or that a window with an already completed drawing/program will become unrresponsive? I've seen the second behavior, but not the first. Thanks, Vern Radenski, Atanas wrote: > Hi, > > Thank you for taking care of the turtle.py module. Here are tow > suggestions. > > [1] I would suggest a correction of a bug in the fill function of > turtle.py. The statement: > > # self._canvas.lower(item) > > should be removed. As it is now, it lowers polygons when filled. This > causes inconsistent behavior because nothing else is lowered. Here is a > suggested the statement in context: > > > def fill(self, flag): > if self._filling: > path = tuple(self._path) > smooth = self._filling < 0 > if len(path) > 2: > item = self._canvas._create('polygon', path, > {'fill': self._color, > 'smooth': smooth}) > self._items.append(item) > > # Should be removed, because > # nothing else is lowered but filled polygons: > > # self._canvas.lower(item) > > if self._tofill: > for item in self._tofill: > self._canvas.itemconfigure(item, > fill=self._color) > self._items.append(item) > self._path = [] > self._tofill = [] > self._filling = flag > if flag: > self._path.append(self._position) > self.forward(0) > > [2] A nuisance with this otherwise quite useful module is its behavior > in Windows systems: It tends to *stop responding*. This happens when the > canvas is covered by other graphics for a while, especially in cases > when execution is triggered form the interactive prompt. It would be > great if this problem can be fixed (although I am not sure what can be > done about it.) > > Atanas > > Atanas Radenski > mailto:radenski at chapman.edu http://www.chapman.edu/~radenski/ > > I find television very educating. Every time somebody turns on the set, > I go into the other room and read a book - Groucho Marx > > > >>-----Original Message----- >>From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] > > On > >>Behalf Of Vern Ceder >>Sent: Monday, February 27, 2006 11:32 AM >>To: Edu-sig at python.org >>Subject: [Edu-sig] Any suggestions about turlte.py >> >>Hello everyone, >> >>As a consequence of my complaining about it in my PyCon talk, I have >>been invited to submit some patches for turtle.py. To my mind, > > turtle.py > >>should be something that one could actually use for some very simple >>"programming with graphics" lessons, with NO tweaking or additional >>software. >> >>So I think the following would be handy: >> >>1. equally usable with either "import * from turtle" or "import > > turtle" > >>imports >>2. should open with a window covering at least half the screen (the >>current default is too small to be useful) >>3. should offer some simple configuration choices for things like >>initial size and shape, but mostly rely on reasonable defaults >>4. should offer a class wrapper so that that one could easily >>instantiate different turtles for a first experience with objects. >>5. some minor tweaks to make it better behaved when run from IDLE >> >>Does anyone have any feedback on these ideas or any other suggestions >>about how turtle.py might be improved without being fundamentally > > changed? > >>Note: this is about turtle.py only, for all its deficiencies. Any >>suggestions to try another library, system, or language will be >>cheerfully, but resolutely, ignored. ;) >> >>Cheers, >>Vern Ceder >> >> >>-- >>This time for sure! >> -Bullwinkle J. Moose >>----------------------------- >>Vern Ceder, Director of Technology >>Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 >>vceder at canterburyschool.org; 260-436-0746; FAX: 260-436-5137 >>_______________________________________________ >>Edu-sig mailing list >>Edu-sig at python.org >>http://mail.python.org/mailman/listinfo/edu-sig -- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder at canterburyschool.org; 260-436-0746; FAX: 260-436-5137