Re: round off problem
On 28 Jun 2004, at 11:14, George Walters wrote:
>
>
> I have imported general ledger data from a working system in another OS
> into mysql using Matt's ODBC tools. Trying to finish the EU general
> ledger software, I've run into serious round off issues. Here's a
> couple of examples to show the problem.
>
> A typical account balance:
>
> Mysql shows -1143.46 which is correct
> EU trace shows -1143.459961 which is not accurate to 15 places as the EU
> manual states.
>
> Totalling the credits and debits over the entire file of transactions
> gives the following (printing with a mask of %12.2f.)
>
> Debits = 4642782.63
> Credits= 4642782.56
>
> Off by 4 cents. The input data from the other OS is balanced. It looks
> like there's about 8 places of accuracy not 15.
> The data records are always read into a sequence, then arithmetic is
> done with atoms.
>
> Any Ideas?
Use only string math libs. That way you are also free from the famous
pentium math bug, or any future bugs. Humans play with money in decimal
system, and additions is fine in binary when translated to decimal, but
division isn't. Subtraction can get you into trouble too. Only other cure, if
you
don't mind being tied to a certain cpu family, is to use machine code to flip it
into bcd mode, do the math, and return it to previous state. But i would avoid
binary like the plague when your rear counts on accuracy in decimal matters.
Or, round up/down to the penny after *each and every* basic math operation,
which is still not trustworthy if your job is on the line. The order of the
operations across the db will change the results, which is why it's not
trustworthy.
Kat
|
Not Categorized, Please Help
|
|
