Before going further in attempting to contribute to the discussions of Pep238 (or case sensitivty) allow be to present my credentials.
None, to speak of.
Except that I've been through the program. Guido's program. His language. His environment. His tutorials.
I think with some success.
Participate little on python-list, because much of what goes on is over my head.
But on the question of learning programming with Python - as I mention, been through the program.
Here the issues are under my nose, not over my head.
I particpate actively on the edu-sig list, because I understand my success could be other's success. Am a big supporter of Guido's CP4E ideals.
Yet despite the gratitude I try to keep in mind, I clash consistently with Guido on CP4E - sometimes in unpleasant ways.
Can only hope he appreciates at some level that I bring some passion to the table on some common goals.
Because that clash now spills over to the Python list.
Since I have convinced myself that not only do I object to the rationale and evidence gathering behind the integer division change - I am going to step up and be arrogant enough to say that I am against it as a design feature, in light of the only aspect of Python design about which I would dare to speak - CP4E goals.
3 / 4 = 0 3.0 / 4 = .75
Something important is going on here. I have a decent understanding of what that is. Enough to get me by in the real world.
I came to It - having already understood that I would only get so far if I expected it all to come to me.
That reckoning has been put off an hour ot two for the Python 2.2 learner, with a measurable cost.
Pity for the Python2.2 learner.
Quite well realize that I am not saying anything that hasn't been said before on the issue.
But disappointed to never have heard the counter argument from Guido - what put the issue over the top for him?
If I was told that experinced programmers might appreciate this change for any possible reason - I'd be quiet as a mouse.
Since I remain convinced that the single most important factor for Python's acceptance as an educational language is the growth of its acceptance as a professional language.
It will be interesting to see where Guido chooses to draw the line on the thought process that lead him to his integer division conclusion.
Which is the real issue - the integer division thing, stand-alone, not likely to be a deal breaker for anyone.
Like to believe that there is more real world thinking than Guido chooses to share publicly.
Arthur Siegel and I seem to be pushing each other's buttons constantly. I don't know why it is, but ever post of his feels like a flame or flamebait to me. I always feel that he attacks me as a person rather than attacking my arguments (usually because he claims that I haven't given any arguments). Try as I may, this makes it very hard, almost impossible for me to respond in a meaningful manner to Arthur's posts. I wonder what I've done to tick him off. I also wonder how come he is so good at ticking me off.
The reason for wanting / to return a float (or at least a type that can represent close approximations of numbers like 0.75) has been discussed many times before. The summary of the argument in the PEP may not be complete, but I disagree with Arthur's assessment that integer division is not a problem -- the VPython folks have ample experience that it is.
Because all Arthur does is tick me off, I'll leave it at this -- maybe someone else can explain it all to him.
On Sun, 22 Jul 2001 11:01:08 -0500, Arthur_Sie...@rsmi.com <Arthur_Sie...@rsmi.com> wrote:
> If I was told that experinced programmers might > appreciate this change for any possible reason - > I'd be quiet as a mouse.
I don't think they will..
> Since I remain convinced that the single most important > factor for Python's acceptance as an educational language is > the growth of its acceptance as a professional language.
First of all, it's really ugly. It's the ugliest thing in python for a newbie, imho. Yes, 1/2 is 0. You have to type 1.0/2 to get 0.5. No, there is no good reason for that, just memorize it. Ugh.
If it was just a matter of that, it wouldn't be enough for a change (non- backwards-compatible one). But, the problem is that people will have strange bugs because of this and spend hours upon hours trying to figure out what's wrong. Python may be around during next 10-20 years and userbase may grow a thousandfold, and having this ugliness on board for all this time is a big problem.
It's arguable whether the problem is serious enough to break old code, but it's obvious (to me, anyway) that there *is* a rather big problem here.
> It looks like it hasn't been updated since March. I see no support for the > argument that the current integer division semantics are confusing, only a > claim that the current semantics are a problem. Perhaps there's a more > recent version of the PEP available that hasn't been released to the > website.
Skip,
I've asked Moshe today to update the rationale based on the discussion in c.l.py. He said he would. So just be patient.
Guido> The reason for wanting / to return a float (or at least a type Guido> that can represent close approximations of numbers like 0.75) has Guido> been discussed many times before. The summary of the argument in Guido> the PEP may not be complete, but I disagree with Arthur's Guido> assessment that integer division is not a problem -- the VPython Guido> folks have ample experience that it is.
It looks like it hasn't been updated since March. I see no support for the argument that the current integer division semantics are confusing, only a claim that the current semantics are a problem. Perhaps there's a more recent version of the PEP available that hasn't been released to the website.
> It looks like it hasn't been updated since March. I see no support for the > argument that the current integer division semantics are confusing, only a > claim that the current semantics are a problem. Perhaps there's a more > recent version of the PEP available that hasn't been released to the > website.
Not really. I'm working on the PEP, and hopefully there will be a new version tommorow with some more meat. -- gpg --keyserver keyserver.pgp.com --recv-keys 46D01BD6 54C4E1FE Secure (inaccessible): 4BD1 7705 EEC0 260A 7F21 4817 C7FC A636 46D0 1BD6 Insecure (accessible): C5A5 A8FA CA39 AB03 10B8 F116 1713 1BCF 54C4 E1FE
> ... > If I was told that experinced programmers might > appreciate this change for any possible reason - > I'd be quiet as a mouse.
Not all experienced programmers agree. At the last Python Conference, I moderated a 40-some person group discussion on conceivable changes to Python's numeric model, not advocating but keeping the participants from killing each other <wink>. The meaning of integer division wasn't the focus, but naturally came up. By show of hands, about 3/4ths of the participants agreed that 3/4 should not return 0, but rather *something* x such that x*4 had a better chance of being confused with 3 than with 0. There was no consensus on exactly what 3/4 should return -- rational or HW float or decimal float were the most popular alternatives.
It shouldn't be so hard to understand why. The current integer division loses information silently and without a trace. Combined with that Python is not a statically typed language, there's simply no telling what e.g.
def velocity(distance, time): return distance / time
will compute by inspection. This isn't about esoteric user overloading of "/", it's about ordinary arithmetic on builtin numeric types, and many experienced Python programmers have testified over the years to being burned in practice by stuff exactly that simple.
I expect that either way is easy enough to *teach*, but I don't accept ease of teaching as a primary goal: I'm much keener on semantics that, once *learned*, are hard to forget or to stumble over. Even if such semantics are 100x harder to teach at first, fine by me: you spend the rest of your life living with the consequences. I wish the definition of continuity were easier to teach too, but that doesn't mean I'll settle for an easier definition that doesn't actually work <wink>.
some-mice-are-surprised-when-thet-divide-up-the-cheese-and- cheese-mass-mysteriously-disappears-ly y'rs - tim
I'm the last person to avoid going off on a tangent.
On Sun, 22 Jul 2001 14:22:21 -0400, "Tim Peters" <tim....@home.com> wrote: > I wish the definition of continuity were > easier to teach too, but that doesn't mean I'll settle for an easier > definition that doesn't actually work <wink>.
Here is one that is easier to teach, if you just reverse the order of teaching calculus and first-order logic and basic set theory.
A function is continuous at c if, when embedding the world of Reals into a saturated model (or, say, 2^{Beth_omega} saturated, if you don't want to get into subtle assumptions), for every infinitesimal x, f(c+x)-f(c) is an infintesimal.
Of course, you might think that teaching about saturation is hard -- well, it might be ;-)
In article <mailman.995826216.11537.python-l...@python.org>, "Tim Peters" <tim....@home.com> wrote:
> By show of hands, about 3/4ths of the > participants agreed that 3/4 should not return 0, but rather *something* x > such that x*4 had a better chance of being confused with 3 than with 0.
Well then, float is a very bad choice for what to return, or then how do we explain when 3/4 * 4 = 3 (exactly) but 3/10 * 10 != 10?
I would be a lot happier with integer / integer = rational (as in Mathematica's programming lang), but float is just ugly. It is turning exact values (integers) into approximate ones (float) when I didn't tell it to. It's almost as bad as if integer subtraction always truncated to 16 bit values -- a lot of the time that would give sort of reasonable answers but it's a gratuitous approximation where you didn't expect one. -- David Eppstein UC Irvine Dept. of Information & Computer Science eppst...@ics.uci.edu http://www.ics.uci.edu/~eppstein/
In article <eppstein-03540D.13070222072...@news.service.uci.edu>, David Eppstein <eppst...@ics.uci.edu> wrote:
> Well then, float is a very bad choice for what to return, or then how do > we explain when 3/4 * 4 = 3 (exactly) but 3/10 * 10 != 10?
Uh, of course I meant 3/10 * 10 != 3... -- David Eppstein UC Irvine Dept. of Information & Computer Science eppst...@ics.uci.edu http://www.ics.uci.edu/~eppstein/
Tim Peters wrote: > By show of hands, about 3/4ths of the > participants agreed that 3/4 should not return 0, but rather *something* x > such that x*4 had a better chance of being confused with 3 than with 0. > There was no consensus on exactly what 3/4 should return -- rational or HW > float or decimal float were the most popular alternatives.
This has probably already been brought up, but perhaps the problem lies not with the "/" operator, but one step earlier in distinguishing the meaning of:
x = 3 and x = 3.
That is subtle difference that can cause quite different results later on.
Or, one may try to teach that when ALL arguments of an operator are in one "set", such as the set of integers, then one must expect a result that is an element from THAT set, not another set, such as the set of real numbers or from the set of complex numbers. Set theory seems to be taught fairly early on in math, I think.
It has been my observation that people can often quickly grasp and make use of the common underlying general principles behind things after having seen only a few examples, provided there is a CONSISTENT underlying principle. A handful of general rules may be easier to teach than a collection of special cases. So can and should Python adopt an underlying principle along the lines where one can grasp the following pattern:
integer = integer operator integer real = integer operator real real = real operator integer real = real operator real complex = integer operator complex ...
I prefer a handful of general rules, and operators that obey them.
David Eppstein wrote: > I would be a lot happier with integer / integer = rational (as in > Mathematica's programming lang), but float is just ugly. It is > turning > exact values (integers) into approximate ones (float) when I didn't > tell it > to. It's almost as bad as if integer subtraction always truncated to > 16 > bit values -- a lot of the time that would give sort of reasonable > answers > but it's a gratuitous approximation where you didn't expect one.
I agree. It's turning an otherwise fairly strongly (but dynamically) typed language on its head. If I want type-changing operations, I'll do them explicitly.
-- Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/ __ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE / \ Wretches hang that jurymen may dine. \__/ Alexander Pope Esperanto reference / http://mirror/alcyone/max/lang/esperanto/ An Esperanto reference for English speakers.
> I wish the definition of continuity were easier to teach too, but that > doesn't mean I'll settle for an easier definition that doesn't actually > work <wink>.
[Moshe Zadka]
> Here is one that is easier to teach, if you just reverse the order > of teaching calculus and first-order logic and basic set theory.
> A function is continuous at c if, when embedding the world of Reals > into a saturated model (or, say, 2^{Beth_omega} saturated, if you > don't want to get into subtle assumptions), for every infinitesimal x, > f(c+x)-f(c) is an infintesimal.
> Of course, you might think that teaching about saturation is hard -- > well, it might be ;-)
Na, they always leave *some* of the foundations in intro calculus courses fuzzy. H. Jerome Keisler wrote a very good intro calculus text based on non-standard analysis, unfortunately now out of print. See
for publication details. He didn't try to explain the intricacies of model theory, he just spelled out "the rules" for working with infinitesimals and got on with it. Huge steaming masses of epsilon-delta proofs were conspicuous by absence, so he was able to get to "the interesting stuff" a lot quicker that way. A good feel for the flavor of the approach can be gotten by skipping to the end ("Part IV: Turning Calculus into Algebra") of
Tim Peters <tim....@home.com> wrote: > [Arthur_Sie...@rsmi.com] >> ... >> If I was told that experinced programmers might >> appreciate this change for any possible reason - >> I'd be quiet as a mouse. > Not all experienced programmers agree. At the last Python Conference, I > moderated a 40-some person group discussion on conceivable changes to > Python's numeric model, not advocating but keeping the participants from > killing each other <wink>. The meaning of integer division wasn't the > focus, but naturally came up. By show of hands, about 3/4ths of the > participants agreed that 3/4 should not return 0, but rather *something* x > such that x*4 had a better chance of being confused with 3 than with 0. > There was no consensus on exactly what 3/4 should return -- rational or HW > float or decimal float were the most popular alternatives. > It shouldn't be so hard to understand why.
[snip Tim's reasons]
The audience was entirely self-selected; they were people with an interest in numeric models. Did Guido ask for a show of hands in the big session afterwards? I don't recall; I kind of suspect the outcome would've been different.
> The current integer division > loses information silently and without a trace. Combined with that Python > is not a statically typed language, there's simply no telling what e.g. > def velocity(distance, time): > return distance / time > will compute by inspection.
There's no telling what:
def add_stuff(a, b): return a + b
will compute by inspection either, though. Are we complaining about that? (yeah, I know the inverse operation is rather hard to define for string addition :)
[snip]
Of course I claim no expertise in this matter whatsoever. :) For working with pixels in GUIs and such, integer division can be a useful thing, though.
Regards,
Martijn -- History of the 20th Century: WW1, WW2, WW3? No, WWW -- Could we be going in the right direction?
* Tim Peters <tim....@home.com> menulis: | | The meaning of integer division wasn't the | focus, but naturally came up. By show of hands, about 3/4ths of the | participants agreed that 3/4 should not return 0, but rather *something* | [snip]
In other words, nobody raised their hand, since 3/4 == 0. Well, that settles it, then -- nobody wants this change <0.75 wink>.
-- Cliff Crawford http://www.sowrong.org/ A sign should be posted over every campus toilet: "This flush comes to you by courtesy of capitalism." -- Camille Paglia
On Sun, 22 Jul 2001 13:24:22 -0700, Erik Max Francis <m...@alcyone.com> wrote:
> I agree. It's turning an otherwise fairly strongly (but dynamically) > typed language on its head. If I want type-changing operations, I'll do > them explicitly.
Be sure to tell math.cos that...it has been "silently" turning integers into floats for years.
> Well then, float is a very bad choice for what to return, or then how > do we explain when 3/4 * 4 = 3 (exactly) but 3/10 * 10 != 10? [3 > was intended here]
Using decimal floats, 3/10*10 does equal 3, but a generation raised on BCD-ish hand calculators wouldn't even blink an eye if 1/3*3 returned 0.999999999999.
> I would be a lot happier with integer / integer = rational (as in > Mathematica's programming lang),
That view has its fans too; see PEPs 239 and 240; also mounds of prior discussion on the python-numerics list:
You're probably new enough to this to have missed that Guido had lots of experience with rationals in the ABC language and didn't like it there. Speed and memory consumption were unpredictable for non-experts, and could vary wildly (factors of 1000s) for a fixed algorithm, depending on the inputs. Rationals aren't a cure-all, and the instant you throw a sqrt or transcendental into the mix you're back to some form of fp anyway.
> but float is just ugly. It is turning exact values (integers) into > approximate ones (float) when I didn't tell it to.
If the language defines "/" as returning a float, then you told it to. You *almost* may as well complain that math.sqrt(2) turns an exact value into an approximate one; but, e.g., when I use Macsyma, it doesn't lose information there either. Python isn't going to do symbolic computation by default, so the question isn't whether to compromise, but where.
> It's almost as bad as if integer subtraction always truncated to 16 > bit values -- a lot of the time that would give sort of reasonable > answers but it's a gratuitous approximation where you didn't expect > one.
You don't expect an approximation in that context because Python promises not to make one in that context. If you expect things a language doesn't promise, that's not really the language's fault <wink>.
> This has probably already been brought up, but perhaps the problem lies > not with the "/" operator, but one step earlier in distinguishing the > meaning of:
> x = 3 > and > x = 3.
> That is subtle difference that can cause quite different results later > on.
Why is that? It's because unlike any other builtin arithmetic operation, "/" today can cause *catastrophic* loss of information silently, and in ordinary cases. If code sticks to + - * and **, it usually doesn't matter much in the end whether someone says
x = 3 or x = 3.
at the start. But toss in one "/", and radically different results are common.
> Or, one may try to teach that when ALL arguments of an operator are in > one "set", such as the set of integers, then one must expect a result > that is an element from THAT set, not another set, such as the set of > real numbers or from the set of complex numbers. Set theory seems to > be taught fairly early on in math, I think.
I think you're missing that the proponents are arguing on pragmatic grounds: this has mostly to do with that x/y surprises people in real life. It's not that there aren't clear rules, or that the rules can't be taught, or that people are too stupid to understand the rules. Guido hears all the complaints, and he's become convinced that this is a genuine and serious flaw in the language: the current rules are *unusable* for too many people too often. If you're not one of them, congratulations <wink>. I'm not either -- I never get burned by this. But I see plenty of people who are, and they're neither stupid nor careless; it's a common blind spot, so it doesn't really matter that it's not one I (or you) suffer.
> ... > I prefer a handful of general rules, and operators that obey them.
Of course, but computer numerics is a massive exercise in picking the general rules you want to preserve at the expense of others, and trading all that off against pragmatics too. Not losing information silently is also a Very Good General Rule, and even 745 binary fp arithmetic is better at meeting that one than current "/".
On Sun, 22 Jul 2001 14:22:21 -0400, "Tim Peters" <tim....@home.com> wrote: >[Arthur_Sie...@rsmi.com] >> ... >> If I was told that experinced programmers might >> appreciate this change for any possible reason - >> I'd be quiet as a mouse.
I'd call myself experienced, though not yet with Python (though I fancy my other experience gives me a leg up on most Python newbies).
I am generally so adaptable it's almost a problem, so I'll have no big problem with '//' after I accept that this is Rome, and I should do as the Romans do. It's certainly not going to put me off Python ;-)
>Not all experienced programmers agree. At the last Python Conference, I >moderated a 40-some person group discussion on conceivable changes to >Python's numeric model, not advocating but keeping the participants from >killing each other <wink>. The meaning of integer division wasn't the >focus, but naturally came up. By show of hands, about 3/4ths of the >participants agreed that 3/4 should not return 0, but rather *something* x >such that x*4 had a better chance of being confused with 3 than with 0. >There was no consensus on exactly what 3/4 should return -- rational or HW >float or decimal float were the most popular alternatives.
>It shouldn't be so hard to understand why. The current integer division >loses information silently and without a trace. Combined with that Python
The thing is, current floating point operations also (sometimes, not always, just as with integer ops) lose "information silently and without a trace." Just less noticeably, for the most part, if you sanitize output.
Which leads me to wondering if exactness would be a more approachable concept for CP4E than details of numeric representation alternatives.
For many 'float' is about as relevant to their desired computing experience as 'hypoid' is to their commuting experience. Why not keep both hidden under the hood (without welding it shut, of course) ?
>is not a statically typed language, there's simply no telling what e.g.
>def velocity(distance, time): > return distance / time
>will compute by inspection. This isn't about esoteric user overloading of >"/", it's about ordinary arithmetic on builtin numeric types, and many >experienced Python programmers have testified over the years to being burned >in practice by stuff exactly that simple.
I believe you. BTW, is there an efficient type assertion that doesn't go away with optimization, that one could use to refuse wrong-type arguments?
>I expect that either way is easy enough to *teach*, but I don't accept ease >of teaching as a primary goal: I'm much keener on semantics that, once
Glad to hear that. <rant>Worst IMHO is when teachers teach what is actually wrong to children or the otherwise innocently ignorant, with the rationale that the real truth is too complicated, and even letting on that there is a real truth will just be confusing. That not letting on part is the real evil. Of course, many teachers are themselves the product of this methodology, and pass it on unawares.</rant>
I wonder what K-12 teachers will say about Python float ;-/ Maybe there should be guidelines for teaching what is not understood, so that bright kids don't get cynical too fast.
>*learned*, are hard to forget or to stumble over. Even if such semantics >are 100x harder to teach at first, fine by me: you spend the rest of your >life living with the consequences. I wish the definition of continuity were >easier to teach too, but that doesn't mean I'll settle for an easier >definition that doesn't actually work <wink>.
On Sun, 22 Jul 2001 17:40:10 GMT, Rainy <s...@optonline.net> wrote: >First of all, it's really ugly. It's the ugliest thing in python for a newbie, >imho. Yes, 1/2 is 0. You have to type 1.0/2 to get 0.5. No, there is no good >reason for that, just memorize it. Ugh.
There _is_ a good reason. 1 and 2 are integers. How many 2s can you fit into a 1?
None.
Zero.
-- Grant Edwards grante Yow! Can you MAIL a BEAN at CAKE? visi.com
On Sun, 22 Jul 2001 14:22:21 -0400, Tim Peters <tim....@home.com> wrote: >It shouldn't be so hard to understand why. The current integer division >loses information silently and without a trace.
No, it doesn't. Integer division is integer division. The correct answer for the value of 3/4 is 0. If you wanted the remainder, you should ask for it. If you want to divide floating point numbers, you should _use_ floating point numbers.
Perhaps my mind was warped by using nothing but integer arithmatic in my software for many years because floating point was simply too slow and too expensive.
-- Grant Edwards grante Yow! Are we THERE yet? My at MIND is a SUBMARINE!! visi.com
Unlike, say, the participants in this discussion? Hmm. You set a rather high standard here, Martijn <wink>.
? they were people with an interest in numeric models.
Or uninterested in Stackless (its "competition" in that time slot). I suppose the next time we want advice about Unicode, we should just ask Americans.
> Did Guido ask for a show of hands in the big session afterwards?
No, not on this issue.
> I don't recall; I kind of suspect the outcome would've been different.
I actually think 1/2==0 bothers "the general" population more than those with a keen interest in numerics. Indeed, nobody with a keen interest in numerics has bugged Guido about this except Moshe, that I know of; the most visible repeated pressures have come from educators using Python as a means to some other end.
>> The current integer division loses information silently and without a >> trace combined with that Python is not a statically typed language, >> there's simply no telling what e.g.
>> def velocity(distance, time): >> return distance / time
>> will compute by inspection. > There's no telling what:
> def add_stuff(a, b): > return a + b
> will compute by inspection either, though.
You chopped all my following text, saying that the velocity() example wasn't about user-defined overloadings but about ordinary arithmetic on the builtin numeric types. A user trying e.g. velocity(3, 2) is simply going to be surprised -- as countless newbies have testified on c.l.py over the years.
> ... > For working with pixels in GUIs and such, integer division can be a > useful thing, though.
It can be useful for many things; that's not at issue, and nobody has ever proposed taking away the ability to get an integer result; the issue is how to spell that.
In article <mailman.995839419.19134.python-l...@python.org>, "Tim Peters" <tim....@home.com> wrote:
> A user trying e.g. velocity(3, 2) is simply going to be > surprised -- as countless newbies have testified on c.l.py over the years.
My intuition is that the users who will be surprised that 1/2 = 0 are the same ones who would be bitten by roundoff-error bugs if 1/2 = 0.5. Result: buggier code since the errors are less obvious.
If you have a routine "velocity" in which it doesn't make sense to do integer truncation, and it doesn't coerce its args to float by adding 0.0, that's also a bug. -- David Eppstein UC Irvine Dept. of Information & Computer Science eppst...@ics.uci.edu http://www.ics.uci.edu/~eppstein/
Tim Peters wrote: > Guido hears all the > complaints, and he's become convinced that this is a genuine and serious > flaw in the language: the current rules are *unusable* for too many people > too often. If you're not one of them, congratulations <wink>. I'm not > either -- I never get burned by this. But I see plenty of people who are, > and they're neither stupid nor careless; it's a common blind spot, so it > doesn't really matter that it's not one I (or you) suffer.
Well, having learned one set of expectations, I can say that I WILL suffer some pain if this is changed. And it isn't a case of an expectation carried over from another language!
Speaking of patterns, it unfortunately appears that Guido has a strong tendency to take the existing user base for granted, since he continues to keep the door open to code-breaking changes. There is only so much insult ("well, what you were doing was bad style anyway," or "you shouldn't have written code that depends on integer division(!)") and injury (the more Python you've written, the more likely something you wrote wont work with the latest version and will need to spend hours reviewing, just-in-case-anyway) before one decides that it just isn't worth the pain.
I do not want to continue to write more Python and expose myself to further risk of having it either become dependent on an un-maintained and minority release (e.g. "sorry, you should have upgraded to 3.1 years ago; who writes stuff on 2.1 these days anyway?") or having a growing body of code to constantly shepherd along to insure it runs on the next release.
That is the pragmatics from my point of view. And it doesn't give a damn what real or perceived "flaw" in the language is being addressed.
