Currently using a double data to run an accumulator in a for loop. I am adding .1 to each cycle of the loop, however, the expected result is off by a very minor number ie - .000000000022, can't give much more info because it relates to an assignment in the cattle drive. Any ideas? Jerome
Jerome, Here is a quote from "Java 2 for Professional Developers" by Michael Morgan:
"Floating point numbers are like piles of sand -- whenever you move them you lose a little sand, and pick up a little dirt. This happens because the computer stores the significant bits (called the mantissa separately from the exponent. As you do arithmetic that changes the exponent, the significance of the bits in the mantissa changes. Bits that are insignificant in one step may show up as significant parts of the number later in the calculation."
Hope this helps. Stephanie
Joined: Nov 22, 2008
Stephanie: Thanks for the input ... part of the learning process. You answered my question ... only to bring up another, so in the "real world" .... how do I perform a calculation and maintain the integrity of the data being processed (ie. paychecks. order entries, etc...) If I'm doing math with a double or float, do I have to convert it to an int or long, then convert it back. Perhaps a few desired method calls from the math package with do the trick ??? .......... I dunno ?? just wondering. Jerome
Jerome, If you are doing fix point (ie like dollars and cents) you would use ints or longs to hold the numbers not floating point numbers. The reason for this is exactally the point you led with, you get precision error. for most financial type software we handle this with fixed point number that we "shift" when we input, calcluate or output. The best example of the is good old Cobol, where we would define a number (it would be stored as an integer) with a picture (a mask used to "fix" the number when transformations would occur, like: 07 PAY-CHECK-RATE PIC 9(3)V99. 07 PAY-CHECK-HOURS PIC 9(3)V99. 07 PAY-CHECK-AMOUNT PIC 9(6)V99. then you could calcuate amount = rate * hours. which would internally yeild a number with 4 decimal point, and would automatically truncate to two decimal points.
Joined: Nov 22, 2008
Cobol ??? WOW - I haven't touch that in 7+ years !!! .... but I did understand your explaination. Thanks for the response. Jerome
Admittedly, this is a judgement call, but I hope someone can advise me on whether I should worry about the mantissa affecting the integrity of my variables. I only need the tenths place, and so far the unexpected number only show up starting at about the ten-millionths place. I'm testing this on the server where it will run, and it's all going to stay on the server as it's part of the backend to a web app. However, we're going to be getting a new server within the year. Should I worry that on the new server, the mantissa may approach the tenths place enough to affect how it is rounded? Thanks in advance for your thoughtful elucidation. g.
No, you should not need to worry about this. There might be small differences in results between JVMs, but not that big that you will likely be affected. If you *really* need the same result on every JVM, you can use the strictfp keyword (http://java.about.com/library/glossary/bldef-strictfp.htm) in your variable declarations. This way calculations are guaranteed to get the exactly same results on every JVM, though you might lose some performance.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus