Mailman 3 February 2007 - Edu-sig

Interface of Tomorrow
by kirby urner Feb. 24, 2007

Feb. 24, 2007

More interface of tomorrow eye candy: http://www.fastcompany.com/video/general/perceptivepixel.html Note "Python" commercial. Kirby

1 0

Partial Sums using List Comprehensions
by kirby urner Feb. 24, 2007

Feb. 24, 2007

I've appending a posting (of mine) from another group, because of the Python syntax it contains: a list comprehension giving partial sums. So often in math, we want to do that, or in simple grocery store arithmetic, or statistics, where what interests is a list of cumulative sums, running totals. Now an interesting way to date yourself is if you have a "cringe reflex" when you see: >>> halfoctas = [sum(manylayers[0:x]) for x in range(1,21)] when you realize the *same totals* are starting over for every member of the list, i.e. we're not capitalizing on having already added 18 numbers, when going to the 19th -- we start all over. What a waste of perfectly good ADDs, right? If you're old school assembler with limited RAM (8K sound like a lot?) your reflex will be to cache those totals and run screaming from any VHLL (very high level language) that doesn't mirror your sense of memory/clock economy. But in Python, is in other VHLLs such as J, it's economy of syntax, and therefore conceptual economy in the programmer's own brain, that we're seeking, less so a perfectly optimized fleet of electrons through the CPU's adder. We waste "clock cycles" with wild abandon, because most computers just sit there wasting clock cycles anyway -- that's what they have, in magnificent abundance (*way* too much time on their hands). Programmers, on the other hand, have busy lives and need to get on with learning their sums. List comprehension syntax is easy to master and any decent Python course gets into it quickly (within the first hour, during an overview pass?). And that's the tradeoff in electronics: pushing the busy work onto the machines, freeing up our own minds for more interesting challenges. But you still need old school type thinkers, for when memory really does get to be tight (which it still does, in many knowledge domains, e.g. climatology). Also you could just go: >>> def halfoctas(n): return [sum([x*x for x in range(1, n+1)][0:i]) for i in range(1, n+1)] >>> halfoctas(10) [1, 5, 14, 30, 55, 91, 140, 204, 285, 385] >>> halfoctas(20) [1, 5, 14, 30, 55, 91, 140, 204, 285, 385, 506, 650, 819, 1015, 1240, 1496, 1785, 2109, 2470, 2870] but that's a lot less transparent I think. Or write it as a generator -- don't have to specify n in that case (just invoke .next() without limit). Kirby ========================= Re: School Boycott --- In synergeo(a)yahoogroups.com, "Alan Michelson" <amichelson2002@...> wrote: > As you can see, there hasn't been as much discussion about the > half-coupler as there was about the octant (they both have the same > volume — one-sixth of the cube!) > Yeah, you're doing good work. And every school child gets at least a tactile and/or visual gander at the Egyptian variety, especially if getting brainwashed with Biblical stories, in which Pharoh is bound to come in (and go out). So "half octahedron" is no unfamiliar concept. Nor should be the ball packing corresponding thereto, beginning with a plane of XY spheres, surmounted by another "down in the valleys", and another, and so on, tapering right up to a tippy top apex ball -- maybe it makes more sense to begin from there, excavating as you grow the base. We're talking about the sum of consecutive squares of course, and so in Python: >>> def layers(n): return n**2 >>> manylayers = [layers(n) for n in range(1, 21)] >>> halfoctas = [sum(manylayers[0:i]) for i in range(1,21)] >>> halfoctas [1, 5, 14, 30, 55, 91, 140, 204, 285, 385, 506, 650, 819, 1015, 1240, 1496, 1785, 2109, 2470, 2870] Then we cut and paste the first few into the Encyclopedia of Integer Sequences and voila: http://www.research.att.com/~njas/sequences/A000330 > > I mean, why aren't we teaching this stuff? There's no coherent > > opposition, just mindless inertia. A boycott might help us focus. ... Kirby

1 0

Re: [Edu-sig] OLPC: first thoughts on the first keynote at Pycon
by Laura Creighton Feb. 24, 2007

Feb. 24, 2007

