pdclib:printing_floating_point_numbers
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| pdclib:printing_floating_point_numbers [2025/08/21 13:40] – 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 " | 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 " | ||
| + | === 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 '' | ||
| ==== Infinity ==== | ==== Infinity ==== | ||
| Line 144: | Line 147: | ||
| 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 " | 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 " | ||
| - | |||
| - | |||
pdclib/printing_floating_point_numbers.1755776406.txt.gz · Last modified: by solar