he receiving end is simple: We look at our 80 bits and check all 16 row and column sums. If they all match, then we are happy with the 64 bits. If just one row or one column is wrong, then we assume that it is a 1-bit error in a parity column or row, and we are still happy with the 64 bits. If one row and one column are each wrong, then we assume that the single bit at the in- tersection of that row and that column is wrong. We flip the bit, and we are happy with the corrected 64 bits. Finally, if more than one row or more than one column is wrong, then we conclude that there is more than one error, shrug our shoulders, and do whatever our system does with unresolvable errors. We may take an educated guess with some likelihood of being right, or we may report some kind of error condition depending on our data system's architec- ture and needs. A system sending real-time voice or video has to send something, even if it is wrong. If two errors are rare enough in this eight-by-eight matrix, then the wrong sound is sent, but the problem is small enough to be disregarded. On the other hand, a computer file transfer system likely will be better off reporting irrecoverable errors and having the data resent. In this case, the computer system relying on this eight-by-eight matrix error-correcting system would have limited FEC plus additional error recovery. FEC would suffice to ensure accurate transmission in the case of a single error in one ma- trix. Error recovery with a request for retransmission would be used as the fallback in case there were two errors in a single matrix. We can measure our bit error rate (BER), therefore, by counting the number of times our error correction has to resolve an error and the number of times it cannot resolve an error. Occasionally there will be a set of errors that cancel each other out, the sys- tem is fooled, and the wrong 64 bits are sent without our knowledge. However, this does not happen very often even with this primitive error-correction scheme. The mathe- matical structure o