On Sun, 6 Jun 2004, Raymond Irving wrote:
>Hi,
>
>Is this a problem with all database systems or is it only unique to SQLite?
Most database systems have a seperate money type precisely for this
problem, which is often BCD to allow arbitrary length values. Rounding
errors are simply not an option for financial institutions.
You could process money using 64-bit integers, using a BLOB encoded
representation, and write custom aggregate function to decode and sum
these 64-bit values.
>
>__
>Raymond Irving
>
>"D. Richard Hipp" <[EMAIL PROTECTED]> wrote:
>The value 1.2 cannot be represented exactly in a (finite-length)
>binary number. On my machine, 1.2 gets stored as
>
>1.1999999999999999555910790149937383830547332763671875
>
>Whenever you print this out to a reasonable number of digits,
>it gets rounded to 1.2. But internally, the value is never 1.2.
>The value 1.2 simply cannot be stored in an 8-byte IEEE floating
>point number.
>
>If you are storing dollars and cents, only 4 cents values out of
>100 can be represented exactly in binary: 0.00, 0.25, 0.50, and
>0.75. Any other cents value will be approximated. When you add
>up a large number of dollars+cents values, the approximation errors
>will hopefully cancel each other out and you will get a result that
>is a good approximation. But there are no guarantees. The errors
>might accumulate so that your answer is a penny or two different
>from what you accountant thinks it ought to be. If you need to
>be 100% dead-on accurate to the penny, you should store your
>dollars+cents values as an integer number of cents.
>
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
