On Tue, 19 Sep 2017 12:31 am, Ben Bacarisse wrote: > Was the result of 1/2 determined > by a poll to find out what most people expected?
No. It was determined by the fact that a decade or more of experience with the language demonstrated that the Python 2 behaviour was a terrible mistake and a continual source of bugs in code because the / operator would silently change its function and return garbage results depending on the precise type of the numeric arguments. I specify *numeric* arguments because I don't want people derailing this in a general rant about operator overloading. I'm not talking about "if you pass a Widget instead of a float, you get an unexpected different Widget". Rather, I am talking about "if you pass 2 instead of 2.0, you get an answer of 34.72 instead of the correct answer of 35.47" kinds of errors. Silent failures that return garbage results. A simple (if perhaps artificial) example: harmonic mean. >>> 1/sum(1/x for x in [1.0, 2.0, 5.5, 3.2, 4.0]) # Correct. 0.4455696202531646 >>> 1/sum(1/x for x in [1.0, 2, 5.5, 3.2, 4.0]) # Oops. 0.57328990228013033 > But there is a stronger claim (which I think you also made) that a > floating point result is the correct one. However, some people with > little experience of floating point arithmetic (I certainly can't say > most but it must be quite few) will expect > > 1/10 > > to return a tenth. For /them/, the floating point result is silently > wrong and a source of bugs. It does return a tenth, or rather the closest possible result to a tenth representable. It is true that binary floats have some unexpected properties. They aren't the real numbers that we learn in maths. But most people who have been to school have years of experience with calculators training them to expect computer calculations are sometimes "off". They do a sum and get 2.999999999 instead of 3, or perhaps 3.000000001, and that's just the way calculators work. And then a small but vocal minority get a bit more experience with computers and forget what they had already learned and make the novice mistake of expecting floats to be infinitely precise real numbers, then complain that "Python is inaccurate" on the bug tracker. Of course they don't bother to do even a cursory search before raising an issue, or read the documentation, or the FAQs, or do the tutorial. > If I were aiming a language at beginners, > I'd make 1/10 be a rational or a type error. You would make it a type error? Why, do you hate beginners and want to punish them for typing to learn your language? Fortunately Python is not a language that is purely aimed at beginners. Python doesn't go out of its way to be hostile to anyone, let alone beginners, but it doesn't compromise or stint on functionality just so that novices to programming have a microscopically easier first week. > However, I don't think that is Python's main demographic, so 1/10 giving > something not quite one tenth may well be the correct design choice. Indeed. There are three obvious choices for regular division of integers. All have disadvantages: - Return a binary float. This has the advantage that it is the most common, and the fastest, and that computationally binary floats have the smallest "wobble" of any numeric base. If you are serious about floating point accuracy and stability, you probably want binary floats. But like all floating point formats, it has the disadvantages that many calculations can suffer from rounding errors, and that certain "ordinary looking" decimal values, like 0.1, cannot be represented exactly. - Return a decimal float. This has the advantage that "ordinary looking" values like 0.1 can be represented exactly, but otherwise is subject to precisely the same rounding errors as binary floats, plus the additional problem that the errors can be significantly larger, leading to even more numeric instability. And just like binary, there are still ordinary fractions which cannot be expressed exactly, like 1/3. - Return an exact rational number, a fraction. While these are exact, this has the disadvantage that fractions are not as practical as decimals for humans. Rational arithmetic is also much slower than floating point, and that many perfectly innocent-looking calculations can explode into ridiculously huge numbers of digits, leading to excessive memory use and even more performance degradation. Guido strongly dislikes the rational option because of his experience with ABC, where simple-looking calculations would often grind to a halt as they calculated fractions with millions or billions of digits in the numerators and denominators, for numbers which were well within the range of a float. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
