Weird result returned from adding floats depending on order I add them

[joanne matthews (RRes-Roth)]

I'm getting different results when I add up a list of floats depending
on the order that I list the floats. For example, the following returns
False:
def check():
totalProp=0
inputs=[0.2,0.2,0.2,0.1,0.2,0,0.1]
for each in inputs:

totalProp+=each
print "totalProp=",totalProp
if totalProp != 1:
print "Your proportions must add up to 1"

return False
return True

However, if I swap, the 4th and 5th list items like this:

totalProp=0
inputs=[0.2,0.2,0.2,0.2,0.1,0,0.1]
for each in inputs:

totalProp+=each
print "totalProp=",totalProp
if totalProp != 1:
print "Your proportions must add up to 1"

return False
return True

I get True returned. Can anyone tell me whats going on and how I can
avoid the problem. Thanks

Joanne Matthews

[Laurent Pointal]

joanne matthews (RRes-Roth) a écrit :

I'm getting different results when I add up a list of floats depending
on the order that I list the floats. For example, the following returns
False:
def check():
totalProp=0
inputs=[0.2,0.2,0.2,0.1,0.2,0,0.1]
for each in inputs:

totalProp+=each
print "totalProp=",totalProp
if totalProp != 1:
print "Your proportions must add up to 1"

return False
return True

However, if I swap, the 4th and 5th list items like this:

totalProp=0
inputs=[0.2,0.2,0.2,0.2,0.1,0,0.1]
for each in inputs:

totalProp+=each
print "totalProp=",totalProp
if totalProp != 1:
print "Your proportions must add up to 1"

return False
return True

I get True returned. Can anyone tell me whats going

Its related to the internal representation of real numbers using a
finite number of binary digits - intermediate additions may (here the
order is have an impact) produce results which have no representation,
and lead to dismiss of an epsilon value.

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

on and how I can
avoid the problem. Thanks

Use an ad-hoc library with numerical types using a different
representation (other posters may give examples of libraries they use).

[John McCallum]

Hi,

I'm getting different results when I add up a list of floats depending
on the order that I list the floats. For example, the following returns

[snip summation]

if totalProp != 1:

From a numerical analysis point of view, never ever do this. The values
you are adding are approximations to the numbers you require, you then
test for equality (the real no no)...

There is even a section in the Python tutorial about it:

http://docs.python.org/tut/node16.html

Cheers,
John McCallum
Edinburgh

[John Machin]

On Feb 20, 11:29 pm, "joanne matthews (RRes-Roth)"
<[e-mail]:

I'm getting different results when I add up a list of floats depending
on the order that I list the floats.

This is quite expected. Floating point arithmetic is subject to
rounding errors.

[doesn't add to 1.0]

inputs=[0.2,0.2,0.2,0.1,0.2,0,0.1]

However, if I swap, the 4th and 5th list items like this:

inputs=[0.2,0.2,0.2,0.2,0.1,0,0.1]

[adds to 1.0]

What is happening:

print repr(whatever_you_are_puzzled_by) is a Very Good Idea (TM).

>>a = [0.2, 0.2, 0.2, 0.1, 0.2, 0.1]
b = [0.2, 0.2, 0.2, 0.2, 0.1, 0.1]
sum(a)

1.0000000000000002

>>sum(b)

1.0

>>tot = 0.0
for x in a:

.... tot += x
.... print repr(x), repr(tot)
....
0.20000000000000001 0.20000000000000001
0.20000000000000001 0.40000000000000002
0.20000000000000001 0.60000000000000009
0.10000000000000001 0.70000000000000007
0.20000000000000001 0.90000000000000013
0.10000000000000001 1.0000000000000002

>>tot = 0.0
for x in b:

.... tot += x
.... print repr(x), repr(tot)
....
0.20000000000000001 0.20000000000000001
0.20000000000000001 0.40000000000000002
0.20000000000000001 0.60000000000000009
0.20000000000000001 0.80000000000000004
0.10000000000000001 0.90000000000000002
0.10000000000000001 1.0

>>>

As you can see, 0.1 and 0.2 can't be represented exactly as floating
point numbers. Consequently there is only a rough chance that they
will add up to what you think they should add up to.

Fixes:

(1) Round the sums to a suitable precision.

>>round(sum(a), 3)

1.0

>>round(sum(b), 3)

1.0

>>>

(2) Test against a range, rather than for equality:

>>abs(sum(a) - 1.0) < 0.001

True

>>abs(sum(b) - 1.0) < 0.001

True

>>>

(3) Use the Decimal module

(4) Google this group (or the Python cookbok, I forget which) for
fancy algorithms for doing accurate sums of lists of floats.

HTH,
John

[Grant Edwards]

On 2007-02-20, joanne matthews (RRes-Roth) <jo*************@bbsrc.ac.ukwrote:

I'm getting different results when I add up a list of floats depending
on the order that I list the floats.

That's how floats work.

For example, the following returns
False:
def check():
totalProp=0
inputs=[0.2,0.2,0.2,0.1,0.2,0,0.1]
for each in inputs:

totalProp+=each
print "totalProp=",totalProp
if totalProp != 1:

Floating point operations are not exact. This test requires
them to be.

[...]

Can anyone tell me whats going on

IEEE floating point can not exactly represent 0.2 nor 0.1, so
you get approximations.

and how I can avoid the problem.

Don't use floating point if you expect exact results.

--
Grant Edwards grante Yow! I feel better about
at world problems now!
visi.com

[John Machin]

On Feb 21, 2:05 am, Grant Edwards <[e-mail]:

On 2007-02-20, joanne matthews (RRes-Roth) <[e-mail]:

I'm getting different results when I add up a list of floats depending
on the order that I list the floats.

>
Don't use floating point if you expect exact results.

It's not the floating point that's the problem, it's the radix, in
this case 2, not being able to express n/10 exactly. As the tutorial
points out, radix-10 has problems representing n/3 (and n/7 and ...)
exactly.

Another take: Don't expect exact results. If the input is exact to 1
or two decimal places, don't expect the sum to be exact to 15 or more
decimal places.

[Grant Edwards]

On 2007-02-20, John Machin <sj******@lexicon.netwrote:

On Feb 21, 2:05 am, Grant Edwards <[e-mail]:

>On 2007-02-20, joanne matthews (RRes-Roth) <[e-mail]:

I'm getting different results when I add up a list of floats depending
on the order that I list the floats.

>>
Don't use floating point if you expect exact results.

It's not the floating point that's the problem, it's the radix, in
this case 2, not being able to express n/10 exactly. As the tutorial
points out, radix-10 has problems representing n/3 (and n/7 and ...)
exactly.

No matter what radix you choose, you're going to be able to
exactly represent 0% of the rational numbers within the range
of the representation. Since you have no control over the FP
representation (and hence radix), and little control over input
values, the only sane thing to do is to write your code under
the assumption that FP can't represent any values exactly.

Another take: Don't expect exact results.

Which is what I said. :)

