Floating point exactness & alternatives (summary)

John Baldwin johnb at srchtec.UUCP
Thu Aug 9 08:36:39 AEST 1990


In article <1990Aug7.173030.2823 at zoo.toronto.edu> henry at zoo.toronto.edu (Henry Spencer) writes:
>In article <713 at tetrauk.UUCP> rick at tetrauk.UUCP (Rick Jones) writes:
>>  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.

Doesn't this push him back into the "continued sums" implementation?
Remember, conversion rates between different currencies "slide" up and down
at a fairly high frequency.  (Does anybody know just HOW frequently the
exchange rates change?)

This would require an INTERNAL currency which would probably NOT be the same as
a recognized world currency;  one in which any unit of any other world currency
can be expressed as an integer.  This is probably tricky enough to find WITHOUT
having the conversions changing on you all the time!

Rick: how many currencies do you have to deal with and how often do they
change?  Maybe this *would* be a feasible approach: if the numbers are too
big for a (long), store them in a struct.  Have a multidimensional array
of structs containing numerators and denominators for conversions.
-- 
John T. Baldwin                      |  johnb at srchtec.uucp
Search Technology, Inc.              |  johnb%srchtec.uucp at mathcs.emory.edu
standard disclaimer:                 |  ...uunet!samsung!emory!stiatl!srchtec..
opinions and mistakes purely my own. |  ...mailrus!gatech!stiatl!srchtec...



More information about the Comp.lang.c mailing list