123.3 + 0.1 is 123.3999999999 ?

Isaac To kkto at csis.hku.hk
Thu May 15 22:07:58 EDT 2003


>>>>> "Isaac" == Isaac To <kkto at csis.hku.hk> writes:

    Jeff> Has the python community converged on a favored solution for
    Jeff> financial/currency apps? An uninformed use of floats as currency
    Jeff> would have obvious pitfalls.

    Jeff> I hope to write some order/inventory apps for a client who uses
    Jeff> product unit prices with variations of as little the
    Jeff> ten-thousandths of a cent, and unit counts of millions of items.

    Jeff> It would be reassuring to have the necessary float() issues for
    Jeff> fixed-accuracy calculation encapsulated in a reusable class. Does
    Jeff> a decent one already exist?

    Isaac> The type that you have mentioned is already there.  It is called
    Isaac> long integers.

By the way, I think even if you use float, there is no "obvious pitfall" in
financial/currency apps.  Normal IEEE double-precision floating point
numbers has 16-17 significant digits of precision.  It means unless you are
doing things like adding up two numbers one of the size 1e13 (i.e., ten
trillions) and another of size 1e-3 (and then subtract the first), you are
pretty fine by just rounding to the nearest 1e-3.  (Who the hell will
actually do that?)  That you want to multiply two numbers one as small as
1e-5 and one as large as 1e15 is not a problem either, since multiplications
do not cause much loss in precision.

Somehow people keep yelling that they can't stand the inaccuracy of floating
points, without actually looking at how inaccurate (or actually, accurate)
they are.

Regards,
Isaac.




More information about the Python-list mailing list