In a message of Fri, 23 Feb 2007 23:20:10 PST, Andreas Raab writes: >Paul D. Fernhout wrote: >> This "edit and continue" support is much more fine grained and >> easier to use than reloading Python modules, even with the variants I a >nd >> others have created. > >Where can I find out more about these variants and what they do? We are >currently trying to enable a workflow that centers around a life >environment and these issues become important for us. Are there any >other life environments (besides Patapata which I have looked at) that >are worth studying? > >Cheers, > - Andreas PyPy made a release last week. http://codespeak.net/pypy/dist/pypy/doc/news.html release 1.0 (coming next month) may be of even more interest to you. Remember that this is bleeding edge computer science research, not something we suggest you use in production right away. in particular greenlets http://codespeak.net/py/dist/greenlet.html may be of interest to you. We don't have an 'edit and continue' interface to pypy yet, but that is exactly what we are doing internally, so by my reckoning, at any rate, it would not be hard to add. EU project winds up in March. No cool new ideas are going to go in until April, because we are going to have the damndest time getting all we promised done on time ... PyPy has its own mailing list http://codespeak.net/mailman/listinfo/pypy-dev and pypy developers hang out on the irc channel #pypy on freenode. That is a better place to discuss pypy than here. Laura Creighton

1 0

PEP accepted
by Andre Roberge Feb. 23, 2007

Feb. 23, 2007

Simple input built-in in Python 3000 has been accepted. Details are here: http://www.python.org/dev/peps/pep-3111/ The next step is the actual implementation which I have foolishly volunteered to do. André

2 1

edu-dinner
by Michael Tobis Feb. 21, 2007

Feb. 21, 2007

I just talked to the Marriott; they are perfectly OK doing room service into the Preston Trail II room. One of us staying at the hotel can collect cash from all interested and put it on a credit card. I am willing to do this. So I suggest we combine dinner and our meeting in the Preston Room Saturday Night They are also sending me a banquet menu and I'll look into it, but I think it would be easier with room service for everyone to get what they want. Any objections? If not please consider this a plan. See you Saturday 7 PM! Michael Tobis

6 10

"Python First" summer workshop
by Atanas Radenski Feb. 21, 2007

Feb. 21, 2007

A summer workshop "Python First: A Lab-Based Digital Introduction to Computer Science" will be held at Chapman University, Orange, California, June 18-21, 2007. Registration is now open. For more information and to register visit: http://www.chapman.edu/wcls/MathCS/sWorkshop/Python/default.asp Respectfully, Atanas Radenski mailto:radenski@studypack.com http://studypack.com mailto:radenski@chapman.edu http://www1.chapman.edu/~radenski

1 0

Pycon talk: advice?
by Andre Roberge Feb. 20, 2007

Feb. 20, 2007

Hi everyone, I have a question for you... I've just finished going through the first draft of my Pycon talk "out loud" to ensure that I didn't talk for too long and find out that I could easily stretch it to one hour... while I only intend to talk for 25 minutes at the most, making sure there is time for questions. Here's a "revised" outline of what my talk could include 1. Defining/demo-ing what is meant by an interactive tutorial (i.e. executing Python code from Firefox). 2. Why VLAM? (Very Little Added Markup) - with simple examples 3. Features of the embedded Python interpreter * including support for input()/raw_input() :-) 4. The new editor. 5. Built-in graphics support (drawings and plots) 6. Doctests as a learning tool. 7. Launching an external applications (2 quick examples) 8. Demo of the new "crunchyfier" - point and click to add VLAM I also need to demonstrate Johannes' latest work which simplify the graphics support, extend input/raw_input, simplifies communication between the browser and the Python backend and is generally a much better approach. Another topic I probably need to slip in there is the issue of security. A feature I will most likely not cover at all is the user customization (style [css] and language [i.e. English and French at the moment). Now comes the question :-) Does anyone have any suggestion/preference as to which topic(s) I should spend more time on? André

1 0

Re: [Edu-sig] understanding recursion
by Michel Paul Feb. 20, 2007

Feb. 20, 2007

