174: Error Correction: Hamming Distance And Codes.

Take Up Code - A podcast by Take Up Code: build your own computer games, apps, and robotics with podcasts and live classes

Categorie:

How do you correct errors once you identify them? I’ve explained a lot already about error detection. Make sure to listen to the last several episodes for more information. Detecting errors is the first step and the most important. I mean, if you don’t know that something went wrong, then you’re not even going to try fixing it, right? If you’re sending a file over a network and you detect an error, usually, the easiest way to correct the error is to throw away what you received and ask for the sender to retransmit the part that was bad. You shouldn’t need to start over from the beginning unless the data you’re sending is so small that it already fits in a single packet of data. What if you can’t retransmit the data? Either because it’s gone or impractical to transmit again. Maybe there’s a single source of data that’s being sent to hundreds or thousands of recipients in real time. You can’t expect the sender to stop and retransmit information each time a recipient complains that it didn’t receive the correct information. One thing to consider is what effect would this have on the recipient. Is it okay to just ignore the problem? If you’re sending audio, then maybe you can ignore some data without the listener even noticing. You can do this as long as you have some data before and after the error. That’s because even though you may not know the exact missing value or values, you can probably guess what the data would likely have been. Another technique you can use to correct errors uses Hamming codes that have enough Hamming distance between them that you can guess which value was likely sent. Make sure to listen to the full episode for examples and more explanation. There’s even an example of how our brains do error correction everytime we look at something. Or you can also read the full transcript below. Transcript I’ve explained a lot already about error detection. Make sure to listen to the last several episodes for more information. Detecting errors is the first step and the most important. I mean, if you don’t know that something went wrong, then you’re not even going to try fixing it, right? If you’re sending a file over a network and you detect an error, usually, the easiest way to correct the error is to throw away what you received and ask for the sender to retransmit the part that was bad. You shouldn’t need to start over from the beginning unless the data you’re sending is so small that it already fits in a single packet of data. What if you can’t retransmit the data? Either because it’s gone or impractical to transmit again. Maybe there’s a single source of data that’s being sent to hundreds or thousands of recipients in real time. You can’t expect the sender to stop and retransmit information each time a recipient complains that it didn’t receive the correct information. One thing to consider is what effect would this have on the recipient. Is it okay to just ignore the problem? If you’re sending audio, then maybe you can ignore some data without the listener even noticing. You can do this as long as you have some data before and after the error. That’s because even though you may not know the exact missing value or values, you can probably guess what the data would likely have been. Let me give you an example. Let’s say that I send you the values 1, 2, 3, then an error causes you to throw away the next value. After that, you get the values 5 and 6. This is an easy example because all the values you did get form a straight line and it’s likely that the missing value would be 4. Just imagine listening to somebody counting and you sneeze right when they say 4. You could fill in the missing 4 with no problem. Now, it’s always possible that the other person made a mistake and counted 1, 2, 3, 8, 5, 6. And this shows that correct

Visit the podcast's native language site