Mailman 3 October 2002 - Edu-sig

re: Types and true division (was Re: strange output)
by Arthur Oct. 10, 2002

Oct. 10, 2002

>I couldn't agree more. The removal of barriers that are nothing more than >arbitrary in the modern era of programming languages is a key reason for what >is looking like its successful adoption at one of the most prestigious >educational institutions in the UK. And crucially, in preference to C. In the world. Don't be modest. But I will stick to my guns that we have a legimate disagreement. I wouldn't be here if I didn't think Python does an all in all brilliant job of addressing these issues. But like in all things, there comes a point of dimishing returns, then negative returns. Where is that point? If the underlying numeric typing system were in fact to disappear with some kind of actual unification implementation, obviously there becomes nothing to discuss. The phrase "premature optimization" comes to mind again here. You readily admit that you are not getting across important and fundamental issues regarding numerics in Python that a physics student *needs* to know. I contend those issues are getting too deeply submerged, without losing *any* of their fundamental importance. Now all I am asking, because alll I am in a position to ask, is that we acknowledge ourselves to have an honest disagreement. Art

1 0

Re: [Edu-sig] re: Types and true division (was Re: strange output)
by Michael Williams Oct. 10, 2002

Oct. 10, 2002

In message <200210101159.g9ABxV006652(a)pcp02138704pcs.reston01.va.comcast.net> Guido van Rossum <guido(a)python.org> writes: > > Certainly I had nor have no reason to believe that Guido, in the > > weighing of pros and cons, took at all seriously the possiblity that > > the div operator change might be *harmful* to folks looking to > > Python as an introduction to programming. > > If we take this argument seriously, perhaps Python would become a > better language if we crippled it some more. Let's limit the maximum > size of lists to 32767, and the maximum size of dicts to 32768. Let's > make multiplication undefined when the result is larger than 2**33. > Let's truncate all identifiers to 6 characters. Let's make keywords > (but not identifiers) case-insensitive. Let the program die with a > core dump upon division by zero. > > Seriously, Art, it sounds like you struggled with a problem and are > proud that you overcame it, and now you want others to have the same > experience. > > I'll tell you what. The school of hard knocks sucks. There are > plenty of *interesting* problems in programming to break your head on, > there's no need to surrect artificial barriers. Save some brain cells > to think about an efficient sorting algorithm or a generational > garbage collector (never mind that Python comes with these built-in as > well). I couldn't agree more. The removal of barriers that are nothing more than arbitrary in the modern era of programming languages is a key reason for what is looking like its successful adoption at one of the most prestigious educational institutions in the UK. And crucially, in preference to C. We don't have to waste time teaching specific language/arcitechture features and can concentrate on the algorithms, which is what people who use programming as a means rather than an end are interested in. -- Michael

1 0

Types and true division (was Re: strange output)
by Arthur Oct. 10, 2002

Oct. 10, 2002