>why do you say "can't use" we can can just *redefine* Oh, definitely. I agree. We certainly can and SHOULD have students learn to redefine what we mean by various operators. In saying "can't use" I don't mean "can't EVER use". : ) I just mean within the scope of this exercise. Again, I initially meant this to be an exercise PRIOR to studying any particular language. I think it's a good kind of math/CS exercise to have to analyze what we mean by simple integer operations that we normally take for granted, and this analysis naturally introduces recursion. And I think it nicely blends in with ultimately redefining these operations for other data structures. >But in Python, we have been, given looping constructs Right. Again, I just mean within the scope of the exercise. Along this line, here's an interesting thing regarding GCF - suppose we have so far ONLY defined what we mean by greaterThan, lessThan, and difference. With ONLY those definitions in place, we can define GCF: gcf(a, b): if a = b ---> a if greaterThan(a, b) ---> gcf(difference(a, b), b) if lessThan(a, b) ---> gcf(a, difference(b, a)) We can define gcf prior to defining division or mod. I think that's kind of interesting. But certainly, outside the scope of this set of exercises, it makes sense to use looping constructs, and Guido's gcf is pure beauty. -----Original Message----- From: kirby urner [mailto:kirby.urner@gmail.com] Sent: Mon 02/19/07 10:05 PM To: Michel Paul Cc: edu-sig(a)python.org; Jane Wortman; Lee Morris Subject: Re: [Edu-sig] understanding recursion > The important thing in these exercises is that we can't use our typical arithmetic > operators of +, -, *, /, as we are DEFINING them! I think a Pythoneer will twistedly think at this point is: why do you say "can't use" we can can just *redefine* __add__, __sub__, other __ribs__, to suit, get whatever meanings for those typical arithmetic operators you like. > And in the act of defining them, we naturally have to think recursively, as we > haven't been given any looping constructs. But in Python, we have been, given looping constructs (it's a VHLL ya know, not an assembly language like Scheme and/or MMIX). Kirby

2 1

Re: [Edu-sig] understanding recursion
by Michel Paul Feb. 20, 2007

Feb. 20, 2007

I'd like to share an idea that occurred to me awhile back. It's a problem one can pose prior to discussing any specific programming language. Given two black-box functions prev(n) and next(n), along with conditional reasoning and the typical math comparison operators, define arithmetic. So for example, visualizing the translation of a segment [a, b] on a number line, we could define difference(a, b) in this way: difference(a, b): if b = 0 ---> a if b > 0 ---> difference(prev(a), prev(b)) if b < 0 ---> difference(next(a), next(b)) Or, we could make the base case: if a = b ---> 0 (if a and b are equal, then there is no difference) and get a slightly different definition. Understand that this was a pseudo-code style I was using prior to having seen Python. Imagine my joy when I then found Python! The important thing in these exercises is that we can't use our typical arithmetic operators of +, -, *, /, as we are DEFINING them! And in the act of defining them, we naturally have to think recursively, as we haven't been given any looping constructs. I must say - it was Scheme that initially inspired me to think like this. (That, and the fact that I have frequently found myself without a functional lab at the beginning of the school year! Seriously, it has been unbelievable.) I think this is a good kind of exercise for both CS and math students. And this is what made me fall in love with Python right away - the fact that I could do this kind of stuff: zero = [] def next(n): return [n] def prev(n): return n[0] one = next(zero) two = next(one) four = next(next(two)) three = prev(four) In Python, this stuff will RUN! I was ecstatic for days because of this. Of course, given this implementation we are restricted to the Naturals - but that's OK. The Naturals is a good place to start! We then have to think about how to implement other kinds of number. I think that constructing this kind of understanding is something we would want kids to do. There could be a lot of history integrated there. We can also extend the exercise to define > and <. So, given only prev(n), next(n), equality, and conditional reasoning, define arithmetic! I realize this might seem really remote and abstract for most high school students, but I actually think it's something they COULD and SHOULD grapple with. Exercises like this contain lots of good math AND CS simultaneously. I mean, consider a high school student who could articulate FROM SCRATCH their understanding of the various kinds of number in a simple computational syntax. Seems to me that would meet all kinds of concerns regarding standards. Sincerely, Michel Paul ================================================== "Shall I tell you what it is to know? To say you know when you know, and to say you do not when you do not, that is knowledge." - Confucius ==================================================

2 1

Problem with mouse clicks
by Peter Drake Feb. 19, 2007

Feb. 19, 2007

I just had my students write this program in my CS0 class: from graphics import * graphics() while 0 < 1: click = mouse() x = click[0] y = click[1] oval([x-10, y-10], [x+10, y+10]) (Note that graphics is Zelle's version with my procedural wrappers appended, http://www.lclark.edu/~drake/courses/cs0/graphics.py) Usually (but, frustratingly, not every run), the mouse clicks are offset, so the circles appear some distance above and to the left of where they should. Has anyone else run into this? Is there an explanation or workaround? Peter Drake http://www.lclark.edu/~drake/

1 0