Re: python 3.44 float addition bug?

```On Thu, Jun 26, 2014 at 9:24 PM, Chris Angelico ros...@gmail.com wrote:
But you're right that this can be very surprising. And it's inherent
to the concept of digits having more range than just high or low,
so there's no way you can get this with binary floats.

For an average of two numbers, I think that's true.  For an average of
more than two numbers, it's possible.

a = 2.0 ** 53 - 1
b = 2.0 ** 53 - 2
a
9007199254740991.0
b
9007199254740990.0
(a + b + b) / 3
9007199254740989.0
--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

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

Steven D'Aprano st...@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

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

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
--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```On Thu, Jun 26, 2014 at 7:15 PM, Steven D'Aprano st...@pearwood.info wrote:
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!

But what you're looking at is also a problem with intermediate
rounding, as the sum of .516 and .518 can't be represented in 3
digits. One rule of thumb that I learned back in my earliest coding
days was that your intermediate steps should have significantly more
precision than your end result; so if you want an end result with a
certain precision (say, 3 decimal digits), you should calculate with a
bit more. Of course, a bit is nearly impossible to define [1], but
if you're mostly adding and subtracting, or multiplying by smallish
constants, 1-2 extra digits' worth of precision is generally enough.
Or just give yourself lots of room, like using double-precision for
something like the above example. Compare this:

from decimal import *
getcontext().prec = 4
x = Decimal('0.516')
y = Decimal('0.519')
avg = (x + y) / 2
getcontext().prec = 3
avg + 0
Decimal('0.518')
(x + y) / 2
Decimal('0.52')

Doing the intermediate calculation with precision 3 exhibits the same
oddity Steven mentioned (only the other way around - result is too
high), but having a little extra room in the middle means the result
is as close to the correct answer as can be represented (0.517 would
be equally correct). With floating point on an 80x87, you can do this
with 80-bit FPU registers; I don't know of a way to do so with Python
floats, but (obviously) it's pretty easy with Decimal.

ChrisA

[1] Thank you, smart-aleck up the back, I am fully aware that a bit
is exactly one binary digit. That's not enough for a decimal float.
--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```On Thu, 26 Jun 2014 19:38:45 +1000, Chris Angelico wrote:

On Thu, Jun 26, 2014 at 7:15 PM, Steven D'Aprano st...@pearwood.info
wrote:
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!

But what you're looking at is also a problem with intermediate rounding,
as the sum of .516 and .518 can't be represented in 3 digits.

Exactly. I picked 3 digits because it's much easier to write, and read, a
3 digit example than a 28 digit example. But the failure here is not a
property of too few digits, to be fixed by adding more significant
digits. No matter how many digits you have, there are some calculations
which cannot be performed exactly in that many digits.

Although you seem to have missed the critical issue: this is a failure
mode which *binary floats cannot exhibit*, but decimal floats can. The
failure being that

assert x = (x+y)/2 = y

may fail if x and y are base 10 floats.

I'm afraid my computational-mathematics skills are not good enough to
prove this assertion, but Mark Dickinson on the Python-Dev mailing list
made this claim, and I believe he knows what he is talking about.

https://mail.python.org/pipermail/python-ideas/2014-March/026851.html

If anyone can demonstrate such a failed assertion using floats, I'd love
to see it.

--
Steven
--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```On Fri, Jun 27, 2014 at 12:51 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
Although you seem to have missed the critical issue: this is a failure
mode which *binary floats cannot exhibit*, but decimal floats can. The
failure being that

assert x = (x+y)/2 = y

may fail if x and y are base 10 floats.

No, I didn't miss that; I said that what you were looking at was
*also* caused by intermediate rounding. It happens because .516 + .518
= 1.034, which rounds to 1.03; half of that is .515, which is outside
of your original range - but the intermediate rounding really reduced
the effective precision to two digits, by discarding some of the
information in the original. If you accept that your result is now
accurate to only two digits of precision, then that result is within
one ULP of correct (you'll record the average as either .51 or .52,
and your two original inputs are both .52, and the average of .52 and
.52 is clearly .52).

But you're right that this can be very surprising. And it's inherent
to the concept of digits having more range than just high or low,
so there's no way you can get this with binary floats.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```On Saturday, June 21, 2014 1:57:19 AM UTC+1, FraserL wrote:
I'm not hugely accustomed to Python, but this seems crazy to me.

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 (but it will be much slower
and incompatible with c code that doesn't handle decimals or converts them to
floats) or use epsilon for every comparison and rounding/formatting with
limited   precision for displaying.

