1. Re: arithmetic
- Posted by r.schr at t-online.de
Jun 01, 2002
Hi Walter (and Chris)
the problem is not that of languages nor of the fpu. It is simply a
mathematical fact that there are numbers which can not be represented
exactly due to the limited amount of memory to store them.
For your currency calculations Chris is right as long as you add or
subtract in cents. BUT: the division at the end is not right generally,
the result may not be representable exactly in the machine! If you want
to keep it exact, change the cents into a string, re-read the characters
except the last two as a number: that are your Dollars, and re-read the
last two characters as a number: that are exactly your cents. Than you
print all in a nice string format.
For currency calculations: only the 16th position may be wrong, for
example, the number "1" may be represented as 0.9999999999999999 or
1.000000000000001 (decimal) inside the machine (actually the machine
uses binary numbers).
As long as the maximum number representing your money (except you are
extremely rich!) has less then say 12 decimal digits, and as long as the
number of operations (+-*/) are small (less the say 100), then your
result may be rounded at the end by using the format "%25.2f" of the
printf() or sprintf() functions, i.e.:
a = .9999999999999999
b = 1.000000000000001
printf(1,"%25.2f %25.2f\n" , {a,b})
printf(1,"%25.15e %25.15e\n", {a,b}) -- to compare
the result of which is:
1.00 1.00
9.999999999999998e-001 1.000000000000001e+000
But be aware that YOU have to decide how and where to round if you have
to do monetary calculations! Insurance companies for example do have
strict rules how to do rounding!
Have a nice day, Rolf
Chris Bensler wrote:
>
>
> That is a known problem with floating point accuracy. Not eu's fault.
> The fpu has a hard time dealing with certain numbers, and doesn't
> calculate them accurately.
>
> With fp, 0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1 != 1
>
> Using FP, the actual value of 0.1 can't be represented, instead it's
> 0.1...
> Only certain numbers are affected because of the fp anomaly.
>
> To get around this, if you are using $ numbers, multiply all your values
> by 100 first, to remove the decimal. When you are finished calculating,
> divide by 100. and the value should be accurate.
>
> EG:
> function add_money(atom a, atom b)
> return ((a*100) + (b*100))/100
> end function
>
> You also have to consider rounding.
> Your adding machine stops at 2 decimal places (all values rounded to
> .00). Or most do.
> The FPU uses 15 places of precision (basically, no rounding)
>
> This very topic was discussed a few months ago. If you search the
> February posts. Sorry, I don't remember the name of the thread.
>
> Chris
>
> George Walters wrote:
> > Next problem is when is zero really zero. I'm adding and subtracting a
> > bunch
> > of numbers (dollars and cents) which total to zero on an adding machine
> > but
> > on EU it's -6.blabla -15. How does one deal with this? Does not EU
> > handle
> > this? I have typed the numbers as atom. Was this wrong?
> >
> > george
> >
> >
> >
>
>
