www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Is there an equivalent of the decimal type in D?

reply Myron Alexander <malexander investec.co.za> writes:
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.
Jan 19 2007
next sibling parent reply BCS <ao pathlink.com> writes:
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.
Jan 19 2007
parent Myron Alexander <malexander investec.co.za> writes:
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.
Jan 21 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
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
Jan 22 2007
parent reply Myron Alexander <someone somewhere.com> writes:
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.
Jan 26 2007
parent reply Sean Kelly <sean f4.ca> writes:
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
Jan 27 2007
next sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
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
Jan 27 2007
parent reply Sean Kelly <sean f4.ca> writes:
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
Jan 27 2007
parent reply Sean Kelly <sean f4.ca> writes:
Sean Kelly wrote:
 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.

Perhaps this is my source of confusion. Does Java's BigDecimal support arbitrary precision after the decimal point? Sean
Jan 27 2007
parent Jeff Nowakowski <jeff dilacero.org> writes:
Sean Kelly wrote:
 Perhaps this is my source of confusion.  Does Java's BigDecimal support 
 arbitrary precision after the decimal point?

Yes. -Jeff
Jan 27 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Jan 27 2007
parent Sean Kelly <sean f4.ca> writes:
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
Jan 27 2007
prev sibling next sibling parent "Joel C. Salomon" <JoelCSalomon Gmail.com> writes:
Myron Alexander wrote:
 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?

The ongoing revision to the IEEE 754 floating-point standard has support for decimal; when 754r seems close to ratification would be a good time to add it to D. --Joel
Jan 27 2007
prev sibling parent reply Leandro Lucarella <llucarella integratech.com.ar> writes:
Myron Alexander escribió:
 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?

You can try using a C arbitrary precision library (or wrap it so it's little more pleasant to use in D), like GMP[1]. [1] http://www.swox.com/gmp/ -- Leandro Lucarella Integratech S.A. 4571-5252
Jan 29 2007
parent Myron Alexander <someone somewhere.com> writes:
Leandro Lucarella wrote:
 Myron Alexander escribió:
 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?

You can try using a C arbitrary precision library (or wrap it so it's little more pleasant to use in D), like GMP[1]. [1] http://www.swox.com/gmp/

Hello Leandro. Thanks for the pointer. I will take a look when I can. All the best, Myron.
Jan 29 2007