On Tue, 19 Sep 2017 03:23:15 +0000, Dan Sommers wrote: > On Tue, 19 Sep 2017 01:56:29 +0000, Stefan Ram wrote: > >> Steve D'Aprano <steve+pyt...@pearwood.info> writes: > >>>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. > >> It is possible that many calculators use base 10 and therefore such >> surprises might be less common than in the world of programming >> languages. > > How relevant is the "people use calculators to do arithmetic" argument > today? Okay, so I'm old and cynical, but I know [young] people who > don't (can't?) calculate a gratuity without an app or a web page.
Which is a form of calculator. People still learn to use calculators at school, they still use them at work. They use Excel, which is prone to the same issue. Calculating 15% of $37.85 returns 5.6775 in both Python and on my cheap four-function calculator, and I'm sure my phone would give the same answer. 5.6775 is a much more useful answer than Fraction(2271, 400). ("What's that in real money?") > FWIW, I would prefer that 1/10 be a rational because rationals are exact > when the operands are. Rounding could easily fall under "In the face of > ambiguity, refuse to guess." Perhaps if you didn't understand how numbers are rounded and thought it was a guess. There's nothing ambiguous in correct rounding. IEEE-754 arithmetic is correctly rounded: the operations of addition, subtraction, multiplication, division, and square root are correctly rounded for every combination of float arguments. Assuming your platform provides properly compliant IEEE-754 arithmetic. Things are not as bad as they used to be in the Bad Old Days when computers couldn't even agree on what *zero* was, but there's still room for improvement. Ironically, your comment about ambiguity would be reasonable for, say, trig functions, logarithms, and the like. But in those cases, calculating the exact answer as a rational is usually impossible. Even something as simple as log(2) would require an infinite amount of memory, and infinite time, to express exactly as a fraction. > Yes, every once in a while, I get a result > with lots of digits, but that's usually while I'm developing an > algorithm, and then I can decide whether or not and when to coerce the > result to floating point. I guess that you must have pretty simple algorithms then. No square roots, no trig, no exponentiation except for positive integer powers, little or no iteration. Outside of some pretty specialised fields, there's a reason why the numeric community has standardised on floating point maths. -- Steven D'Aprano “You are deluded if you think software engineers who can't write operating systems or applications without security holes, can write virtualization layers without security holes.” —Theo de Raadt -- https://mail.python.org/mailman/listinfo/python-list