On Mon, 7 Jun 2004 12:31:37 +0100 (BST), Christian Smith <[EMAIL PROTECTED]> wrote: > > 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.
Internationalization (i18n) adds further complexity to currency arithmetic. For instance, the treatment of rounding during currency calculations varies with different countries - rounding up / rounding down, offset by 0.25 / offset by zero, and more. (see http://www.xencraft.com/resources/multi-currency.html#rounding). Then there's 'Bankers rounding' (values below 0.5 go down and values above 0.5 go up; values of exactly 0.5 go to the nearest even number). Even for non-currency fixed-point applications the BigDecimal class in Java and the upcoming Decimal class in Python support up to 8 rounding modes. (These aren't for formatting printed results -- the rounding mode affects the outcome during the calculation of lists of numbers, such as the sum of a database fixed-point column.) Perhaps this is one illustration of why SQLite stays away from having a host of data types -- to do it right involves a lot of sophisticated code that detracts more and more from the foundational SQLite design principle of fast, light, relational data storage and retrieval. Cheers, Bill --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
