Deletion edits
All checks were successful
CI / Typst formatting (pull_request) Successful in 6s
CI / Typos (pull_request) Successful in 7s
CI / Build (pull_request) Successful in 8m34s

This commit is contained in:
Mark 2025-02-11 19:32:20 -08:00
parent 61a43e11ec
commit cda52d83d7
2 changed files with 44 additions and 6 deletions

View File

@ -19,7 +19,7 @@ Only one of the following ISBNs is valid. Which one is it?
\begin{itemize}
\item \texttt{0-134-54896-2}
\item \texttt{0-895-77258-2}
\item \texttt{0-895-77258-2} % oliver twist
\end{itemize}
\begin{solution}
@ -67,18 +67,19 @@ This is called a \textit{transposition error}.
\vfill
\pagebreak
\problem{}
\definition{}
ISBN-13 error checking is slightly different. Given a partial ISBN-13 $n_1 n_2 n_3 ... n_{12}$, the final digit is given by
$$
n_{13} = \Biggr[ \sum_{i=1}^{12} n_i \times (2 + (-1)^i) \Biggl] \text{ mod } 10
$$
\problem{}
What is the last digit of the following ISBN-13? \par
\texttt{978-0-380-97726-?}
\texttt{978-030-7292-06*} % foundation
\begin{solution}
The final digit is 0.
The final digit is 3.
\end{solution}
\vfill
@ -127,7 +128,7 @@ Take a valid ISBN-13 and swap two adjacent digits. When will the result be a val
\vfill
\problem{}<isbn-nocorrect>
\texttt{978-0-08-2066-46-6} was a valid ISBN until I changed a single digit. \par
\texttt{978-008-2066-466} was a valid ISBN until I changed a single digit. \par
Can you find the digit I changed? Can you recover the original ISBN?
\begin{solution}

View File

@ -570,8 +570,45 @@ If we know which parity bits are inconsistent, how can we find where the error i
\vfill
\problem{}<generalize-hamming>
Can you generalize this system for messages of 4, 64, or 256 bits?
Generalize this system for messages of 4, 64, or 256 bits. \par
\begin{itemize}
\item How does the resilience of this scheme change if we use a larger message size?
\item How does the efficiency of this scheme change if we send larger messages?
\end{itemize}
\vfill
\pagebreak
\definition{}
A \textit{deletion} error occurs when one bit of the message is deleted. \par
Likewise, an \textit{insertion} error consists of a random inserted bit. \par
\definition{}
A \textit{message stream} is an infinite string of binary digits.
\problem{}
Show that Hamming codes do not reliably detect bit deletions: \par
\hint{
Create a 17-bit message whose first 16 bits are a valid Hamming block, \par
and which is still valid when a bit (chosen by you; not the $17^\text{th}$) is deleted.
}
\vfill
\problem{}
Convince yourself that Hamming codes cannot correct insertions. \par
Then, create a 16-bit message that...
\begin{itemize}
\item is a valid Hamming block, and
\item incorrectly "corrects" a single bit error when it encounters an insertion error.
\end{itemize}
\vfill
As we have seen, Hamming codes effectively handle substitutions, but cannot reliably
detect (or correct) insertions and deletions. Correcting those errors is a bit more difficult:
if the number of bits we receive is variable, how can we split a stream into a series of messages? \par
\note{This is a rhetorical question, which we'll discuss another day.}
\pagebreak