Few more details are here: http://floating-point-gui.de/errors/comparison/
--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```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, and is
subject to *exactly* the same surprises as binary floats, except for one:
which Decimal, you can guarantee that any decimal string you enter will
appear exactly the same (up to the limit of the current precision).

For example:

py x = Decimal(1)/Decimal(23)
py x
Decimal('0.04347826086956521739130434783')
py x*23 == 1
True
py sum( [x]*23 ) == 1  # Surprise!
False

py (Decimal(19)/Decimal(17))*Decimal(17) == 19  # Surprise!
False

--
Steven
--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```On Thu, Jun 26, 2014 at 12:56 PM, Steven D'Aprano st...@pearwood.info wrote:
That's a myth. decimal.Decimal *is* a floating point value, and is
subject to *exactly* the same surprises as binary floats, except for one:
which Decimal, you can guarantee that any decimal string you enter will
appear exactly the same (up to the limit of the current precision).

The important difference is that the issues with decimal floats come
where humans are comfortable seeing them. If you divide 1 by 3, you
get 0.3 and can understand that adding three of those together
won't quite make 1.0, because you can see that you shortened it. If
you divide 11 by 10, it's not obvious that that repeats.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```Steven D'Aprano st...@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.

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.

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.

--
\ “Guaranteed to work throughout its useful life.” —packaging for |
`\  clockwork toy, Hong Kong |
_o__)  |
Ben Finney

--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```On Thu, 26 Jun 2014 13:13:45 +1000, Chris Angelico wrote:

On Thu, Jun 26, 2014 at 12:56 PM, Steven D'Aprano st...@pearwood.info
wrote:
That's a myth. decimal.Decimal *is* a floating point value, and is
subject to *exactly* the same surprises as binary floats, except for
one: which Decimal, you can guarantee that any decimal string you enter
will appear exactly the same (up to the limit of the current
precision).

The important difference is that the issues with decimal floats come
where humans are comfortable seeing them. If you divide 1 by 3, you get
0.3 and can understand that adding three of those together won't
quite make 1.0, because you can see that you shortened it. If you divide
11 by 10, it's not obvious that that repeats.

I'm not sure if you're agreeing with me or disagreeing with me.

Repeats is a property of a number *in a specific base*, not of the
number itself. So 1/3 does not repeat in base 3, where it would be
written as the terminating trinary number 0.1. Likewise, 11/10 repeats in
base 2, but not in base 10.

What I am I saying is that regardless of whether you use binary floats or
base-10 Decimals, not all rational numbers x/y can be represented
exactly. I certainly wasn't saying that the same rationals are inexact in
both bases, just that the surprise x/y is not exact occurs whether you
have binary or decimal floating point numbers.

Likewise for all other floating point issues, except the surprise this
base-2 float is not exactly equal to the base-10 number I typed. Because
Decimal is base-10, what you type is what you get.

--
Steven
--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```On Thu, Jun 26, 2014 at 2:17 PM, Steven D'Aprano st...@pearwood.info wrote:
I'm not sure if you're agreeing with me or disagreeing with me.

Repeats is a property of a number *in a specific base*, not of the
number itself. So 1/3 does not repeat in base 3, where it would be
written as the terminating trinary number 0.1. Likewise, 11/10 repeats in
base 2, but not in base 10.

What I am I saying is that regardless of whether you use binary floats or
base-10 Decimals, not all rational numbers x/y can be represented
exactly. I certainly wasn't saying that the same rationals are inexact in
both bases, just that the surprise x/y is not exact occurs whether you
have binary or decimal floating point numbers.

Likewise for all other floating point issues, except the surprise this
base-2 float is not exactly equal to the base-10 number I typed. Because
Decimal is base-10, what you type is what you get.

Broadly agreeing, but with the caveat that, as you say, repeats
depends on the base - and there's one base that most humans use, and
it's not the base that IEEE floats use. So when I said that 11/10
repeats, I mean that it repeats in binary, which causes precision
problems with binary floats; but everyone who's done basic work with
vulgar and decimal fractions understands that 1/3 can't be perfectly
represented in decimal.

So the problems with floating point representations are indeed common
to float and decimal.Decimal, but they're more surprising with float
because humans aren't used to tenths repeating.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```Steven D'Aprano, 26.06.2014 04:56:
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, and is
subject to *exactly* the same surprises as binary floats, except for one:
which Decimal, you can guarantee that any decimal string you enter will
appear exactly the same (up to the limit of the current precision).

For example:

