Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #73610

Re: python 3.44 float addition bug?

Show all headers | View raw

On Thu, 26 Jun 2014 13:39:23 +1000, Ben Finney wrote:

> Steven D'Aprano <steve@pearwood.info> writes:
> 
>> On Wed, 25 Jun 2014 14:12:31 -0700, Maciej Dziardziel wrote:
>>
>> > Floating points values use finite amount of memory, and cannot
>> > accurately represent infinite amount of numbers, they are only
>> > approximations. This is limitation of float type and applies to any
>> > languages that uses types supported directly by cpu. To deal with it
>> > you can either use decimal.Decimal type that operates using decimal
>> > system and saves you from such surprises
>>
>> That's a myth. decimal.Decimal *is* a floating point value
> 
> That's misleading: Decimal uses *a* floating-point representation, but
> not the one commonly referred to. That is, Decimal does not use IEEE-754
> floating point.

You're technically correct, but only by accident.

IEEE-754 covers both binary and decimal floating point numbers:

http://en.wikipedia.org/wiki/IEEE_floating_point


but Python's decimal module is based on IEEE-854, not 754.

http://en.wikipedia.org/wiki/IEEE_854-1987

So you're right on a technicality, but wrong in the sense of knowing what 
you're talking about *wink*


>> and is subject to *exactly* the same surprises as binary floats,
> 
> Since those “surprises” are the ones inherent to *decimal*, not binary,
> floating point, I'd say it's also misleading to refer to them as
> “exactly the same surprises”. They're barely surprises at all, to
> someone raised on decimal notation.

Not at all. They are surprises to people who are used to *mathematics*, 
fractions, rational numbers, the real numbers, etc. It is surprising that 
the rational number "one third" added together three times should fail to 
equal one. Ironically, binary float gets this one right:

py> 1/3 + 1/3 + 1/3 == 1
True
py> Decimal(1)/3 + Decimal(1)/3 + Decimal(1)/3 == 1
False


but for other rationals, that is not necessarily the case.

It is surprising when x*(y+z) fails to equal x*y + x*z, but that can 
occur with both binary floats and Decimals.

It is surprising when (x + y) + z fails to equal x + (y + z), but that 
can occur with both binary floats and Decimals.

It is surprising when x != 0 and y != 0 but x*y == 0, but that too can 
occur with both binary floats and Decimals. 

And likewise for most other properties of the rationals and reals, which 
people learn in school, or come to intuitively expect. People are 
surprised when floating-point arithmetic fails to obey the rules of 
mathematical arithmetic.

If anyone is aware of a category of surprise which binary floats are 
prone to, but Decimal floats are not, apart from the decimal-
representation issue I've already mentioned, I'd love to hear of it. But 
I doubt such a thing exists.

Decimal in the Python standard library has another advantage, it supports 
user-configurable precisions. But that doesn't avoid any category of 
surprise, it just mitigates against being surprised as often.


> This makes the Decimal functionality starkly different from the built-in
> ‘float’ type, and it *does* save you from the rather-more-surprising
> behaviour of the ‘float’ type. This is not mythical.

It simply is not true that Decimal avoids the floating point issues that 
"What Every Computer Scientist Needs To Know About Floating Point" warns 
about:

http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

It *cannot* avoid them, because Decimal is itself a floating point 
format, it is not an infinite precision number type like 
fractions.Fraction.

Since Decimal cannot avoid these issues, all we can do is push the 
surprises around, and hope to have less of them, or shift them to parts 
of the calculation we don't care about. (Good luck with that.) Decimal, 
by default, uses 28 decimal digits of precision, about 11 or 12 more 
digits than Python floats are able to provide. So right away, by shifting 
to Decimal you gain precision and hence might expect fewer surprises, all 
else being equal.

But all else isn't equal. The larger the base, the larger the "wobble". 
See Goldberg above for the definition of wobble, but it's a bad thing. 
Binary floats have the smallest wobble, which is to their advantage.

