This commit is contained in:
krahets
2024-04-06 03:02:20 +08:00
parent 0a9daa8b9f
commit 8d37c215c8
148 changed files with 70398 additions and 408 deletions
@@ -2,13 +2,13 @@
comments: true
---
# 3.3   Number Encoding *
# 3.3   Number encoding *
!!! note
In this book, chapters marked with an asterisk '*' are optional readings. If you are short on time or find them challenging, you may skip these initially and return to them after completing the essential chapters.
## 3.3.1   Integer Encoding
## 3.3.1   Integer encoding
In the table from the previous section, we observed that all integer types can represent one more negative number than positive numbers, such as the `byte` range of $[-128, 127]$. This phenomenon seems counterintuitive, and its underlying reason involves knowledge of sign-magnitude, one's complement, and two's complement encoding.
@@ -20,9 +20,9 @@ Firstly, it's important to note that **numbers are stored in computers using the
The following diagram illustrates the conversions among sign-magnitude, one's complement, and two's complement:
![Conversions between Sign-Magnitude, One's Complement, and Two's Complement](number_encoding.assets/1s_2s_complement.png){ class="animation-figure" }
![Conversions between sign-magnitude, one's complement, and two's complement](number_encoding.assets/1s_2s_complement.png){ class="animation-figure" }
<p align="center"> Figure 3-4 &nbsp; Conversions between Sign-Magnitude, One's Complement, and Two's Complement </p>
<p align="center"> Figure 3-4 &nbsp; Conversions between sign-magnitude, one's complement, and two's complement </p>
Although sign-magnitude is the most intuitive, it has limitations. For one, **negative numbers in sign-magnitude cannot be directly used in calculations**. For example, in sign-magnitude, calculating $1 + (-2)$ results in $-3$, which is incorrect.
@@ -92,7 +92,7 @@ We can now summarize the reason for using two's complement in computers: with tw
The design of two's complement is quite ingenious, and due to space constraints, we'll stop here. Interested readers are encouraged to explore further.
## 3.3.2 &nbsp; Floating-Point Number Encoding
## 3.3.2 &nbsp; Floating-point number encoding
You might have noticed something intriguing: despite having the same length of 4 bytes, why does a `float` have a much larger range of values compared to an `int`? This seems counterintuitive, as one would expect the range to shrink for `float` since it needs to represent fractions.
@@ -129,9 +129,9 @@ $$
\end{aligned}
$$
![Example Calculation of a float in IEEE 754 Standard](number_encoding.assets/ieee_754_float.png){ class="animation-figure" }
![Example calculation of a float in IEEE 754 standard](number_encoding.assets/ieee_754_float.png){ class="animation-figure" }
<p align="center"> Figure 3-5 &nbsp; Example Calculation of a float in IEEE 754 Standard </p>
<p align="center"> Figure 3-5 &nbsp; Example calculation of a float in IEEE 754 standard </p>
Observing the diagram, given an example data $\mathrm{S} = 0$, $\mathrm{E} = 124$, $\mathrm{N} = 2^{-2} + 2^{-3} = 0.375$, we have:
@@ -145,7 +145,7 @@ Now we can answer the initial question: **The representation of `float` includes
As shown in the Table 3-2 , exponent bits $E = 0$ and $E = 255$ have special meanings, **used to represent zero, infinity, $\mathrm{NaN}$, etc.**
<p align="center"> Table 3-2 &nbsp; Meaning of Exponent Bits </p>
<p align="center"> Table 3-2 &nbsp; Meaning of exponent bits </p>
<div class="center-table" markdown>