Is there an equivalent of the decimal type in D?
Sean Kelly
sean at f4.ca
Sat Jan 27 10:51:58 PST 2007
Myron Alexander wrote:
> Sean Kelly wrote:
>> Myron Alexander wrote:
>>> Hello.
>>>
>>> I want to work with numbers without having to worry about binary
>>> representation. I work with currencies and other such values that
>>> must be absolute. In Java I have BigDecimal and in Python I have
>>> decimal.
>>
>> For finance, isn't round-off error more of an issue than internal
>> representation?
>
> Internal representation is not the issue. I need stable and predictable
> handling of arithmetic operations and display. With floats and double,
> workarounds exist but they are cumbersome and not guaranteed. Also,
> different compilers and C/FPUs can handle floats and doubles slightly
> differently; not a problem currently but may be a problem for the
> future. A decimal type sacrifices raw performance for guaranteed decimal
> accuracy.
>
> It has been a long time since I had to deal with floats and doubles
> since I do most of my work with BigDecimal; the type of applications do
> not seem to suffer in performance, they are mostly io bound. I have read
> several papers on float handling including, what I have been told is the
> holy text: http://docs.sun.com/source/806-3568/ncg_goldberg.html.
>
> If you have any links to guides on how to handle floating point to
> achieve predictable accuracy, could you please post them as I can't say
> that I understand that problem space as well as I used to.
I'm not sure that accuracy is a problem--at least not compared to
fixed-point BCD. The essential issue with using base 2 floating point
for problems where the user expects an "exact" result in base 10 is that
of representation. Simply put, some numbers that have an exact
representation in base 10 are infinitely repeating numbers in base 2,
and vice-versa. This is why a calculation resulting in 1.5 in base 10
displays as 1.4999... in base 2. But as far as accuracy is concerned,
I'm sure you'll agree that 1.4999... is not terribly far from 1.5 :-)
Of course, finance folks don't see it this way because if you display
1.4999 on a report it doesn't match what they expect and they scream and
yell.
A more important issue to me, however, is that round-off error be as
small as possible. Walter has posted on this a bunch in the past
regarding numeric analysis, the reason for "real" in D, etc. Basically,
when you're dealing with complex formulas involving large numbers, the
more often you round an intermediate result the further off the final
result will be. And while losing a ton of fractional amounts won't
cause lives to be lost like it would in a navigation system, those
"partial pennies" do add up.
Unless you're simply dealing with numbers too large to be represented
exactly with floating-point (16 digits for 64-bit double, and I can't
remember the limit for 80-bit real offhand), I think it makes more sense
to use floating point internally and round to the appropriate degree of
precision for display. The other consideration would be if the
financial spec required rounding to specific degrees of precision at
various points in the calculation, though rounding with floating-point
is still obviously an option.
Sean
More information about the Digitalmars-d-learn
mailing list