Re: round off problem

new topic     » goto parent     » topic index » view thread      » older message » newer message

> 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.
>

 Euphoria atoms are IEEE double precision floating points. They should never
be used for fiannical calculations, as many common decimal values cannot be
accuratrly represented in this type of value. For example, .01 has no finite
binary rerpesentation and therefor can't be exactly represented in an atom.
No doubt your source uses Binary Coded Decimal internally, which can
represent .01 exactly. (By the way BCD calculations are horribly slow vs
binary floating point and for this reason are never used except in finacial
calcualtions.)

Euphoria can't handle BCD directly but there are workarounds. If your totals
are constitently under 10,000,000 you can express all values in cents and
store them as Eu integers. If you are dealing with larger values, you will
need a libray for big numbers--check the contributions page.

-- Mike Nelson

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu