Mailman 3 March 2005 - Edu-sig

Re: Networking in DOSEMU
by Lee Harr July 24, 2005

July 24, 2005

>I want to ask something not concerning python. Here, you give yourself an excellent hint that this is the wrong place to ask this question. >actualy i want to know how can i connect to my novel server thru dosemu. Here, I am wondering if you mean Novell. Searching is facilitated by correct spelling of the thing you seek. Let's take a look... http://www.google.com/search?q=dosemu+mailing+list Strangely, not the first hit on google, but the 3rd hit looks pretty good: http://dosemu.sourceforge.net/mailinglist.html good luck! _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/

4 10

RE: [Edu-sig] Re: More on intro to Python (today's 3 hr training)
by Kirby Urner April 1, 2005

April 1, 2005

> So, the "smart" algorithm should be (untested here.... left as an > exercise :-) > > sum = ( f(a) + f(b) ) / 2. > x = a + h > B = b-h/2 # takes care of round-off error at end point. > > .while x <= B: > . sum += f(x) > . x += h > . > . sum *= h > . return sum > ======== > > André Your comments and Henrik's are cogent and valuable and provide definite improvements. Plus the discussion is conceptual i.e. we're dealing with nuts and bolts problems that the calculus deals with. So my general question is, as usual: wouldn't this be an interesting and intelligent way to teach math? You get concepts, and you get programming skills, and you start to think about analyzing and fine tuning algorithms. Plus you grow to appreciate the power of the calculus, which gives us close formed expressions so often -- a way to avoid fast for-loops entirely. Kirby

3 3

Re: RE: [Edu-sig] Re: Best approach to teaching OOP and graphics
by urnerk＠qwest.net April 1, 2005

April 1, 2005

>That's where I am being confused. > >Graphical programming has nothing necessarily to do with a GUI, so >I am confused why we are discussing them in any way together. The key word is "necessarily" and I completely agree. I was mentioning several kinds of programming. GUI programming *is* graphical, in the sense that "G" stands for "graphical". It so happens the GUI stuff is almost always OO (I talked about that in terms of the Nokia 60 cell phone). I have very limited experience with OpenGL (or PyOpenGL), but yes, the VPython stuff is obviously OO. POV-Ray isn't so obviously, if at all -- but if we write a Python layer on top of POV-Ray (what I like to do), then it makes sense to use OO. > I don't see GUI programming as a necessarily appropriate > environment to introudce OOP. It's certainly the way a lot of people come into contact with it. But you may be right. I think it's possibly useful as an introductory environment, but it could lead to that problem of not understanding OO concepts generically enough, and getting confused about the difference between GUI programming and OO. That seemed to be a confusion we were worried about in this thread. > But using the metaphor of geometric objects already *is* the > canonical way of introducing OOP. Yes, could be. Another canonical metaphor is animals. The mammal class is subclassed into dogs, cats, humans and so on. I've also seen telephones subclassed as fax-phones, cell phones etc. (all types of phone). > What VPython, for example, allows is pursuit of the canonical > methodology, but cutting directly to an actual implementation, > rather than working on "as-if" basis. We wee the triangle, derived > from our more general geometric object, rather than (or in addition to) > only seeing a prompt message saying "I am now a triangle". > > Hard for me to see anything but upside in this approach. I'd have to see you proposal fleshed out in more detail. What is the triangle a subclass or superclass of? What are its methods and properties? And what is the VPython framework you'd use to introduce OO? Kirby -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ .

6 11

More on intro to Python (today's 3 hr training)
by Kirby Urner March 31, 2005

March 31, 2005

So below is a module I tossed up on the big screen in my hotel conference room (the typical scene: breakout rooms, a vendor/exhibitor space, big lunch room with an interesting talk (and it *was* very interesting)). This was probably the most advanced topic I dealt with (decorators) and I didn't even show 'em their archetypal context, inside of classes (talked about it though). But given these were GIS folks (very visual), I thought this'd be a good excuse to at least throw out a couple plots (graphs of curves and their derivatives). I introduced decorators under the heading of "functions as top level" i.e. passable as arguments, valid as returned objects, allowing factory functions returning closures and blah blah. The itertools import shouldn't be there. I was experimenting with giving matplotlib generators to munch on, but that failed -- I think it wants to see the whole list first, to figure out scaling. Makes sense. I quick showed my hypertoon (under a minute I think), just to show off what add-ons can do (i.e. VPython). Didn't even get to my example of using ADO to add a record to the Products table in Northwind.mdb. Pity. And for some reason my feeble pre-talk attempt to open a Word document using COM crashed Python after opening said Greeting.doc (a problem with wrapping Word Objects 11.0 in Office 2003, or is it just me?). Speaking of hypertoons, Scott sent me a cool refactoring of said module using decorators. I just got it this AM and haven't gotten around to actually studying the revisions, but I plan to. That'd really break 2.3 compatibility, but I have reason to think 2.3 isn't showing some of the cartoons properly anyway. BTW, 2.4 experimental VPython failed to work with gcurve in my experiments -- I was going to use its plotting facility in the demo, but ended up switching to matplotlib for this very reason. Could be that I just didn't know how to use it right? If anyone has a working gcurve plot in VPython 2.4 experimental, I'd like to test it on my setup. Kirby ============================= # Decorators (new in 2.4) from itertools import izip import math from pylab import arange, plot, xlabel, ylabel, title, grid, show def adderfactory(n): """ Return an adder function that adds n to its argument """ def adder(x): return x + n return adder def test0(): add2 = adderfactory(2) add10 = adderfactory(10) print "add2(17) : %s" % add2(17) print "add10(17): %s" % add10(17) def derivative(f): """ Factory function: accepts a function, returns a closure """ def df(x, h=1e-8): return (f(x + h) - f(x))/h return df def g(x): return x*x def curve(x): return pow(x, 3) @derivative # same as dg = derivative(dg) def dg(x): return x*x @derivative # same as dcurve = derivative(dcurve) def dcurve(x): return x*x*x @derivative def dcos(x): return math.cos(x) def test1(a=-5,b=6): print "g(x) : %s" % [g(x) for x in range(a,b)] print "dg(x): %s" % [round(dg(x),2) for x in range(a,b)] print "="*30 print "curve(x) : %s" % [curve(x) for x in range(a,b)] print "dcurve(x): %s" % [round(dcurve(x),2) for x in range(a,b)] def test2(): """ Use matplotlib to plot graph """ x = arange(-10,10,0.1) y = [curve(i) for i in x] dy = [dcurve(i) for i in x] plot(x, y, linewidth=1.0) plot(x, dy, linewidth=1.0) xlabel('x') ylabel('y') title('Graph of x**3 & 3*x**2') grid(True) show() def test3(): """ Use matplotlib to plot graph """ x = arange(-10,10,0.1) y = [dcos(i) for i in x] dy = [math.cos(i) for i in x] plot(x, y, linewidth=1.0) plot(x, dy, linewidth=1.0) xlabel('x') ylabel('y') title('Graph of cos & dcos(x)') grid(True) show()

5 10

Re: RE: [Edu-sig] RE: Integration correction
by ajsiegel＠optonline.net March 31, 2005

March 31, 2005

From: Kirby Urner <urnerk(a)qwest.net> > @simpson > def g(x): return x*x > > >>> g(0, 3) > 9.0000000000000036 My resistance to decorators is not unrelated to the fact that I don't seem capable of getting my mind around them. I do find it quite disconcerting that the arguments "g" is expecting cannot be ascertained in the normal manner - that is by looking at "g" for the arguments it is expecting. Ouch, ouch, ouch. I think decorators are a little *too* cool - though do accept they have there real world uses. I am not sure why these are them. And certainly my issue is unrelated to the particular choice of syntax Guido made - which I happen to like, but probably for the wrong reasons. I *particularly* dislike decorators in the context of teaching/learning. Something that is relatively straight forward as executable pseudo-code becomes fancy/schmancy programming. I would probably introduce them first a step or two before metaclasses - in the Python for gurus class. Art

4 5

RE: RE: [Edu-sig] RE: Integration correction
by Arthur March 30, 2005

March 30, 2005

> -----Original Message----- > From: David Handy [mailto:david@handysoftware.com] > > I'll try and answer that one. I won't repeat your post, since it is long - but will say that I understand its sentiments and largely agree with them. Those of us clever enough to have gotten on the bandwagon from 1.5.2 or before have been treated to an exciting and stimulating ride. And I am grateful for it, and do try to express that from time to time. Whether anyone joining the party at 2.4 will be enjoying a similar kind of ride remains to be seen. And the extent to which the price of admission has gone up some since 1.5.2 is - I guess - another matter of conjecture/opinion. Will the mechanics of decorators seem at some point trivial to me. I suspect so. Will I be better off having gotten there than I would if I never had needed to jump the hurdle. No question. But - on the other side - among the frustrations/concerns is the fact that I may feel I really have little guidance to contribute to anyone starting out in Python2.4. It being a very different place to start from then the place where I had started. The fact, for example, that old style classes co-exist with new is just one of many mysteries that confront the initiate at this point. Its like talking about "dialing" a telephone number. I have to wonder what someone my son's age must think about why such a silly phrase might have taken hold. Art

1 0

Re: RE: [Edu-sig] RE: Integration correction
by David Handy March 30, 2005

March 30, 2005

On Wed, Mar 30, 2005 at 07:15:58AM -0500, Arthur wrote: > What I can't and don't understand - as a 'radial" - was why those who > purport to most appreciate Python as it is would sign in mass unto an > endeavor which could foreseeable alter what it is and how it is used in > dramatic ways, and do so irretrievably. I'll try and answer that one. When I learned Python version 1.5.2 back in March of 1999, six years ago, I already had a lot of experience programming in C, C++, Pascal, Perl, etc. Learning Python made me a better programmer. Object-oriented programming concepts that were obscure in C++ became so much clearer in Python, with it's "everything is an object" and "first-class functions and classes." I took that philosophy and began writing better C++ code. But it didn't stop there. After I thoroughly learned Python 1.5.2, it evolved. It got generators and iterators, and I learned those too. By this time I was programming C# and Java. The new things I learned from Python 2.2+ made me a better C# and Java programmer. In 2004 I started using list comprehensions and generator expressions and the more accessible features of new-style classes, including properties and cooperative superclasses. All of these things made my life better. In 2005 (so far) I've now understood descriptors and how they can help me. Metaclasses are next on my list. And with every mind-expanding step I've become a better Java programmer. Even though Java doesn't have Python's features, those "patterns", when learned first in Python, really help. I feel like I'm water skiing, and Python is an intellectual power-boat towing me along. Perhaps you're saying "the boat's going too fast, I want to get off". Well, you may have that luxury, but I don't. I make my *living* doing this stuff. My wife and four hungry children depend on me keeping up with the world-class state of the art. If I were to decide that I've had enough, my brain is full, then I might as well find another line of work. Certainly I have an interest in Python code remaining accessible to entry-level programmers. I am not an elitist. But advanced Python features have made advanced programming accessible to *me*, when otherwise I might not have gotten into it, due to lack of time and perceived barriers to entry. I believe Python offers a lot to programmers at every level. The good old Python 1.5.2 feature set is still great for beginners, and that's the feature set I teach to beginners. But there is no limit to how far you can go in Python. If I taught beginners using, say, Visual Basic, I'm putting a ceiling over their heads. Python scales conceptually. And that's my 2 cents. David H.

2 1

RE: RE: [Edu-sig] RE: Integration correction
by Arthur March 30, 2005

March 30, 2005

> -----Original Message----- > From: Lloyd Hugh Allen [mailto:chandrakirti@gmail.com] > To: Arthur > Subject: Re: RE: [Edu-sig] RE: Integration correction > > I thought that there already were little black box libraries all over > the place. Just that most of them were in C etc. Yes, but... There was a bottom. The bottom has dropped out. Is the best I can express it. Art

1 1

RE:[edu-sig] Simpson exact
by Henrik Eriksson March 30, 2005

March 30, 2005

Kirby, you are working too hard! > >>> simpson(g,0,3,10000) > 8.9999999999999893 Why ten thousand intervals when one interval gives the exact result? >>> simpson(g,0,3,1) 9.0 Henrik

1 0

Re: RE: [Edu-sig] RE: Integration correction
by Lloyd Hugh Allen March 30, 2005

March 30, 2005

Oops. meant to reply to all. Sorry. On Wed, 30 Mar 2005 07:24:16 -0500, Lloyd Hugh Allen <chandrakirti(a)gmail.com> wrote: > I thought that there already were little black box libraries all over > the place. Just that most of them were in C etc. > > > On Wed, 30 Mar 2005 07:15:58 -0500, Arthur <ajsiegel(a)optonline.net> wrote: > > > > My fear is the evolution of libraries of little black boxes which will > > indeed change the landscape of Python dramatically - for better and for > > worse. > > > > What I can't and don't understand - as a 'radial" - was why those who > > purport to most appreciate Python as it is would sign in mass unto an > > endeavor which could foreseeable alter what it is and how it is used in > > dramatic ways, and do so irretrievably. > > > > Ah well.. > > > > Art > > > > > > _______________________________________________ > > Edu-sig mailing list > > Edu-sig(a)python.org > > http://mail.python.org/mailman/listinfo/edu-sig > > >

1 0