Differences

This shows you the differences between two versions of the page.

--- pdclib:printing_floating_point_numbers [2025/08/10 20:46] – solar
+++ pdclib:printing_floating_point_numbers [2025/08/21 14:01] (current) – [Biased Exponent] solar
@@ Line 25: / Line 25: @@
 Instead of assuming two's complement to allow for positive and negative exponents, IEEE 754 uses //biased// exponents: The exponent bits are interpreted as unsigned integer, but to get the "real" exponent value, you need to //substract// the bias value, which is ''FLOAT_MAX_EXP - 1'', ''DBL_MAX_EXP - 1'', or ''LDBL_MAX_EXP - 1'', respectively.
+=== Huh? ===
+Remember that IEEE 754 is a //floating point// standard. It makes //no// asumptions on the integer logic of the machine. What should the exponent be encoded at? Two's compliment? You don't know if the ALU supports that! So the exponent is stored unsigned. That means that the value ''1'' (1x10^0, or 1x2^0) is not stored with an exponent of all zeroes, but an exponent halfway between all zeroes (signifying denormals) and all ones (signifying INF / NaN).
 ==== Infinity ====
@@ Line 66: / Line 69: @@
 //Dragon 4// allows to find the shortest decimal number that //uniquely identifies// the binary number.
+Given the limited precision of the mantissa, each representable binary value has exactly one predecessor, and one successor. If we have printed enough decimal digits to //unambiguously// identify //this// binary value, we can (and should!) stop printing further digits, as those no longer signify any usable precision.
+Let's have a look at such a triple of consecutive numbers, for the sake of brevity in single precision format:
+  * 0x4040 0001 -- 3.0000002384185791015625
+  * 0x4040 0002 -- 3.000000476837158203125
+  * 0x4040 0003 -- 3.0000007152557373046875
+You will see that everything after the seventh fractional digit is, effectively, useless. The decimal number ''3.0000004'' //uniquely identifies// the binary value ''0x4040 0002'', and is all that should be printed, even if the user requested a precision of 20 digits.
+The initial reflex might be, "but what when I //need// those additional digits?". The simple answer is, you really don't. You already have no way to distinguish whether the value you're looking at really was ''...047683...'' or, for example, ''...039871...'', or ''...058812...''. If you //think// you need those digits, you should not be using a ''float''.
+==== How does it do it? ====
+Looked at from low earth orbit, Dragon4 works something like this<sup>[1]</sup>:
+  * Copy the mantissa part of the value into a big integer.
+  * If the value is not a subnormal, set the implied decimal.
+  * As you don't have a decimal point in there anywhere, correct the exponent by the number of mantissa bits (basically, move the decimal point out of the bit pattern).
+  * You set up a "mask" value, one that signifies half the distance between the value and its predecessor / successor.<sup>[2]</sup>
+  * //{ stuff not yet understood here }//
+  * The mantissa bigint now being the numerator / dividend, find the highest power of ten that is still less than the mantissa bigint, as denominator / divisor.
+  * Begin loop:
+    * Divide mantissa bigint numerator by power-of-ten denominator. Result is in the range 0..9 (1..9 for the first round), and your decimal digit.
+    * Substract denominator * quotient from mantissa.
+    * Multiply mantissa and mask value by 10.
+    * Repeat until a) mantissa is zero, b) specified precision is reached, c) mantissa < mask value
+[1]: I am not done either understanding nor implementing the Dragon4 algorithm itself, so what I am writing here is very much work in progress.
+[2]: There is a special case when the successor value would have a higher exponent, i.e. the successor would be twice as far away as the predecessor. You need to take this into account.
+==== Visualization ====
+Taking the hint from [[https://www.ryanjuckett.com/printing-floating-point-numbers/|Ryan Juckett's tutorial]] on the subject, let's visualize what we're doing with a 6-bit floating point format, with 1 sign bit, 3 exponent bits, and 2 mantissa bits.
+^   Binary   ^  Exponent  ^  Mantissa  ^  Value  ^  Margin  ^
+|  0 000 00  | 0          | 0          | 0       | 0.0625   |
+|  0 000 01  | 0          | 1          | 0.0625  | 0.0625   |
+|  0 000 10  | 0          | 2          | 0.125   | 0.0625   |
+|  0 000 11  | 0          | 3          | 0.1875  | 0.0625   |
+|  0 001 00  | 1          | 0          | 0.25    | 0.0625   |
+|  0 001 01  | 1          | 1          | 0.3125  | 0.0625   |
+|  0 001 10  | 1          | 2          | 0.375   | 0.0625   |
+|  0 001 11  | 1          | 3          | 0.4375  | 0.0625   |
+|  0 010 00  | 2          | 0          | 0.5     | 0.125    |
+|  0 010 01  | 2          | 1          | 0.625   | 0.125    |
+|  0 010 10  | 2          | 2          | 0.75    | 0.125    |
+|  0 010 11  | 2          | 3          | 0.875   | 0.125    |
+|  0 011 00  | 3          | 0          | 1       | 0.25     |
+|  0 011 01  | 3          | 1          | 1.25    | 0.25     |
+|  0 011 10  | 3          | 2          | 1.5     | 0.25     |
+|  0 011 11  | 3          | 3          | 1.75    | 0.25     |
+|  0 100 00  | 4          | 0          | 2       | 0.5      |
+|  0 100 01  | 4          | 1          | 2.5     | 0.5      |
+|  0 100 10  | 4          | 2          | 3       | 0.5      |
+|  0 100 11  | 4          | 3          | 3.5     | 0.5      |
+|  0 101 00  | 5          | 0          | 4       | 1        |
+|  0 101 01  | 5          | 1          | 5       | 1        |
+|  0 101 10  | 5          | 2          | 6       | 1        |
+|  0 101 11  | 5          | 3          | 7       | 1        |
+|  0 110 00  | 6          | 0          | 8       | 2        |
+|  0 110 01  | 6          | 1          | 10      | 2        |
+|  0 110 10  | 6          | 2          | 12      | 2        |
+|  0 110 11  | 6          | 3          | 14      | -        |
+|  0 111 00  | 7          | 0          | INF     | -        |
+|  0 111 01  | 7          | 1          | NaN(*)  | -        |
+|  0 111 10  | 7          | 2          | NaN     | -        |
+|  0 111 11  | 7          | 3          | NaN     | -        |
+*: Signalling NaN (highest mantissa bit zero)
+The "Margin" is the difference between that number and its next higher "neighbor". Half that distance is where a decimal representation would be "tied" between those two binary representations.
+Take 0.25 and 0.3125 for example, which have a margin of 0.0625. Half that margin would be 0.03125. The decimal number (0.25 + 0.03125) = 0.28125 would be tied beween 0.25 and 0.3125. But 0.28124 would //unambiguously// identify the binary 0 001 00, because that's closer. This is how strtod() and scanf() can make use of this margin number.
+This works the other way around, too. Let's look at 0.4375. I don't need to //print// 0.4375 to unambiguously identify the binary 0 001 11, because either 0.43 or 0.44 would suffice (being less than 0.03125 away from the "real" value). Just 0.4 wouldn't do, because (0.4375 - 0.4) > 0.03125, and thus closer to 0.375 (0 001 10). This is the way printf() is looking at the issue.