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 9 1398
joanne matthews (RResRoth) 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 adhoc library with numerical types using a different
representation (other posters may give examples of libraries they use).
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
On Feb 20, 11:29 pm, "joanne matthews (RResRoth)"
<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
On 20070220, joanne matthews (RResRoth) <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
On Feb 21, 2:05 am, Grant Edwards <gra...@visi.comwrote:
On 20070220, joanne matthews (RResRoth) <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, radix10 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.
On 20070220, John Machin <sj******@lexicon.netwrote:
On Feb 21, 2:05 am, Grant Edwards <gra...@visi.comwrote:
>On 20070220, joanne matthews (RResRoth) <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, radix10 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!!
On Feb 21, 3:44 am, Grant Edwards <gra...@visi.comwrote:
On 20070220, John Machin <sjmac...@lexicon.netwrote:
On Feb 21, 2:05 am, Grant Edwards <gra...@visi.comwrote:
On 20070220, joanne matthews (RResRoth) <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".
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 roundtrip 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 nonrepeating
base10 values with nonrepeating base2, you can express base2 with
base10. 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 base16:
>>hexfloat(0.2)
hexfloat('0.33333333333334')
>>hexfloat(0.1)
hexfloat('0.1999999999999A')
Interesting, if a bit confusing.
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 This discussion thread is closed Replies have been disabled for this discussion. Similar topics
3 posts
views
Thread by redneck_kiwi 
last post: by

10 posts
views
Thread by Charles Law 
last post: by

3 posts
views
Thread by lagj 
last post: by

38 posts
views
Thread by baong 
last post: by

5 posts
views
Thread by kelmen 
last post: by

12 posts
views
Thread by syn1kk 
last post: by

9 posts
views
Thread by serge 
last post: by

18 posts
views
Thread by atv 
last post: by

135 posts
views
Thread by robinsiebler 
last post: by
          