[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Tue, Sep 19, 2017 at 5:07 PM, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote: > 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+python at 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?") Sounds like you want a display formatting feature. I wonder how Python code would display a number... >>> f = fractions.Fraction(2271, 400) >>> "$%.2f" % f '$5.68' Looks like money to me. > 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. Yeah, logarithms would have to be defined to return floats. Fortunately, the math module seems pretty happy to accept fractions: >>> math.log(f) 1.7365109949975766 >>> math.sin(f) -0.5693256092491197 >>> math.sqrt(f) 2.382750511488771 >> 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. Aside from the backward compatibility concerns (which mean that this can't be done in a language that calls itself "Python"), I'm not seeing any reason that a human-friendly language can't spend most of its time working with arbitrary-precision rationals, only switching to floats when (a) the programmer explicitly requests it, or (b) when performing operations that fundamentally cannot be performed with rationals. ChrisA

- Prev by Date:
**[Tutor] beginning to code** - Next by Date:
**Stdlib, what's in, what's out** - Previous by thread:
**Old Man Yells At Cloud** - Next by thread:
**Old Man Yells At Cloud** - Index(es):