If the input is exact to 1 or two decimal places, don't expect
the sum to be exact to 15 or more decimal places.

In this case the input values have about 14 significant digits.
So does the output. Unfortunately, the algorithm as written
requires an infinite number of significant digits.

--
Grant Edwards grante Yow! WHOA!! Ken and
at Barbie are having TOO
visi.com MUCH FUN!! It must be the
NEGATIVE IONS!!

[John Machin]

On Feb 21, 3:44 am, Grant Edwards <[e-mail]:

On 2007-02-20, John Machin <[e-mail]:

On Feb 21, 2:05 am, Grant Edwards <[e-mail]:

On 2007-02-20, joanne matthews (RRes-Roth) <[e-mail]:

Don't use floating point if you expect exact results.

Another take: Don't expect exact results.

Which is what I said. :)

It may well be what you said. I didn't hear that. What you wrote was
"Don't use floating point if you expect exact results." That is *not*
the same as "Don't expect exact results".

[Rhamphoryncus]

On Feb 20, 6:08 am, "John Machin" <[e-mail]:

>for x in b:

... tot += x
... print repr(x), repr(tot)
...
0.20000000000000001 0.20000000000000001
0.20000000000000001 0.40000000000000002
0.20000000000000001 0.60000000000000009
0.20000000000000001 0.80000000000000004
0.10000000000000001 0.90000000000000002
0.10000000000000001 1.0

As you can see, 0.1 and 0.2 can't be represented exactly as floating
point numbers. Consequently there is only a rough chance that they
will add up to what you think they should add up to.

Although your point is correct, this is actually a myth about repr.
The goal of repr is to be able to round-trip all numbers, so
eval(repr(n)) == n. From that perspective it would be perfectly legal
if it printed out a nice and short "0.2" or "0.1".

As for the actual value, although you can't express all non-repeating
base-10 values with non-repeating base-2, you can express base-2 with
base-10. It just gets a little long:

>>'%.60f' % 0.2

'0.20000000000000001110223024625156540423631668090 8203125000000'

>>'%.60f' % 0.1

'0.10000000000000000555111512312578270211815834045 4101562500000'

Unfortunately this method of printing out floats won't work for
smaller values, since the %f formatting limits the number of decimal
places.

But if you want a more compact exact representation I have bodged
together a way of printing out floats in base-16:

>>hexfloat(0.2)

hexfloat('0.33333333333334')

>>hexfloat(0.1)

hexfloat('0.1999999999999A')

Interesting, if a bit confusing.

[Miki]

Hello Joanne,

... [float problem] ...
I get True returned. Can anyone tell me whats going on and how I can
avoid the problem. Thanks

If you want to be truly accurate, you can use gmpy.mpq (http://
gmpy.sourceforge.net/).

>>a = [0.2, 0.2, 0.2, 0.1, 0.2, 0.1]
b = [0.2, 0.2, 0.2, 0.2, 0.1, 0.1]
qa = [gmpy.mpq(int(i * 10), 10) for i in a]
qb = [gmpy.mpq(int(i * 10), 10) for i in b]
sum(qa)

mpq(1)

>>sum(qb)

mpq(1)

>>sum(qa) == sum(qb)

True

HTH,
--
Miki <mi*********@gmail.com>
http://pythonwise.blogspot.com