469,923 Members | 1,547 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,923 developers. It's quick & easy.

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

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
Feb 20 '07 #1
9 1398
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).
Feb 20 '07 #2
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
Feb 20 '07 #3
On Feb 20, 11:29 pm, "joanne matthews (RRes-Roth)"
<joanne.matth...@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.
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

Feb 20 '07 #4
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
Feb 20 '07 #5
On Feb 21, 2:05 am, Grant Edwards <gra...@visi.comwrote:
On 2007-02-20, joanne matthews (RRes-Roth) <joanne.matth...@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.
>
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.

Feb 20 '07 #6
On 2007-02-20, John Machin <sj******@lexicon.netwrote:
On Feb 21, 2:05 am, Grant Edwards <gra...@visi.comwrote:
>On 2007-02-20, joanne matthews (RRes-Roth) <joanne.matth...@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.
>>
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!!
Feb 20 '07 #7
On Feb 21, 3:44 am, Grant Edwards <gra...@visi.comwrote:
On 2007-02-20, John Machin <sjmac...@lexicon.netwrote:
On Feb 21, 2:05 am, Grant Edwards <gra...@visi.comwrote:
On 2007-02-20, joanne matthews (RRes-Roth) <joanne.matth...@bbsrc.ac.ukwrote:
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".

Feb 20 '07 #8
On Feb 20, 6:08 am, "John Machin" <sjmac...@lexicon.netwrote:
>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.

Feb 21 '07 #9
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

Feb 21 '07 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by redneck_kiwi | last post: by
5 posts views Thread by kelmen | last post: by
12 posts views Thread by syn1kk | last post: by
18 posts views Thread by atv | last post: by
135 posts views Thread by robinsiebler | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.