py x = Decimal(1)/Decimal(23)
py x
Decimal('0.04347826086956521739130434783')
py x*23 == 1
True
py sum( [x]*23 ) == 1  # Surprise!
False

py (Decimal(19)/Decimal(17))*Decimal(17) == 19  # Surprise!
False

It seems that no-one has mentioned the fractions module in this thread
yet. It gives you rational numbers (enumerator/denominator), as supposed to
the limited real numbers that floating point numbers represent.

https://docs.python.org/3/library/fractions.html

There are quite a number of use cases for exact calculations where rational
numbers beat any other solution. For the cases above, for example, you'd
get exact results by design. Or in currency calculations, where you want to
move the rounding to the very end and prevent any loss of precision along
the way (unless you're trying to tweak your account in the right direction,
that is).

Stefan

--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```On Mon, 23 Jun 2014 17:55:50 -0700, buck wrote:

It used to be that the best way to compare floating point numbers while
disregarding the inherent epsilon was to use `str(x) == str(y)`. It
looks like that workaround doesn't work anymore in 3.4.

What inherent epsilon? Can you explain what you mean?

What's the recommended way to do this now?

format(.01 + .01 + .01 + .01 + .01 + .01, 'g') == format(.06, 'g')
True

That's equivalent to doing an implicit round. If all you want to do is
round your calculations, then explicitly round them:

py x = sum([0.01]*6)
py y = 0.06
py round(x, 12) == round(y, 12)
True

Not that I'm recommending that you do it this way, but an explicit round
is better than using string formatting.

http://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/

--
Steven
--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```It used to be that the best way to compare floating point numbers while
disregarding the inherent epsilon was to use `str(x) == str(y)`. It looks like
that workaround doesn't work anymore in 3.4.

What's the recommended way to do this now?

format(.01 + .01 + .01 + .01 + .01 + .01, 'g') == format(.06, 'g')
True

On Saturday, June 21, 2014 12:24:24 PM UTC-7, Ned Deily wrote:
In article

captjjmrkpd5k__h9qg12q+arafzvan6egudtmedge2ccaqe...@mail.gmail.com,

Chris Angelico ros...@gmail.com wrote:

Also, when you're looking at how things print out, consider looking at

two things: the str() and the repr(). Sometimes just print(p)

doesn't give you all the info, so you might instead want to write your

loop thus:

z = 0.01

p = 0.0

for i in range(19):

p += z

print(str(p) +  --  + repr(p))

Sometimes you can get extra clues that way, although in this instance

I think you won't.

Actually, I think this is one case where you would get extra clues (or

extra headscratching) if you run the code with various releases of

Python.

\$ python2.6 b.py

0.01 -- 0.01

0.02 -- 0.02

0.03 -- 0.02

0.04 -- 0.040001

0.05 -- 0.050003

0.06 -- 0.060005

0.07 -- 0.070007

0.08 -- 0.080002

0.09 -- 0.089997

0.1 -- 0.02

0.11 -- 0.10999

0.12 -- 0.11998

0.13 -- 0.12998

0.14 -- 0.13999

0.15 -- 0.14999

0.16 -- 0.16

0.17 -- 0.17001

0.18 -- 0.18002

0.19 -- 0.19003

\$ python2.7 b.py

0.01 -- 0.01

0.02 -- 0.02

0.03 -- 0.03

0.04 -- 0.04

0.05 -- 0.05

0.06 -- 0.060005

0.07 -- 0.07

0.08 -- 0.08

0.09 -- 0.09

0.1 -- 0.0

0.11 -- 0.10999

0.12 -- 0.11998

0.13 -- 0.12998

0.14 -- 0.13999

0.15 -- 0.15

0.16 -- 0.16

0.17 -- 0.17

0.18 -- 0.18002

0.19 -- 0.19003

\$ python3.4 b.py

0.01 -- 0.01

0.02 -- 0.02

0.03 -- 0.03

0.04 -- 0.04

0.05 -- 0.05

0.060005 -- 0.060005

0.07 -- 0.07

0.08 -- 0.08

0.09 -- 0.09

0.0 -- 0.0

0.10999 -- 0.10999

0.11998 -- 0.11998

0.12998 -- 0.12998

0.13999 -- 0.13999

0.15 -- 0.15

0.16 -- 0.16

0.17 -- 0.17

0.18002 -- 0.18002

0.19003 -- 0.19003

What's going on here is that in Python 2.7 the repr() of floats was

changed to use the minimum number of digits to accurately roundtrip the

number under correct rounding.  For compatibility reasons, the str()

representation was not changed for 2.7.  But in Python 3.2, str() was

