Lo que todo programador debería saber sobre aritmética de punto flotante
various suggested corrections
+8
-7
+5
-4
content/errors/comparison.html
+5
-4
content/errors/comparison.html
···
8
8
to be equal (e.g. when calculating the same result through different correct methods) often differ
9
9
slightly, and a simple equality test fails. For example:
10
10
11
-
a = 0.1 + 0.2
12
-
b = 0.15 + 0.15
11
+
a = 0.15 + 0.15
12
+
b = 0.1 + 0.2
13
13
if(a == b) // can be false!
14
+
if(a >= b) // can also be false!
14
15
15
16
Don't use absolute error margins
16
17
--------------------------------
···
31
32
-----------------------
32
33
There are some important special cases where this will fail:
33
34
34
-
* When both `a` and `b` are zero. `0.0/0.0` is "not a number", which returns false for all comparisons.
35
-
* When only `b` is zero, the division yields "infinity", which is greater than epsilon even when `a` is smaller.
35
+
* When both `a` and `b` are zero. `0.0/0.0` is "not a number", which causes an exception on some platforms, or returns false for all comparisons.
36
+
* When only `b` is zero, the division yields "infinity", which may also cause an exception, or is greater than epsilon even when `a` is smaller.
36
37
37
38
Also, the result is not commutative (`nearlyEquals(a,b)` is not always the same as `nearlyEquals(b,a)`). To fix these problems, the code has to get a lot more complex, so we really need to put it into a function of its own:
38
39
+1
-1
content/formats/binary.html
+1
-1
content/formats/binary.html
···
61
61
62
62
Specifically, binary can only represent those numbers as a finite fraction where the denominator
63
63
is a power of 2. Unfortunately, this does not include most of the numbers that can be
64
-
represented as finite fration in base 10, like 0.1.
64
+
represented as finite fraction in base 10, like 0.1.
65
65
66
66
| Fraction | Base | Positional Notation | Rounded to 4 digits| Rounded value as fraction | Rounding error |
67
67
|-|-|-|-|
+2
-2
content/formats/integer.html
+2
-2
content/formats/integer.html
···
8
8
This works, but has a number of **severe drawbacks**:
9
9
10
10
* It's more work (and more opportunity for bugs) to get it right, especially in regard to [rounding modes](/errors/rounding/).
11
-
* Integers have complete precision, but very limited range, and when they overflow, they usually "wrap around" silently, i.e. the largest integer plus 1 becomes zero (for unsigned ints) or the largest negative one (for signed). This is just about the worst possible behaviour when dealing with money, for obvious reasons.
12
-
* The implicit decimal point is hard to change and extremely inflexible: if you store dollars as cents, it's simply impossible to support the [Bahraini dinar](http://en.wikipedia.org/wiki/Bahraini_dinar)(1 dinar = 1,000 Fils) at the same time. You'd have to store the position of the decimal point with the data - the first step in implementing your own (buggy, non-standard) limted-precision decimal [floating-point](/formats/fp/) format.
11
+
* Integers have complete precision, but very limited range, and when they overflow, they usually "wrap around" silently, i.e. the largest integer plus 1 becomes zero (for unsigned ints) or the negative value with the largest magnitude (for signed). This is just about the worst possible behaviour when dealing with money, for obvious reasons.
12
+
* The implicit decimal point is hard to change and extremely inflexible: if you store dollars as cents, it's simply impossible to support the [Bahraini dinar](http://en.wikipedia.org/wiki/Bahraini_dinar)(1 dinar = 1,000 Fils) at the same time. You'd have to store the position of the decimal point with the data - the first step in implementing your own (buggy, non-standard) limited-precision decimal [floating-point](/formats/fp/) format.
13
13
14
14
Summary: **using integers is not recommended.** Do this only if there really is no [better alternative](/formats/exact/) at all.