digitalmars.D.learn - Is there an equivalent of the decimal type in D?
- Myron Alexander (5/5) Jan 19 2007 Hello.
- BCS (3/16) Jan 19 2007 Not yet. It could be done as a lib, even using BCD opcodes. I might give...
- Myron Alexander (9/12) Jan 21 2007 I'm not a machine language/asm programmer anymore so I didn't know that
- Sean Kelly (4/7) Jan 22 2007 For finance, isn't round-off error more of an issue than internal
- Myron Alexander (18/30) Jan 26 2007 Internal representation is not the issue. I need stable and predictable
- Sean Kelly (29/58) Jan 27 2007 I'm not sure that accuracy is a problem--at least not compared to
- Jeff Nowakowski (9/18) Jan 27 2007 Floating point is a very bad idea for representing money. If you're
- Sean Kelly (9/28) Jan 27 2007 And this is more of a problem than rounding error with BCD? Most BCD
- Sean Kelly (4/20) Jan 27 2007 Perhaps this is my source of confusion. Does Java's BigDecimal support
- Jeff Nowakowski (3/5) Jan 27 2007 Yes.
- Bill Baxter (4/15) Jan 27 2007 Bad example. 1.5 *is* exactly representable in base 2 floating point.
- Sean Kelly (3/18) Jan 27 2007 Oops! :-)
- Joel C. Salomon (5/8) Jan 27 2007 The ongoing revision to the IEEE 754 floating-point standard has support...
- Leandro Lucarella (8/13) Jan 29 2007 You can try using a C arbitrary precision library (or wrap it so it's
- Myron Alexander (5/20) Jan 29 2007 Hello Leandro.
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: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.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 26 2007
Myron Alexander 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. 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. SeanMyron Alexander wrote: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.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?
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: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.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.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? SeanThe 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.
Jan 27 2007
Sean Kelly wrote:Jeff Nowakowski wrote:Perhaps this is my source of confusion. Does Java's BigDecimal support arbitrary precision after the decimal point? SeanSean Kelly wrote: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.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.
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:Oops! :-) SeanI'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 :-)
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 Leandro. Thanks for the pointer. I will take a look when I can. All the best, 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?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/
Jan 29 2007