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