Problem with floating point precision

[j_mckitrick]

I checked the docs, but found nothing about floating point issues.

I am working on an app that deals with currency values, and only does
addition and subtraction (no division). But I am starting to see
values that should be the same failing a compare! What is the
workaround or correct way to compare 2 floats? It worked fine for
months, then suddenly starting acting odd. I might have upgraded
Python somewhere in between, I can't recall.

jonathon

 

[John Roth]

I checked the docs, but found nothing about floating point issues.

I am working on an app that deals with currency values, and only does
addition and subtraction (no division). But I am starting to see
values that should be the same failing a compare! What is the
workaround or correct way to compare 2 floats? It worked fine for
months, then suddenly starting acting odd. I might have upgraded
Python somewhere in between, I can't recall.

The basic issue here is that you shouldn't be using floats
for currency. Granted, lots of people do, but it will eventually
run into exactly the problem you're describing.

The reason is that currency is best handled by some form of
arithmetic that works with discrete quantities, while floats are
intended to be used with continuous quantities (like scientific
and engineering measurements).

There's a floating decimal package in 2.4 that is intended
to eventually (in 2.5 maybe?) be the base of a currency
package. However, that doesn't help today.

What I'd do is create a currency class that uses plain
old, boring ints as the base, with the necessary decimal
point handling present behind the scene.

John Roth

 

[Roy Smith]

I checked the docs, but found nothing about floating point issues.

I am working on an app that deals with currency values, and only does
addition and subtraction (no division). But I am starting to see
values that should be the same failing a compare! What is the
workaround or correct way to compare 2 floats?

A full analysis of floating point math would fill a book. The details
depend greatly on the underlying FP hardware in your system, although
these days it's pretty hard to find a machine which doesn't use IEEE 754
standard math, so you might start by googling for "ieee 754".

Python 2.4 will have a new Decimal numeric type, which was invented to
resolve many of the problems that happen when trying to use floats for
currency calculations. Take a look at
http://www.python.org/peps/pep-0327.html for more information.

There is an alpha version of 2.4 that was released recently; you might
want to download that and start playing around with the Decimal type to
see if that solves your problem. I'm sure other people here could give
a better estimate of when there will be a production release of 2.4, but
my guess is that it's a few months away.

 

[Brian Gough]

I checked the docs, but found nothing about floating point issues.

See the appendix "Floating Point Arithmetic: Issues and Limitations"
in the Python Tutorial for a discussion of this topic.

 

[Tim Peters]

[John Roth]

...
There's a floating decimal package in 2.4 that is intended
to eventually (in 2.5 maybe?) be the base of a currency
package. However, that doesn't help today.

It will help in 2.4, though. Fixed-point decimal is a subset of what
2.4's decimal arithmetic can do, and it's dead easy to do exact
"dollars and cents" calculations using it. I'm not sure what a
currency package would add on top of it -- maybe add currency markers
to string output, perhaps offer a simplified rounding discipline for
multiplication, not really sure. The "hard parts" will already be in
2.4.

 

[Arthur]

The basic issue here is that you shouldn't be using floats
for currency. Granted, lots of people do, but it will eventually
run into exactly the problem you're describing.

The reason is that currency is best handled by some form of
arithmetic that works with discrete quantities, while floats are
intended to be used with continuous quantities (like scientific
and engineering measurements).

There's a floating decimal package in 2.4 that is intended
to eventually (in 2.5 maybe?) be the base of a currency
package. However, that doesn't help today.

@$#,###.##
import decimal

I believe wil be the syntax for getting at it

Art