Floating point number association error

Question

When I do a floating point addition I get different results. My database is 32 bit Kognitio. Can some one explain me better why this is a problem when I have my floating point values well within the limits.

I do understand that the operations involving floating point numbers are not always associative due to approximation and rounding errors. But in my case, I haven't used the complete precision of storage.

Below are my trials using a simple select

Good Way!! 
   2.45000000000000e+000 
+  2.45000000000000e+000 
+  2.45000000000000e+000 
+  2.45000000000000e+000 
+  2.45000000000000e+000 
+  2.45000000000000e+000
+  4.90000000000000e+000 
+ -9.80000000000000e+000 
+ -9.80000000000000e+000 
--------------------------
   0.00000000000000e+000

Bad Way??
  -9.80000000000000e+000 
+ -9.80000000000000e+000 
+  2.45000000000000e+000 
+  2.45000000000000e+000 
+  2.45000000000000e+000 
+  2.45000000000000e+000 
+  2.45000000000000e+000 
+  2.45000000000000e+000
+  4.90000000000000e+000 
--------------------------
-3.55271367880050e-015

Guys, I accept C&C but please let me know how I can improve this question. A simple -1 will not give me any input — Srini V, Mar 05 '15 at 16:24

Jeffrey L Whitledge · Accepted Answer · 2015-03-05T16:38:33.367

1

But you are using the full precision of the 32-bit floating point number. Remember that these are binary floating point values, not decimal. When you view it in decimal, you get a bunch of trailing zeros, and it looks very nice and clean. But if you were to view those values in binary, you would see a bunch of ones trailing to the right. The value in binary is not exactly equivalent to what you are seeing in decimal.

2.45 in base 10 is approximately equal to 10.011100110011001100110011001100 in 32-bit binary. (These values may not be exactly correct, but it gives the right idea.) That binary number rendered exactly in decimal is 2.449999988079071044921875, which gets rounded to 2.450000.

Adding those approximations in different orders will give different approximations.

edited Mar 05 '15 at 16:38

answered Mar 05 '15 at 16:30

Jeffrey L Whitledge

58,241
9
71
99

Thanks, but can you please explain using my example on why it is giving different answer when i change the order? If I simply remove the + 4.90000000000000e+000 from the second example (Bad way) I am getting - 4.90000000000000e+000 . That is where it is confusing me – Srini V Mar 05 '15 at 16:33
Got that jeff. Thanks a lot – Srini V Mar 05 '15 at 16:43

score 0 · Answer 2 · answered Mar 06 '15 at 11:43

The FP representations of various numbers (and hence extent of inaccuracy) will all be controlled by the IEEE754 FP standard.

You can see binary representations for any FP value by using the tool at http://www.h-schmidt.net/FloatConverter/IEEE754.html

For example, 2.45 has sign bit 0 exponent encoded as 128 (which is evaluated after subtracting 127, so is effectively 1) mantissa encoded as 1887437 (which is approximately 1.225000023841858)

As you can see with that representation, it is fractionally too big (as doubling the mantissa value gives something slightly bigger than the 2.45 we are trying to represent).

You can put the other values into that tool to find the representations that IEEE754 requires.

The cause of the inaccuracy propagated into the result is going to be the order in which numbers are summed, as we’ve seen in the Good Way / Bad Way examples.

Floating point number association error

2 Answers2