Lo que todo programador debería saber sobre aritmética de punto flotante
Typo fixes and clarifications
+9
-9
+4
-4
content/basic.html
+4
-4
content/basic.html
···
34
34
### Why do other calculations like 0.1 + 0.4 work correctly?
35
35
36
36
In that case, the result (0.5) *can* be represented exactly as a floating-point number,
37
-
and it's possible for rounding errors in the input numbers to cancel each other out.
38
-
Even that can't necessarily be relied upon though. If for example those two numbers
39
-
were stored in differently sized floating point representations first, and then added
40
-
together, the rounding errors might not have offset each other perfectly.
37
+
and it's possible for rounding errors in the input numbers to cancel each other out -
38
+
But that can't necessarily be relied upon (e.g. when those two numbers
39
+
were stored in differently sized floating point representations first, the rounding
40
+
errors might not offset each other).
41
41
42
42
In other cases like 0.1 + 0.3, the result actually isn't *really* 0.4, but close enough that 0.4
43
43
is the shortest number that is closer to the result than to any other floating-point number. Many languages then display that number instead of converting the actual result back to the closest
+2
-2
content/errors/comparison.html
+2
-2
content/errors/comparison.html
···
61
61
-----------------------------------------
62
62
But the there is an alternative to adding even more conceptual complexity to such an apparently simple task: instead of comparing `a` and `b` as [real numbers](http://en.wikipedia.org/wiki/Real_numbers), we can think about them as discrete steps and define the error margin as the maximum number of possible floating-point values between the two values.
63
63
64
-
This is conceptually very clear and easy and has the advantage of implicitly scaling the relative error margin with the magnitude of the values. Technically, it's a bit more complex, but not as much as you might think, because IEEE 754 floats are designed to maintain their order when their bit patters are interpreted as integers.
64
+
This is conceptually very clear and easy and has the advantage of implicitly scaling the relative error margin with the magnitude of the values. Technically, it's a bit more complex, but not as much as you might think, because IEEE 754 floats are designed to maintain their order when their bit patterns are interpreted as integers.
65
65
66
-
However, this method does require the programming language to support conversion between floating-point values and integer bit patters. Read the [Comparing floating-point numbers](/references/) paper for more details.
66
+
However, this method does require the programming language to support conversion between floating-point values and integer bit patterns. Read the [Comparing floating-point numbers](/references/) paper for more details.
+1
-1
content/formats/exact.html
+1
-1
content/formats/exact.html
···
5
5
6
6
While [binary](/formats/binary/) [floating-point](/formats/fp/) numbers are better for computers to work with, and usually good enough for humans, sometimes they are just not appropriate. Sometimes, the numbers really must add up to the last bit, and no technical excuses are acceptable - usually when the calculations involve money.
7
7
8
-
Unfortunately, there is no dominating standard like IEEE 754 for this.
8
+
Unfortunately, there is no dominating standard like IEEE 754 for this (The 2008 version of the standard added decimal types, which is too recent to have seen widespread adoption).
9
9
Each language or platform has its own solution, sometimes multiple different ones. For details, look at the "Languages" section.
10
10
11
11
There are at least three fundamentally different kinds of such types:
+1
-1
content/formats/fp.html
+1
-1
content/formats/fp.html
···
57
57
* The significand's most significant bit is assumed to be 1 and omitted, except for special cases.
58
58
* There are separate **positive and a negative zero** values, differing in the sign bit, where all other bits are 0. These must be considered equal even though their bit patterns are different.
59
59
* There are special **positive and negative infinity** values, where the exponent is all 1-bits and the significand is all 0-bits. These are the results of calculations where the positive range of the exponent is exceeded, or division of a regular number by zero.
60
-
* There are special **not a number** (or NaN) values where the exponent is all 1-bits and the significand is not all 0-bits. These represent the result of various undefined calculations (like multiplying 0 and infinity, any calculation involving a NaN value, or application-specific cases). Even bit-identical NaN values must *not* be considered equal.
60
+
* There are special **not a number** (or NaN) values where the exponent is all 1-bits and the significand is *not* all 0-bits. These represent the result of various undefined calculations (like multiplying 0 and infinity, any calculation involving a NaN value, or application-specific cases). Even bit-identical NaN values must *not* be considered equal.