3blue1brown explica con su habitual representacion gráfica como funcionan los códigos de Hamming, uno de los pilares del almacenamiento y transmisión de información, ya que permiten detectar y corregir los errores que se producen por diversas razones. Parte de la magia de los códigos de Hamming es su eficiencia: Por ejemplo usando bloques de 256 bits, es suficiente con usar 9 de ellos para control de errores, quedando los otros 247 para los datos en si. Si uno de los bits en los datos cambia, es posible detectar y corregir el error.
#2 Ya te digo. Cogí como optativa una asignatura en la que se trataba esto entre otros tipos de codificación y era una pasada todo lo que se había desarrollado (hablo de hace ya décadas) para prevenir la transmisión errónea de datos o más bien corregirlos en la llegada.
En particular recuerdo dos detalles. Uno que me dejó fue conocer, si recuerdo bien, que en lo que es un cd de datos, con sus 650-700 megas de capacidad, en realidad entre una cosa y otra se escriben 2,1GB en él, lo que está cerca de la capacidad nominal de un dvd.
El otro fue la práctica que había que programar y luego defender. Consistía en simular la transmisión de un archivo con ruido en la línea, de manera que se introducían errores que después había que corregir y ver cómo funcionaba. Una chorrada de código.
Sin embargo el día de la defensa de la práctica el profesor, haciendo su trabajo, al archivo que yo tenía de ejemplo le añadió al final unas cuantas líneas aleatoriamente, unas vacías, otras con letras repetidas. Lo hizo para asegurarse de que no se le hacían trampas, claro. A mí me dio igual porque sabía que funcionaba.
Excepto que la primera vez que lo ejecutó "no funcionó". Es decir, sí funcionó pero sucedió que tras pasar por la simulación de ruido y la pertinente corrección de errores, en algún punto del texto extra que añadió el profesor se interpretó lo que debiera ser una letra cualquiera como un EOF (para el neófito: End Of File, la marca que dice que el fichero se acaba aquí). Por tanto aunque el programa funcionaba, el archivo resultante no era lo que debiera ser, le faltaba un trozo.
Tuve que ejecutar la simulación una segunda vez para demostrarle que funcionaba
Y sí, a toro pasado es algo fácil de darse cuenta y tiene arreglo trivial (enviar antes del archivo el valor del tamaño, esperando que eso se reciba bien, si eso enviándolo varias veces y coger el valor que más se repita como referencia para no parar antes de llegar a él y poner que cada EOF que llegue antes de llegar al tamaño de archivo nuevo es un error de transmisión. Porque, sí, en la práctica tu sabes si has acabado la simulación pero en el mundo real no) pero la gotita de sudor por la frente la tuve, no sé si literal pero la tuve.
#6 No le acabo de ver yo la utilidad a eso. Puedes tener un ejemplo con unos pocos bits para ver el funcionamiento y que te quede en la cabeza, pero hacerlo como ejercicio es ridículo.
#8 Más allá de hacer un ejemplo o dos con tres o cuatro bits, si eso mejor cuatro que se ve más fácil aunque parezca que es más, suficiente. Lo de tenerlo como ejercicio es tedioso y no sirve para nada, es algo que está bien saber pero está precisamente diseñado para que lo hagan las máquinas. No es como hacer divisiones y multiplicaciones que, con números "pequeños", tiene su utilidad que las sepas hacer de cabeza y las practiques.
Comentarios
Me encanta este canal
¿Esto tiene que ver con los ficheros *.rev? No hablo inglés, pero tiene toda la pinta.
Que recuerdos de la universidad...
#2 Ya te digo. Cogí como optativa una asignatura en la que se trataba esto entre otros tipos de codificación y era una pasada todo lo que se había desarrollado (hablo de hace ya décadas) para prevenir la transmisión errónea de datos o más bien corregirlos en la llegada.
En particular recuerdo dos detalles. Uno que me dejó fue conocer, si recuerdo bien, que en lo que es un cd de datos, con sus 650-700 megas de capacidad, en realidad entre una cosa y otra se escriben 2,1GB en él, lo que está cerca de la capacidad nominal de un dvd.
El otro fue la práctica que había que programar y luego defender. Consistía en simular la transmisión de un archivo con ruido en la línea, de manera que se introducían errores que después había que corregir y ver cómo funcionaba. Una chorrada de código.
Sin embargo el día de la defensa de la práctica el profesor, haciendo su trabajo, al archivo que yo tenía de ejemplo le añadió al final unas cuantas líneas aleatoriamente, unas vacías, otras con letras repetidas. Lo hizo para asegurarse de que no se le hacían trampas, claro. A mí me dio igual porque sabía que funcionaba.
Excepto que la primera vez que lo ejecutó "no funcionó". Es decir, sí funcionó pero sucedió que tras pasar por la simulación de ruido y la pertinente corrección de errores, en algún punto del texto extra que añadió el profesor se interpretó lo que debiera ser una letra cualquiera como un EOF (para el neófito: End Of File, la marca que dice que el fichero se acaba aquí). Por tanto aunque el programa funcionaba, el archivo resultante no era lo que debiera ser, le faltaba un trozo.
Tuve que ejecutar la simulación una segunda vez para demostrarle que funcionaba
Y sí, a toro pasado es algo fácil de darse cuenta y tiene arreglo trivial (enviar antes del archivo el valor del tamaño, esperando que eso se reciba bien, si eso enviándolo varias veces y coger el valor que más se repita como referencia para no parar antes de llegar a él y poner que cada EOF que llegue antes de llegar al tamaño de archivo nuevo es un error de transmisión. Porque, sí, en la práctica tu sabes si has acabado la simulación pero en el mundo real no) pero la gotita de sudor por la frente la tuve, no sé si literal pero la tuve.
#5 En la academia nos hacían detectar y corregir errores en este tipo de códigos A MANO (evidentemente no secuencias demasiado largas)
#6 No le acabo de ver yo la utilidad a eso. Puedes tener un ejemplo con unos pocos bits para ver el funcionamiento y que te quede en la cabeza, pero hacerlo como ejercicio es ridículo.
#7 Bueno, ayuda a "abrir" la mente.
#8 Más allá de hacer un ejemplo o dos con tres o cuatro bits, si eso mejor cuatro que se ve más fácil aunque parezca que es más, suficiente. Lo de tenerlo como ejercicio es tedioso y no sirve para nada, es algo que está bien saber pero está precisamente diseñado para que lo hagan las máquinas. No es como hacer divisiones y multiplicaciones que, con números "pequeños", tiene su utilidad que las sepas hacer de cabeza y las practiques.
#9 El perfil de mis estudios era técnico, no ingeniería.
#10 No se me ocurre cómo puede ser útil tener que hacer ejercicios sobre códigos de Hamming, la verdad.
CRC.
Vendo Opel Corsa.