Xref: utzoo comp.lang.c:30854 comp.lang.misc:5306
Newsgroups: comp.lang.c,comp.lang.misc
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Floating point exactness & alternatives (summary)
Message-ID: <1990Aug7.173030.2823@zoo.toronto.edu>
Organization: U of Toronto Zoology
References: <713@tetrauk.UUCP>
Date: Tue, 7 Aug 90 17:30:30 GMT

In article <713@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes:
>... This is nothing more taxing (!) than business systems, which are not
>known for requiring complex mathematics.  They don't, but they do require
>exactness.  Auditors have this annoying view that accounts must balance to the
>penny, not 1 part in 10 to-the-something.  There is a good case for using some
>form of BCD representation, but there are many programming advantages in using
>the embedded numerical types of the language...

Our own experience, in building accounting systems for our own use, is that
the problem can often be eliminated by ignoring the decimal point in dollar
currencies and thinking of money as measured in pennies.  Then integer
arithmetic suffices, if amounts are not huge.  If amounts *are* huge, note
that most floating-point boxes will do precise integer arithmetic if you
are careful to avoid operations that necessarily produce fractions.

Yes, you get fractional amounts if you (say) buy 3.5 tons of stuff that
is priced at $1.17 per ton... but there really *is* a fractional amount
there, and the proper response is to explicitly round it in whatever
way is appropriate to the problem (in this case, the standard business
approach of rounding up).

This isn't necessarily an adequate solution to tricky cases involving things
like multiple currencies, but for simple stuff, it's amazing how much
simpler the problem gets if you don't insist on representing money as a
fraction just because it's written that way.
-- 
The 486 is to a modern CPU as a Jules  | Henry Spencer at U of Toronto Zoology
Verne reprint is to a modern SF novel. |  henry@zoo.toronto.edu   utzoo!henry