ECC edits

src/Advanced/Error-Correcting Codes/parts/00 detection.tex

@@ -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}

src/Advanced/Error-Correcting Codes/parts/02 hamming.tex

@@ -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