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.

Does D have an equivalent, either at the language level or as a module/class?

Thanks,

Myron.

Reply to Myron,

> 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.
> 
> Does D have an equivalent, either at the language level or as a
> module/class?
> 
> Thanks,
> 
> Myron.
> 

Not yet. It could be done as a lib, even using BCD opcodes. I might give it a crack later, but I have a lot on my plate right now.

BCS wrote:
> Not yet. It could be done as a lib, even using BCD opcodes. I might give it a crack later, but I have a lot on my plate right now.
> 

I'm not a machine language/asm programmer anymore so I didn't know that such opcodes existed. A quick google found some links. Thanks.

Right now, having a decimal class is not a priority, I was more curious than anything. I still have to solve database connection issues as well as a raft of other simple but necessary issues that I take for granted on Java and Python.

Thanks for the info and best regards,

Myron.

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?


Sean

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?
> 
> 
> Sean

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.

Regards,

Myron.

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

Sean Kelly wrote:
> 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.

Floating point is a very bad idea for representing money.  If you're adding up currencies then you want an exact representation, not "close enough".  Sooner or later you will get bitten by rounding error if you use floats.

> 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.

A very bad option.  If the interest rate is 0.0239 or whatever, then that is what you should use, not the "close enough" floating point.  You then use Banker's Rounding whenever you adjust an account.

-Jeff

Sean Kelly wrote:
> 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.

Bad example.  1.5 *is* exactly representable in base 2 floating point. 2^0 + 2^-1 :-)


--bb

Bill Baxter wrote:
> Sean Kelly wrote:
>> 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.
> 
> Bad example.  1.5 *is* exactly representable in base 2 floating point. 2^0 + 2^-1 :-)

Oops! :-)


Sean

Jeff Nowakowski wrote:
> Sean Kelly wrote:
>> 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.
> 
> Floating point is a very bad idea for representing money.  If you're adding up currencies then you want an exact representation, not "close enough".  Sooner or later you will get bitten by rounding error if you use floats.

And this is more of a problem than rounding error with BCD?  Most BCD representations I've seen only use around 6 decimal places, which is far too few in some cases.

>> 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.
> 
> A very bad option.  If the interest rate is 0.0239 or whatever, then that is what you should use, not the "close enough" floating point.  You then use Banker's Rounding whenever you adjust an account.

I still fail to see how a floating point calculation that adjusts to the appropriate precision for display will be less precise than BCD.  If that's the case, why is floating point used for science applications where precisions is typically even more important?


Sean