changed to be identical to repr() for floats.  It's important to keep in

mind that the actual binary values stored in float objects are the same

across all of these releases; only the representation of them as decimal

characters varies.

https://docs.python.org/2.7/whatsnew/2.7.html#other-language-changes

http://bugs.python.org/issue9337

--

Ned Deily,

n...@acm.org
--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```On Tue, Jun 24, 2014 at 10:55 AM, buck workithar...@gmail.com wrote:
It used to be that the best way to compare floating point numbers while
disregarding the inherent epsilon was to use `str(x) == str(y)`.

Who said that?

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```
buck wrote:

What's the recommended way to do this now?

format(.01 + .01 + .01 + .01 + .01 + .01, 'g') == format(.06, 'g')

There's no recommended way. What you're asking for can't be
done. Whatever trick you come up with, there will be cases
where it doesn't work.

Why do you think you want to compare floats for equality?
The best thing to do will depend on the answer to that.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```On 2014-06-21, FraserL fraser.long+use...@nospamgmail.com wrote:

I'm not hugely accustomed to Python, but this seems crazy to me.

Both are producing the same floating point numbers, Python just
changed the way they're printed.  One version doesn't show you all the
digits, the other does.

--
Grant

--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```In article
captjjmrkpd5k__h9qg12q+arafzvan6egudtmedge2ccaqe...@mail.gmail.com,
Chris Angelico ros...@gmail.com wrote:
Also, when you're looking at how things print out, consider looking at
two things: the str() and the repr(). Sometimes just print(p)
doesn't give you all the info, so you might instead want to write your
loop thus:

z = 0.01
p = 0.0
for i in range(19):
p += z
print(str(p) +  --  + repr(p))
Sometimes you can get extra clues that way, although in this instance
I think you won't.

Actually, I think this is one case where you would get extra clues (or
extra headscratching) if you run the code with various releases of
Python.

\$ python2.6 b.py
0.01 -- 0.01
0.02 -- 0.02
0.03 -- 0.02
0.04 -- 0.040001
0.05 -- 0.050003
0.06 -- 0.060005
0.07 -- 0.070007
0.08 -- 0.080002
0.09 -- 0.089997
0.1 -- 0.02
0.11 -- 0.10999
0.12 -- 0.11998
0.13 -- 0.12998
0.14 -- 0.13999
0.15 -- 0.14999
0.16 -- 0.16
0.17 -- 0.17001
0.18 -- 0.18002
0.19 -- 0.19003

\$ python2.7 b.py
0.01 -- 0.01
0.02 -- 0.02
0.03 -- 0.03
0.04 -- 0.04
0.05 -- 0.05
0.06 -- 0.060005
0.07 -- 0.07
0.08 -- 0.08
0.09 -- 0.09
0.1 -- 0.0
0.11 -- 0.10999
0.12 -- 0.11998
0.13 -- 0.12998
0.14 -- 0.13999
0.15 -- 0.15
0.16 -- 0.16
0.17 -- 0.17
0.18 -- 0.18002
0.19 -- 0.19003

\$ python3.4 b.py
0.01 -- 0.01
0.02 -- 0.02
0.03 -- 0.03
0.04 -- 0.04
0.05 -- 0.05
0.060005 -- 0.060005
0.07 -- 0.07
0.08 -- 0.08
0.09 -- 0.09
0.0 -- 0.0
0.10999 -- 0.10999
0.11998 -- 0.11998
0.12998 -- 0.12998
0.13999 -- 0.13999
0.15 -- 0.15
0.16 -- 0.16
0.17 -- 0.17
0.18002 -- 0.18002
0.19003 -- 0.19003

What's going on here is that in Python 2.7 the repr() of floats was
changed to use the minimum number of digits to accurately roundtrip the
number under correct rounding.  For compatibility reasons, the str()
representation was not changed for 2.7.  But in Python 3.2, str() was
changed to be identical to repr() for floats.  It's important to keep in
mind that the actual binary values stored in float objects are the same
across all of these releases; only the representation of them as decimal
characters varies.

https://docs.python.org/2.7/whatsnew/2.7.html#other-language-changes

http://bugs.python.org/issue9337

--
Ned Deily,
n...@acm.org

--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```Ok I've seen https://docs.python.org/2/tutorial/floatingpoint.html now
thanks to Yhg1s on #python

I bet you get this kind of thing a lot, sorry :-/

FraserL fraser.long+use...@nospamgmail.com wrote in
news:XnsA35313E634BA0fraserlonggmailcom34@216.196.109.145:

I think I found a strange bug in python 3.4.1,
...

#test code
z = 0.01
p = 0.0
for x, y in enumerate(range(1, 20)):
p += z
print(p)
#end

3.4.1 output:

...
0.05
0.060005
0.07
...

I'm not hugely accustomed to Python, but this seems crazy to me.

--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```