Morning rounds. Michael writes: >The course is a *programming* course (not a physics course, although it is for >physics undergrads). and Micahel writes: > Numeric typing is important, yes, but when you've got two >days to teach students programming, you've got to be selective. 2 days. Maybe I am irretrievable scarred by the fact that my undergardauate degree is in English literature. But I can't help feeling the discussion is in harm of being misdirected when you emphasize in one post that you are teaching *programming* and don't mention that whatever it is you are teaching you are teaching in a 2 day course. I am of recent vintage allowing myself to call what I am capable of doing: *programming*. 3 or 4 years of fairly intense effort. With allowances for native intelligence issues and aptitudes, for the natural decay of brain cells (I'm not 20), and with an additional fudge factor for the long-term effects of some of my late 1960's and early 1970's recreational ingestions - maybe someone else could get there is a 1 1/2 or 2.. The issue then remains at least to some extent one of constituencies. I am not sure how much I would like to see Python try to configure itself as the perfect solution to the 2 day programming course. Because the concept itself is a little bizarre, IMO. I came across this quote in the book "The Cognitive Computer", by Roger C. Schank - an artificial intelligence researher, I believe of some note: """ There is one very good reason to learn programming, but it has nothing to do with preparing for high-tech carerrs or with making sure one is computer literate in order to avoid being cynically manipulated by the computers of the future. The real value of learning to program can only be understood if we look at learning to program as an exercise of the intellect, as a kind of moden-day Latin that we learn to sharpen our minds. """ I was once asked on a Python list in a course of one these contentious debates, in a not very friendly tone, who it was I thought I was representing with my comments. I guess I would at least like to *think* I am representing anyone coming to the study of Pythion with that kind of attitude and and those kinds of goals. Might not be *the* constituency, but certainly *a* constituency. Art

3 2

Re: [Edu-sig] Types and true division (was Re: strange output)
by Michael Williams Oct. 7, 2002

Oct. 7, 2002

In message <004601c26bfc$dcf1cd00$9865fea9@arthur> "Arthur" <ajs(a)ix.netcom.com> writes: > >The course is a *programming* course (not a physics course, although it is > for > >physics undergrads). You can read the handbook and my dissertaion > discussing > >Python's relative merits here: > > I read excerpts of the handbook and dissertation - both of which are > interesting. > > But I don't agree with your take on "/". Or necessarily disagree. 1/2=.5 > *is* more intutive to someone who has not programmed before. Common sense > would allow us to conclude that is true in the absence of any study of the > issue. Just as I think common sense allows us to conclude that list[1] is > more intutively the first item in the list, rather than the second. Indeed. > You toss off the issue of numeric typing is a few sentences of the handbook, > and it comes into play in the creation of Numeric arrays. Correct. > The problem is that I don't think you will know to what extent your students > actually grasp the significance of the numeric typing issue. One can get > far enough without understanding it. It only becomes an issue when it > becomes an issue. The whole reason we're using Python is that we can get away without explaining everything the first time around, and come back to stuff like this in a second year course. Numeric typing is important, yes, but when you've got two days to teach students programming, you've got to be selective. > For example perhaps while doing a > > a[1] = .5 > > to an array that was initially as an int array, not so much consciously as > by a=array([1,2,3}). > > Not something that one does everyday. This actually came up in onse student's program -- so you are correct that it is a real problem. > The interesting study might be to see if your students acutally *get* the > significance and pitfalls of the underlying numeric typing system. I would imagine not. ;-) > Seems to me that for a physics student, it is particularly important that > they do. For example, to be aware of the pitfalls that can arise in > comparing values for equality. As I say above, unfortunately we have to be *very* selective. It was decided it was worth spending more time on procedural concepts like control flow, and some time on graphing, simply because those two very quickly give an immediate and tangible return on a student's investment of their time. We have a real problem with student retention; programming becomes an elective in the second year. I agree with you entirely that typing and the internal representation system of a computer is *crucial* to a physicist's understanding. Whether it's the *most crucial* is another matter ;-> > So I still ask whether it is necessarily true that the more intutive > behavior is the behavior we should prefer in all cases. It is perhaps > unintuitive to suggest not. But I am suggesting it. This argument was pretty much done to death around the time of the PEP on comp.lang.python. By the way, the versions of both my handbook and dissertation on <http://users.ox.ac.uk/~sann1276/> are not final versions. In particular, our first batch of "real" first years (not trial volunteers) arrive next week, and we're putting a lot of finishing touches to it. For example, after you reminded me of the problem with truncation of floats when stored in arrays of ints I added a little bit on this. Thanks for your comments. I'll be posting to this list and other relevant ones when there is something a bit more final to look at (which had better be within the next few days, otherwise I'm in trouble!) Cheers, -- Michael

1 0

Fw: [Visualpython-users] Re: strange output
by Arthur Oct. 4, 2002

Oct. 4, 2002

>The course is a *programming* course (not a physics course, although it is for >physics undergrads). You can read the handbook and my dissertaion discussing >Python's relative merits here: I read excerpts of the handbook and dissertation - both of which are interesting. But I don't agree with your take on "/". Or necessarily disagree. 1/2=.5 *is* more intutive to someone who has not programmed before. Common sense would allow us to conclude that is true in the absence of any study of the issue. Just as I think common sense allows us to conclude that list[1] is more intutively the first item in the list, rather than the second. You toss off the issue of numeric typing is a few sentences of the handbook, and it comes into play in the creation of Numeric arrays. The problem is that I don't think you will know to what extent your students actually grasp the significance of the numeric typing issue. One can get far enough without understanding it. It only becomes an issue when it becomes an issue. For example perhaps while doing a a[1] = .5 to an array that was initially as an int array, not so much consciously as by a=array([1,2,3}). Not something that one does everyday. The interesting study might be to see if your students acutally *get* the significance and pitfalls of the underlying numeric typing system. Seems to me that for a physics student, it is particularly important that they do. For example, to be aware of the pitfalls that can arise in comparing values for equality. So I still ask whether it is necessarily true that the more intutive behavior is the behavior we should prefer in all cases. It is perhaps unintuitive to suggest not. But I am suggesting it. Art

1 0

re: Enter into it, we can
by Arthur Oct. 4, 2002

Oct. 4, 2002

Is this perhaps the newest of the new, new paradigms?

1 0

Enter into it, we can
by Tienzen (Jeh-Tween) Gong Oct. 4, 2002

Oct. 4, 2002

1 0

Re: [Edu-sig] Fw: [Visualpython-users] Re: strange output
by Michael Williams Oct. 4, 2002

Oct. 4, 2002

In message <001101c26baa$5d8cb4f0$9865fea9@arthur> "Arthur" <ajs(a)ix.netcom.com> writes: > All of which to me speaks to the better use of language in conducting > discussions around these points. As far as I am aware nobody interested in > Python as an introductory *programming* language ever raised a serious > objection to the "/" operator behavior as it stood. It concerned me that > the potential for a conflict of interests between different classes of > "novices" was never addressed in the debate. Novices were newbies, were > non-programmers. But the distinction of one's with an eye toward truly > learning programming, and ones with no interest in getting below the top > surface of scripting a little ditty or two, were discussed as if they were > somehow one class of folk. FWIW, here at the University of Oxford we're beginning a teaching course using Python as the principal language (replacing Pascal). We chose to go to the trouble of making future/true division the default behaviour for exactly the reasons described in the PEP. I didn't raise an objection to the / behaviour at the time because I wasn't using Python. I'm glad it's changing though. The course is a *programming* course (not a physics course, although it is for physics undergrads). You can read the handbook and my dissertaion discussing Python's relative merits here: http://users.ox.ac.uk/~sann1276/python/ -- Michael

1 0

Fw: [Visualpython-users] Re: strange output
by Arthur Oct. 4, 2002

Oct. 4, 2002

Doing my morning rounds of annoying posts. Thought I'd forward this up to edu-sig. Bruce Sherwood, FWIW, was an influential advocate of the change in the "/" operator (in that Guido referred to his position and classroom experience a number of times in the course of the debate). Bruce says without ambiguity that his position is based on the fact that his students where thrown by the fact that Python did not behave as a calculator. Of course Bruce is a physics instructor, with *no* particular interest in conveyuing programming ideas to his students, Even basic ones. Except to the extent it effects their ability to use one particular library - VPython. Which by the way he had very little to do with creating - at least in terms of actually writing code. All of which to me speaks to the better use of language in conducting discussions around these points. As far as I am aware nobody interested in Python as an introductory *programming* language ever raised a serious objection to the "/" operator behavior as it stood. It concerned me that the potential for a conflict of interests between different classes of "novices" was never addressed in the debate. Novices were newbies, were non-programmers. But the distinction of one's with an eye toward truly learning programming, and ones with no interest in getting below the top surface of scripting a little ditty or two, were discussed as if they were somehow one class of folk. ----- Original Message ----- From: "Arthur" <ajs(a)ix.netcom.com> To: "Bruce Sherwood" <basherwo(a)unity.ncsu.edu>; "vpusers" <visualpython-users(a)lists.sourceforge.net> Sent: Friday, October 04, 2002 9:13 AM Subject: Re: [Visualpython-users] Re: strange output > I think it worth supplementing Bruce's analysis with the solution to what > was trying to be accomplished by > > rininitial = ball.pos > > I believe either: > > rinitial = ball.pos[:] > > or > > rinitial =copy(ball.pos) > > would get one to where one is trying to go. > > [:] returns a complete "slice" of the list. > copy, of course, a copy of the list. > > In either case rinitial is no longer an additional name for ball.pos, but an > object independant of it, which will not be modified upon the modification > of ball.pos. > > I think I have this right. Corrections welcome. > > Art > ----- Original Message ----- > From: "Bruce Sherwood" <basherwo(a)unity.ncsu.edu> > To: "vpusers" <visualpython-users(a)lists.sourceforge.net> > Sent: Friday, October 04, 2002 8:16 AM > Subject: [Visualpython-users] Re: strange output > > > > A VPython user sent me a small program that behaved oddly, and I thought I > > should share my analysis, since it involves an aspect of Python that is > > subtle and may be missed in early study of the language. Fortunately it > > rarely bites students writing computational physics programs! > > > > Early in the program the user said "rinitial = ball.pos" which means > "assign > > an additional name to ball.pos, so that in the future one can refer to the > > ball's position either by the label (name) ball.pos or the label (name) > > rinitial". You can have lots of names pasted onto the same thing. The > puzzle > > for the user was that later in the program (after moving the ball around), > > printing rinitial showed the new value of ball.pos, not the initial value. > > > > This multiple labeling has consequences only with "mutable" objects such > as > > lists -- objects whose values can be changed in situ. For example, if you > > say "a = 5" and then "b = a", and then say "a = 7", b will still have the > > value 5. When you assign 7 to a, you create a new object ("7") and attach > > the label "a" to it, so b continues to be a label for the object "5". > > > > But with "rinitial = ball.pos", you can actually change ball.pos without > > creating a new object. For example, you might say "ball.pos.y = 7" in > which > > case the 2nd element in the ball.pos list has changed (without affecting > the > > other two elements). Since rinitial is a label for ball.pos, printing > > rinitial shows you the new value of ball.pos. > > > > A list such as [1,2,3] is mutable. The Visual vectors are mutable. A > 'tuple' > > such as (1,2,3) is not mutable. Constants such as 3 or pi or a string such > > as 'cat' are not mutable. > > > > Needless to say, it took me a while to pay attention to "mutability" as an > > important property of Python objects! > > > > Bruce > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Visualpython-users mailing list > > Visualpython-users(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/visualpython-users > > >

1 0

handling money and floats with beginners
by Tim Wilson Oct. 3, 2002

Oct. 3, 2002

Hi everyone, I'm struggling a bit with explaining how important it is to handle floating point numbers correctly when doing calculations with money. My latest assignment (http://isd197.org/sibley/cs/icp/loancalc_html) involves calculating and printing a load payment schedule and I want my students to do things "the right way." My assignment instructions include a link to the Floating Point Arithmetic section of the python tutorial, but it's not quite enough. Does anyone have any code snippets that illustrate the problem clearly and are understandable by novices? My instructions say that the simplest approach is to do money-related calculations in pennies. Is that really the best approach for beginners? I didn't address this issue very well last year and I'd like to do a better job this time around. -Tim -- Tim Wilson | Visit Sibley online: | Check out: Henry Sibley HS | http://www.isd197.org | http://www.zope.com W. St. Paul, MN | | http://slashdot.org wilson(a)visi.com | <dtml-var pithy_quote> | http://linux.com

2 1