As I gear up to write or translate lessons for Crunchy Frog, I would like feedback on one general issue: // -- the new integer division operator. // is already legal in Python 2.4, though / still means the same thing for integers. That is to change in Python 2.5, that is already in alpha 2: / as integer division will able to be set to mean the old operator or always mean real division (I forget which is the default in 2.5). I think this is an excellent change in Python. I would encourage using // for integer division in all newly written lessons. There is the issue in 2.4 that you still have to go through an extra cast if you want real division, x = 5 y = 3 real_quotient = float(x)/y but there is nothing for that at the moment -- Andrew N. Harrington Computer Science Department Undergraduate Program Director Loyola University Chicago http://www.cs.luc.edu/~anh 512B Lewis Towers (office) Office Phone: 312-915-7982 Snail mail to Lewis Towers 416 Dept. Fax: 312-915-7998 820 North Michigan Avenue aharrin@luc.edu Chicago, Illinois 60611
On // and /, I neglected to mention that in Python 2.4 you can already use / for real division in any file where the top line imports from future: from __future__ import division Andrew Harrington wrote:
As I gear up to write or translate lessons for Crunchy Frog, I would like feedback on one general issue: // -- the new integer division operator.
// is already legal in Python 2.4, though / still means the same thing for integers. That is to change in Python 2.5, that is already in alpha 2: / as integer division will able to be set to mean the old operator or always mean real division (I forget which is the default in 2.5).
I think this is an excellent change in Python. I would encourage using // for integer division in all newly written lessons. There is the issue in 2.4 that you still have to go through an extra cast if you want real division, x = 5 y = 3 real_quotient = float(x)/y
but there is nothing for that at the moment
-- Andrew N. Harrington Computer Science Department Undergraduate Program Director Loyola University Chicago http://www.cs.luc.edu/~anh 512B Lewis Towers (office) Office Phone: 312-915-7982 Snail mail to Lewis Towers 416 Dept. Fax: 312-915-7998 820 North Michigan Avenue aharrin@luc.edu Chicago, Illinois 60611
On 5/26/06, Andrew Harrington <aharrin@luc.edu> wrote:
As I gear up to write or translate lessons for Crunchy Frog, I would like feedback on one general issue: // -- the new integer division operator.
It's hardly new; it was introduced in 2.2.
// is already legal in Python 2.4, though / still means the same thing for integers. That is to change in Python 2.5, that is already in alpha 2: / as integer division will able to be set to mean the old operator or always mean real division (I forget which is the default in 2.5).
Where did you get this? / won't change its meaning until 3.0. Ever since 2.2 you can force it to mean real division by using "from __future__ import division".
I think this is an excellent change in Python. I would encourage using // for integer division in all newly written lessons.
Right. We've been encouraging this ever since 2.2.
There is the issue in 2.4 that you still have to go through an extra cast if you want real division, x = 5 y = 3 real_quotient = float(x)/y
but there is nothing for that at the moment
Unless you want to promote the __future__ statement above. But that's questionable for newbies -- it's better to teach the current language. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
I would just like to point out that Python (compared to Smalltalk) http://www.smalltalk.org/articles/article_20041008_a1.html has always done division wrong, and the new approach still does division wrong, IMHO, from a mathematical (not implementation) perspective. :-) In a dynamic object system, especially one oriented towards beginners at all, the proper result from division of two whole numbers is a "fraction". Fractions can be represented as a special type of mathematical object different from either an integer or a floating point number, with the order of promotion when mixing various types being integer -> fraction -> floating point. Multiplying two fractions should still yield a fraction (unless it reduces, e.g. 3/5 * 5/3 --> 15 / 15 --> 1). Smalltalk has done this for twenty plus years. It's the way mathematicians work on the chalkboard (if any still do. :-) when working with equations and reducing terms. It lends itself to generalizations, like including units into expressions and reducing or multiplying units. if the mathematics library is written to be extensible. It's the way grade school math is taught. It avoids a loss of precision (converting, say, 2/3 to the imprecise 0.66666666666666663) until explicitly required (e.g. "float(2/3)"). If you want a float from a fraction, then in such a system you should generate it yourself, either by making one of the numbers a float (e.g. 3.0 / 5) or by taking the fractional result and converting it to a float ("float(3/5)"). Obviously "float(2/3)" in Python as it is now yields 0.0 not 0.59999999999999998. Python as a community is still stuck in an integer vs. floating point mindset left over from C, IMHO. Having said that, I don't necessarily think Guido is making the wrong decision for the overall Python community or language, e.g. his comments here: http://mail.python.org/pipermail/python-dev/2001-March/013587.html Just one example of how when a language goes down one path from a set of choices, it kind of gets stuck with them, and builds a community comfortable with those decisions (where others uncomfortable with them use other systems); the same is generally true for mailing lists about any topic :-). The bigger issue here is actually that in Smalltalk these sort of things are done by user accessible libraries, and so you could use a different math library or extend the current one without changing the language, whereas in Python (especially in the past) they are more under the covers hidden in C and built into the system, at least as far as is generally thought and discussed. Still, here is Python implementation of fractions done by Mike Hostetler: http://users.binary.net/thehaas/fractionpy.shtml (haven't tried it myself though.) So, it is possible. And as Python moves to more generally unified types and objects by default, stuff like that may be done more and more as more people think of it. And I think it would be nice for a standard to evolve for that, especially from a "using Python to teach mathematics" standpoint. Personally, I think that since one isn't going to be doing much serious number crunching computation in Python itself (compared to NumPy or some other library accessed through Python) that having fractions in Python isn't much of a performance issue in practice (more a coding style change if anything to be explicit about floats). But it certainly is a potential major compatibility issue, so I can see the argument for the current approach, although to be fair, any minor change affecting math is a major compatibility issue, and the current behavior of 2/3 == 0 is always surprising. It would seem problematical to beginners to need to learn yet another operator, yet another inconsistency, and so on, before it is needed; I have no problem by itself with a "//" operator, which is useful in special circumstances, as is one to yield a remainder, see for example: http://mail.python.org/pipermail/python-list/2001-August/060184.html So I think from a pedagogical point of view, getting kids to use "//" when "/" really should be OK at the start and maps onto the infix syntax they already know is at the very best an ugly necessity to gain other Python benefits, given how Smalltalk shows that operator is not needed for routine mathematics or for beginners. Still, given the current situation, I think your suggestion makes sense. --Paul Fernhout Andrew Harrington wrote:
As I gear up to write or translate lessons for Crunchy Frog, I would like feedback on one general issue: // -- the new integer division operator.
// is already legal in Python 2.4, though / still means the same thing for integers. That is to change in Python 2.5, that is already in alpha 2: / as integer division will able to be set to mean the old operator or always mean real division (I forget which is the default in 2.5).
I think this is an excellent change in Python. I would encourage using // for integer division in all newly written lessons. There is the issue in 2.4 that you still have to go through an extra cast if you want real division, x = 5 y = 3 real_quotient = float(x)/y
but there is nothing for that at the moment
On 5/26/06, Paul D. Fernhout <pdfernhout@kurtz-fernhout.com> wrote:
I would just like to point out that Python (compared to Smalltalk) http://www.smalltalk.org/articles/article_20041008_a1.html has always done division wrong, and the new approach still does division wrong, IMHO, from a mathematical (not implementation) perspective.
Scheme also has a built in rational number type. There's been some discussion of building that in to Python, but my understanding is that's being left to libraries at this point. We already have any number of Rational Number implementations (I've written a few myself). Adding a new decimal type (different from floating point) became the focus instead (good choice of priorities IMO). Are you subscribed to pydev by the way? You seem inclined to redesign Python in some fundamental way, and that's unlikely to happen as a result of posts to edu-sig. We tend to take Python as a given. Kirby
On 5/26/06, kirby urner <kirby.urner@gmail.com> wrote:
Scheme also has a built in rational number type. There's been some discussion of building that in to Python, but my understanding is that's being left to libraries at this point. We already have any number of Rational Number implementations (I've written a few myself).
Rationals are easy to implement and easy to understand from a mathematical POV, but not practical when it comes to computing your taxes. ABC used rationals and it was not a success (except amongst mathematicians :-). Floating point decimal is a much better choice. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
I am just getting started on teaching python as a first language. (The same course at the same university that Andy is teaching this fall, actually.) Since the course is actually a breadth introduction to computing as well as an introduction to programming, time is of the essence. My decision was to simply tell students that fractional numbers on computers are tricky business, and that if they plan to go much further they would have to learn about them, but that I was going to stick to integers. fwiw I find this to be the most cognitively accessible approach. The advantage of Python as a first language is the minimization of intellectual clutter. We can start with procedural knowledge and move to semantic knowledge gradually. Avoiding the complexities of the representation of fractional numbers seems like the best approach at this stage. If I had a bit longer I would still not introduce floats or decimals or infinite precision or fraction objects or any other variation common or obscure at least for the first few weeks. I think it's best, at least for didactic purposes, that there is a handy division operator that is closed on the integers, and I'd prefer to maintain the existing behavior of operator.div when presented with two ints. mt
On 5/26/06, Michael Tobis <mtobis@gmail.com> wrote:
My decision was to simply tell students that fractional numbers on computers are tricky business, and that if they plan to go much further they would have to learn about them, but that I was going to stick to integers.
I would not make this decision. Floating points aren't so problematic that we need to avoid them for several weeks. Several minutes maybe. Kirby
Kirby, I am confident you are dealing with a different population with different interests and skills. Some of my students are taking the course because they are math-averse, and Loyola allows the survey of computing as a fulfillment of a math requirement in business and liberal arts curricula INSTEAD of a conventional math course. I am much more interested in teaching this crowd abstraction, rigor, and orthogonality than exponents and mantissas. I have already rocked their boats trying to explain twos complement. I promise you these people do not need to know what a float is and how it differs from a mathematical real, that on the whole they are not equipped to understand it, and that it would be a bad idea to explain it. Generalizing from this, I suspect a big part of what makes teaching Python such a quandary is that it is so accessible. (As with many of its problems, c.f. "too many web frameworks", this is symptomatic of the language's strengths, but that doesn't mean it isn't a problem) There are diverse audiences that might be exposed, and that in turn makes a uniform curriculum problematic. mt
I introduce the issue of integer versus floating point division by giving (high school) students a self-directed programming challenge that will lead them to the head scratching conclusion that division doesn't work exactly in the manner that they expect. Using long division on the board, it's pretty easy to demonstrate how integer division and use of the modulo division complement one another. As time is also of the essense in my course, we usually settle on the pragmatic axiom of almost always using a floating-point divisor. This reminds me of the recent thread regarding equal sign ambiguity. Perhaps we could start collecting examples of familiar symbols from mathematics that might confuse a new programmer. Kevin Driscoll
On 5/26/06, Michael Tobis <mtobis@gmail.com> wrote:
Kirby, I am confident you are dealing with a different population with different interests and skills. Some of my students are taking the course because they are math-averse, and Loyola allows the survey of computing as a fulfillment of a math requirement in business and liberal arts curricula INSTEAD of a conventional math course.
I am much more interested in teaching this crowd abstraction, rigor, and orthogonality than exponents and mantissas. I have already rocked their boats trying to explain twos complement. I promise you these people do not need to know what a float is and how it differs from a mathematical real, that on the whole they are not equipped to understand it, and that it would be a bad idea to explain it.
I'm not talking about getting into all the details. Just tell 'em to expect some weirdo rounding phenomena, odd last digits and so on, based on the fact that Python is internally using base two when doing decimals. That's all you need to say. But to eschew using floats for weeks just overdramatizes everything and makes them averse to using a very basic and important feature of this computer language. That does them a disservice. I use floats with 8th graders immediately and have never had any problems.
Generalizing from this, I suspect a big part of what makes teaching Python such a quandary is that it is so accessible. (As with many of its problems, c.f. "too many web frameworks", this is symptomatic of the language's strengths, but that doesn't mean it isn't a problem)
The problem with the academics Bernie talks about is no one teaches them Python. They're busy professionals and when they open a tutorial they see a lot of jargon is already assumed (iterator, class, object...). These are proud people, very smart, so they're not about to enroll in my 8th grade class, where all would be made clear.
There are diverse audiences that might be exposed, and that in turn makes a uniform curriculum problematic.
mt
I never said anything about a uniform curriculum. I do think avoiding floats because you think using them means explaining a lot of stuff about mantissas is not a good approach. However, if these are business students, then definitely get in to the decimal class, which is designed for use with currencies (money). Kirby
participants (6)
-
Andrew Harrington -
Guido van Rossum -
Kevin Driscoll -
kirby urner -
Michael Tobis -
Paul D. Fernhout