Why does 821 + 840.34 = 1661.3400000000001
Article ID: KB0091861
Updated On:
| Products | Versions |
|---|---|
| TIBCO ActiveMatrix BusinessWorks | - |
| Not Applicable | - |
Description
Resolution:
BW is used for serious business application integration. This means it has to be implemented strictly according to standard, with most efficiency in terms of memory space and speed, and it has to provide predictable output. This means, in BW, all data are stored in memory according to the standard, without any redundancy. Calculations are performed the same way as other programming languages, without any massaging.
As we know, numbers are stored in computer as binaries. Unfortunately, most of the decimals can not be converted to binaries precisely. For example, the equivalent of decimal 1809.93 is binary
11100010001.1(11011100001010001111) which reads: 11100010001.111011100001010001111 with infinite loops of 11011100001010001111 after it (the correct notation should be replacing parenthesis by dots on top of the 1st and last number in the loop).
As you can see, there is no way to store 1809.93 in memory precisely regardless of what precision you choose (float, double ...). For example, xsd:double datatype is patterned after the IEEE double-precision 64-bit floating point type [IEEE 754-1985]. The basic value space of double consists of the values m Ã? 2^e, where m is an integer whose absolute value is less than 2^53, and e is an integer between -1075 and 970,
When 1809.93 is stored as a double, it would have 53 bits to represent the significand, the other 11 for integer exponent.The rest of the data has to be rounded.
On top of that, there is a more serious problem: as user can always choose to input more digits than BW uses to store numbers, plus those digits used to round up, there is always a chance that BW can not precisely store a number and have to cut the tail.
For example, let's say a data type is only 1 bit long to represent the significand, and my input is 0.10101
With BW, the output is always 0.1
With a calculator with 1 additional bit, the output would be 0.11 (because 0.101 would be round up); with 2 additional bits, the output would be 0.101 (0.1010 needs to be round down).
Therefore, using BW doesn't give you the precise number is limited by decimal-binary conversion. The reason BW doesn't "massage" the output is because it is expensive in terms of both time and space, and the way applications (like calculators) "massage" the output is not standardized therefore could lead to unpredictable output.
If you have to get the rounded information, you need to choose a data type with redundancy (for example using a double when you need a float), and implement your own "massaging" algorithm.
You can also read an explanation Sun provided. It is to answer why 12.1-10.11 does not produce 1.99.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4704007
The workaround is using ‘round-fraction’.
BW is used for serious business application integration. This means it has to be implemented strictly according to standard, with most efficiency in terms of memory space and speed, and it has to provide predictable output. This means, in BW, all data are stored in memory according to the standard, without any redundancy. Calculations are performed the same way as other programming languages, without any massaging.
As we know, numbers are stored in computer as binaries. Unfortunately, most of the decimals can not be converted to binaries precisely. For example, the equivalent of decimal 1809.93 is binary
11100010001.1(11011100001010001111) which reads: 11100010001.111011100001010001111 with infinite loops of 11011100001010001111 after it (the correct notation should be replacing parenthesis by dots on top of the 1st and last number in the loop).
As you can see, there is no way to store 1809.93 in memory precisely regardless of what precision you choose (float, double ...). For example, xsd:double datatype is patterned after the IEEE double-precision 64-bit floating point type [IEEE 754-1985]. The basic value space of double consists of the values m Ã? 2^e, where m is an integer whose absolute value is less than 2^53, and e is an integer between -1075 and 970,
When 1809.93 is stored as a double, it would have 53 bits to represent the significand, the other 11 for integer exponent.The rest of the data has to be rounded.
On top of that, there is a more serious problem: as user can always choose to input more digits than BW uses to store numbers, plus those digits used to round up, there is always a chance that BW can not precisely store a number and have to cut the tail.
For example, let's say a data type is only 1 bit long to represent the significand, and my input is 0.10101
With BW, the output is always 0.1
With a calculator with 1 additional bit, the output would be 0.11 (because 0.101 would be round up); with 2 additional bits, the output would be 0.101 (0.1010 needs to be round down).
Therefore, using BW doesn't give you the precise number is limited by decimal-binary conversion. The reason BW doesn't "massage" the output is because it is expensive in terms of both time and space, and the way applications (like calculators) "massage" the output is not standardized therefore could lead to unpredictable output.
If you have to get the rounded information, you need to choose a data type with redundancy (for example using a double when you need a float), and implement your own "massaging" algorithm.
You can also read an explanation Sun provided. It is to answer why 12.1-10.11 does not produce 1.99.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4704007
The workaround is using ‘round-fraction’.
Issue/Introduction
Why does 821 + 840.34 = 1661.3400000000001
Feedback
Yes
No
Powered by
