[Discuss] Financial database / balance?

[markw at mohawksoft.com]

> On 01/15/2012 02:51 PM, Richard Pieri wrote:
>> 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.
>>
> While Mark is correct based on display and rounding the number 0.37
> cannot be implemented exactly in a binary floating point number. There
> is always that error, as Richard points out.

I find myself in an ambiguous position. I have worked in the banking
software industry as well as banking in general. I know about the
requirements and pros and cons of a financial math package vs IEEE
floating point.

That said, there are subtle differences between the two, but beyond that
there are different expectations of what precision means. For instance, if
you were to write a amortization calculator, you might be tempted to carry
fractional value across calculation periods. In a financial environment
this is not done, nothing is carried across transactions.

To address the assertion that you can't represent some numbers "exactly,"
this is partially true. You can use doubles for calculation, but you can't
just use printf( "%f"); to display the value. You need to play some
tricks. with floor(), ceil(), and round().


>
> --
> Jerry Feldman <gaf at blu.org>
> Boston Linux and Unix
> PGP key id:3BC1EB90
> PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90
>
>
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>