[java] fixed point class
Fixed-Point arithmetic isn't needed in Java, just use the floating point math within the primitives float and double…
Author
I need to handle monetary values for financial operations and AFAIK, floating point math is not really a good thing in those cases due to rounding errors.
I could use double and force it to round it to two or three numbers after the decimal point when I print it, but I wonder if this is the usual way to go in these applications (I dont't like to do a simple addition like 245.50 + 14.15 and get 259.640000000000000002 :-(
I could use double and force it to round it to two or three numbers after the decimal point when I print it, but I wonder if this is the usual way to go in these applications (I dont't like to do a simple addition like 245.50 + 14.15 and get 259.640000000000000002 :-(
I don't know of a fixed point class. But why would you expect that answer? The answer would more likely be 259.65. Moreover, you are far more likely to get such rounding artifacts with fixed point arithmic. The usual way is certainly using floats.
Alternatively, for fixed precision monetary values, sometimes the computations are done in cents, using only integer arithmic. This way, you will always get exactly the right amount. It is somewhat like fixed point arithmic only without the implementation difficulties. You can just use the Java integer.
Illco
Alternatively, for fixed precision monetary values, sometimes the computations are done in cents, using only integer arithmic. This way, you will always get exactly the right amount. It is somewhat like fixed point arithmic only without the implementation difficulties. You can just use the Java integer.
Illco
Try apFloat
http://www.apfloat.org/
It is an arbitrary precision arithmetic package.
That should help!
http://www.apfloat.org/
It is an arbitrary precision arithmetic package.
That should help!
Author
Thanks for your answers. Yes, actually I meant decimal, not exactly fixed point. I found this. It seems to have a limited license, but I don't plan to sell my program (I do it for my gf) so There should be no problems using it.
No, I would expect it to result 259.65, but actually I got some strange rounding errors (the listed addition was only an example, I don't remember the real values involved).
EDIT: mmm, apparently the BigDecimal class (improved in java 1.5 api following the request of IBM) just does this...
[Edited by - cignox1 on October 23, 2005 12:15:36 PM]
Quote:
But why would you expect that answer? The answer would more likely be 259.65.
No, I would expect it to result 259.65, but actually I got some strange rounding errors (the listed addition was only an example, I don't remember the real values involved).
EDIT: mmm, apparently the BigDecimal class (improved in java 1.5 api following the request of IBM) just does this...
[Edited by - cignox1 on October 23, 2005 12:15:36 PM]
Boy this is elementary programming question. Rouding errors caused by number representation.
BTW I suspect that number was 259.650000000000000002, other version of the problem would be 259.649999999999999998. As you clearly see majority of digits is correct, you just need round few least important digits, so first number would be 259.650000000000000002 - 0.000000000000000002 = 259.65
second would be 259.649999999999999998 + 0.000000000000000002 = 259.65
Doubles are used even in banking operations, they are just rounded properly to nearest even number before showing the result to user (to don't scare him). They are also rounding after exponential calculations. If you need to know when number representation errors would become significant, you could calculate it as a simple exercise.
BTW I suspect that number was 259.650000000000000002, other version of the problem would be 259.649999999999999998. As you clearly see majority of digits is correct, you just need round few least important digits, so first number would be 259.650000000000000002 - 0.000000000000000002 = 259.65
second would be 259.649999999999999998 + 0.000000000000000002 = 259.65
Doubles are used even in banking operations, they are just rounded properly to nearest even number before showing the result to user (to don't scare him). They are also rounding after exponential calculations. If you need to know when number representation errors would become significant, you could calculate it as a simple exercise.
Author
Quote:
Boy this is elementary programming question. Rouding errors caused by number representation.
Thank you, I did the homeworks ;-)
Seriously, I know that floating point representations lead to rounding errors, that's why I asked for a decimal representation, that should make them dramatically less evident than with binary, because 0.1(for example) can be represented exactly.
Yes, I thought to keep doubles because BigDecimal would make me modify 2000+ codelines (and I don't feel like, really). If only java permitted operator overloading, moving from double to BigDecimal would have been easier :-(
One thing to remember is that operator overloading could easily be replaced by a function. By creating a replaceall macro in your IDE from 'x+y' to 'BigDecimal.add(x,y)' is a small feat, especially in comparison to rewriting 2000 lines of code.
Author
Quote:Original post by H_o_p_s
One thing to remember is that operator overloading could easily be replaced by a function. By creating a replaceall macro in your IDE from 'x+y' to 'BigDecimal.add(x,y)' is a small feat, especially in comparison to rewriting 2000 lines of code.
Wouldn't this replace all x+y occurrencies (so integers, strings and other types as well?).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
