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

- Myron Alexander <malexander investec.co.za> Jan 19 2007
- BCS <ao pathlink.com> Jan 19 2007
- Myron Alexander <malexander investec.co.za> Jan 21 2007
- Sean Kelly <sean f4.ca> Jan 22 2007
- Myron Alexander <someone somewhere.com> Jan 26 2007
- Sean Kelly <sean f4.ca> Jan 27 2007
- Jeff Nowakowski <jeff dilacero.org> Jan 27 2007
- Sean Kelly <sean f4.ca> Jan 27 2007
- Sean Kelly <sean f4.ca> Jan 27 2007
- Jeff Nowakowski <jeff dilacero.org> Jan 27 2007
- Bill Baxter <dnewsgroup billbaxter.com> Jan 27 2007
- Sean Kelly <sean f4.ca> Jan 27 2007
- "Joel C. Salomon" <JoelCSalomon Gmail.com> Jan 27 2007
- Leandro Lucarella <llucarella integratech.com.ar> Jan 29 2007
- Myron Alexander <someone somewhere.com> Jan 29 2007

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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