Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Financial database / balance?



> On Jan 15, 2012, at 1:56 PM, markw at mohawksoft.com wrote:
>>
>> You are confusing "display" of a double with "use" of a double.
>> 0.36999999999999999556 is numerically, with finite precision less than
>> 15
>> decimal places, effectively 0.37.
>
> No, I'm not.  While .369999999 etc. is "effectively" 0.37, it isn't 0.37.
> Do an amortization of your IRA with doubles and with arbitrary precision
> BCD.  You'll get different results, and the doubles math result will be
> wrong.
>
> Wrong is not good enough for anyone's finances.

You snipped the part where I said scientific math is different than
financial math. Please also remember I'm the one who mentioned the double
rounding errors.

Calculating an amortization of a mortgage over 30 years for a financial
institution is different than you would calculate in a spread sheet. With
a spread sheet, precision is carried across periods, in a financial
institution, the accounts are "settled" each period and there is no
precision carried to the next period. Financial math makes sure that every
penny is counted and there is very little fractional ambiguity.


Remember:

0.999999999999999 for all intent and purposes is the same a one. And a 0
with an infinite number of 9s after the decimal point equals one.

>
> --Rich P.
>
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org