If you stick to trivial calculations using nothing but trivially "neat" 
decimal numbers, like 0.1, you may never notice that Decimal is subject 
to the same problems as float (only worse, in some ways -- Decimal 
calculations can fail in some spectacularly horrid ways that binary 
floats cannot). But as soon as you start doing arbitrary calculations, 
particularly if they involve divisions and square roots, things are no 
longer as neat and tidy.

Here's an error that *cannot* occur with binary floats: the average of 
two numbers x and y is not guaranteed to lie between x and y!


py> from decimal import *
py> getcontext().prec = 3
py> x = Decimal('0.516')
py> y = Decimal('0.518')
py> (x + y) / 2
Decimal('0.515')


Ouch!



-- 
Steven

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

python 3.44 float addition bug? FraserL <fraser.long+usenet@NOSPAMgmail.com> - 2014-06-20 19:57 -0500
  Re: python 3.44 float addition bug? FraserL <fraser.long+usenet@gmail.com> - 2014-06-20 20:11 -0500
    Re: python 3.44 float addition bug? Gary Herron <gary.herron@islandtraining.com> - 2014-06-20 18:19 -0700
  Re: python 3.44 float addition bug? Gary Herron <gary.herron@islandtraining.com> - 2014-06-20 18:07 -0700
  Re: python 3.44 float addition bug? Chris Angelico <rosuav@gmail.com> - 2014-06-21 11:33 +1000
  Re: python 3.44 float addition bug? INADA Naoki <songofacandy@gmail.com> - 2014-06-21 10:06 +0900
  Re: python 3.44 float addition bug? Grant Edwards <invalid@invalid.invalid> - 2014-06-21 14:25 +0000
  Re: python 3.44 float addition bug? Ned Deily <nad@acm.org> - 2014-06-21 12:24 -0700
    Re: python 3.44 float addition bug? buck <workitharder@gmail.com> - 2014-06-23 17:55 -0700
      Re: python 3.44 float addition bug? Chris Angelico <rosuav@gmail.com> - 2014-06-24 13:26 +1000
      Re: python 3.44 float addition bug? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-24 17:30 +1200
      Re: python 3.44 float addition bug? Steven D'Aprano <steve@pearwood.info> - 2014-06-24 06:34 +0000
  Re: python 3.44 float addition bug? Maciej Dziardziel <fiedzia@gmail.com> - 2014-06-25 14:12 -0700
    Re: python 3.44 float addition bug? Steven D'Aprano <steve@pearwood.info> - 2014-06-26 02:56 +0000
      Re: python 3.44 float addition bug? Chris Angelico <rosuav@gmail.com> - 2014-06-26 13:13 +1000
        Re: python 3.44 float addition bug? Steven D'Aprano <steve@pearwood.info> - 2014-06-26 04:17 +0000
          Re: python 3.44 float addition bug? Chris Angelico <rosuav@gmail.com> - 2014-06-26 14:41 +1000
      Re: python 3.44 float addition bug? Ben Finney <ben@benfinney.id.au> - 2014-06-26 13:39 +1000
        Re: python 3.44 float addition bug? Steven D'Aprano <steve@pearwood.info> - 2014-06-26 09:15 +0000
          Re: python 3.44 float addition bug? Chris Angelico <rosuav@gmail.com> - 2014-06-26 19:38 +1000
            Re: python 3.44 float addition bug? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-27 02:51 +0000
              Re: python 3.44 float addition bug? Chris Angelico <rosuav@gmail.com> - 2014-06-27 13:24 +1000
              Re: python 3.44 float addition bug? Ian Kelly <ian.g.kelly@gmail.com> - 2014-06-27 10:18 -0600
      Re: python 3.44 float addition bug? Stefan Behnel <stefan_ml@behnel.de> - 2014-06-26 07:53 +0200

csiph-web