On Tue, Sep 19, 2017 at 5:07 PM, Steven D'Aprano
<steve+comp.lang.pyt...@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+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?")
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
--
https://mail.python.org/mailman/listinfo/python-list
