170: Parity: Simple And Fast Error Detection.

If you receive some information, how do you know if it’s intact or has been changed? Let me make this point clear from the beginning. Error detection only lets you detect errors. It doesn’t correct them. You have to provide other means to fix any errors. Usually this just means trying again. Parity works by including an extra bit for a small fixed number of data bits. You might want to include a parity bit for every byte or eight bits. This means that if you want to send a parity bit for every eight data bits, then you’ll really be sending and receiving nine bits instead of eight. The other option is to take a data bit away. Maybe you need to send information through a connection that can only support a fixed number of bits. You can’t just add an extra bit. So instead, what you do is devote one of the bits as the parity bit. This leaves you with one fewer bits to use for your actual data. Okay, so how does parity actually work? It sets or clears the parity bit in order to make the total number of bits with the value of 1 be either even or odd. Setting a bit just means to make its value one. And clearing a bit just means to make its value zero. Listen to the full episode or read the full transcript below for more details on parity. Transcript When I was little, my school teacher asked the class to form a line and relay a message from one kid to the next. Everybody thought it was funny that the message at the end was nothing like how it started. Some kids would forget parts, some would leave parts out because they thought it wasn’t important, and some would add new things based on what they thought they heard. It’s amazing how closely programming resembles real life. I know I say that a lot. But it’s true! You might think a computer won’t forget things, or choose to leave things out. And how could a computer make up it’s own story? Well, these things do happen. And we need a way to detect them. Let me make this point clear from the beginning. Error detection only lets you detect errors. It doesn’t correct them. You have to provide other means to fix any errors. Usually this just means trying again. Where can errors enter your application? It’s easy to understand where the errors come from in a line of kids. How about computers? Computers are a lot more reliable today than they used to be and they’re getting better. I remember when hard drives had a sticker that listed all the bad sectors. Those were places on the disk known to have defects. The worst part was the label had empty spots. Room to add your own bad sectors. I would run utilities every few months that would scan the entire disk. It would write data and make sure the same data could be read back again. Sometimes a value would be written and a different value read back. That was a bad sector and would have to be avoided because it was unreliable. Over time as I found new spots on the disk that were bad, I would write down the locations on the sticker. Even though we don’t have to go through this anymore, there can still be errors when reading or writing data. Usually, once data is loaded into a computer, it’ll stay there. But nothing is absolute. It’s possible for data in memory to fail to be written properly or even to change. Not likely, but possible. You’re much more likely to get errors when sending information from one computer to another. I’ve been talking about this a lot since episode 159. And we have protocols designed to deal with errors. But so far, I haven’t described how to actually detect when an error occurs. Let’s start with a simple example. You want to send two binary bits and they’re both zeros. What possible results can you expect? Well, first of all, you might actually get what was sent. But how do you know that it’s correct? What if you receive 01 instead? Was that what was sent? What if you only receive a single 0? Or mayb