On 06/20/2014 05:57 PM, FraserL wrote:

I think I found a strange bug in python 3.4.1,

No, this is not a bug in Python.  There is a limitation of floating
point arithmetic in *all* languages, on *all* computers.   Python 3 may
be the first to let you see this limitation, but it's always been there.

See https://docs.python.org/2/tutorial/floatingpoint.html for more details.

Gary Herron

fresh install of

https://www.python.org/ftp/python/3.4.1/python-3.4.1.amd64.msi

and a fresh install of
https://www.python.org/ftp/python/2.7.7/python-2.7.7.amd64.msi
to compare it to.

#test code
z = 0.01
p = 0.0
for x, y in enumerate(range(1, 20)):
p += z
print(p)
#end

3.4.1 output:

0.01
0.02
0.03
0.04
0.05
0.060005
0.07
0.08
0.09
0.0
0.10999
0.11998
0.12998
0.13999
0.15
0.16
0.17
0.18002
0.19003

2.7.7 output:

0.01
0.02
0.03
0.04
0.05
0.06
0.07
0.08
0.09
0.1
0.11
0.12
0.13
0.14
0.15
0.16
0.17
0.18
0.19

I'm not hugely accustomed to Python, but this seems crazy to me.

--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```
On 06/20/2014 06:11 PM, FraserL wrote:

Ok I've seen https://docs.python.org/2/tutorial/floatingpoint.html now
thanks to Yhg1s on #python

I bet you get this kind of thing a lot, sorry :-/

Yes, often, but it's not a problem. :-)

FraserL fraser.long+use...@nospamgmail.com wrote in
news:XnsA35313E634BA0fraserlonggmailcom34@216.196.109.145:

I think I found a strange bug in python 3.4.1,

...

#test code
z = 0.01
p = 0.0
for x, y in enumerate(range(1, 20)):
p += z
print(p)
#end

3.4.1 output:

...

0.05
0.060005
0.07

...

I'm not hugely accustomed to Python, but this seems crazy to me.

--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```On Sat, Jun 21, 2014 at 10:57 AM, FraserL
fraser.long+use...@nospamgmail.com wrote:
#test code
z = 0.01
p = 0.0
for x, y in enumerate(range(1, 20)):
p += z
print(p)
#end

General tip when you think you've found a bug: Cut out everything that
isn't part of it. In this case, the enumerate has nothing to do with
what you're seeing, which is an artifact of floating-point arithmetic,
so a more classic loop header would simply be:

for i in range(19):

(Or some people will use _ to emphasize that the iterated-over values
are being ignored.)

The smaller you can make your test code, the more likely that people
will be able to see what's going on.

Also, when you're looking at how things print out, consider looking at
two things: the str() and the repr(). Sometimes just print(p)
doesn't give you all the info, so you might instead want to write your
loop thus:

z = 0.01
p = 0.0
for i in range(19):
p += z
print(str(p) +  --  + repr(p))

Sometimes you can get extra clues that way, although in this instance
I think you won't.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

```

Re: python 3.44 float addition bug?

```Read this: https://docs.python.org/3.4/tutorial/floatingpoint.html

On Sat, Jun 21, 2014 at 9:57 AM, FraserL
fraser.long+use...@nospamgmail.com wrote:
I think I found a strange bug in python 3.4.1,

fresh install of

https://www.python.org/ftp/python/3.4.1/python-3.4.1.amd64.msi

and a fresh install of
https://www.python.org/ftp/python/2.7.7/python-2.7.7.amd64.msi
to compare it to.

#test code
z = 0.01
p = 0.0
for x, y in enumerate(range(1, 20)):
p += z
print(p)
#end

3.4.1 output:

0.01
0.02
0.03
0.04
0.05
0.060005
0.07
0.08
0.09
0.0
0.10999
0.11998
0.12998
0.13999
0.15
0.16
0.17
0.18002
0.19003

2.7.7 output:

0.01
0.02
0.03
0.04
0.05
0.06
0.07
0.08
0.09
0.1
0.11
0.12
0.13
0.14
0.15
0.16
0.17
0.18
0.19

I'm not hugely accustomed to Python, but this seems crazy to me.
--
https://mail.python.org/mailman/listinfo/python-list

--