¿Cuál es la relación de compresión máxima teórica de datos altamente aleatorios, como la representación binaria del ruido blanco?

Los datos aleatorios son incompresibles.

Hay dos resultados relevantes:

  1. Independientemente del código que utilice, Shannon demostró que el número esperado de bits que necesita para representar algunos datos no puede ser menor que la entropía de la fuente de datos. Si la fuente es una distribución uniforme en, digamos, secuencias de dígitos binarios [math] n [/ math], entonces la entropía es igual a [math] n [/ math], por lo que en espera de su código, sea lo que sea, no comprimir
  2. Pero ese resultado está en expectativa; en la práctica, ¿no podemos tener suerte? Por ejemplo, si lanzo una moneda un millón de veces y por pura suerte todos ellos lanzan cara, entonces los datos serían comprimibles, ¿no? Bueno, sí, pero eso es extremadamente improbable: puede demostrar que la probabilidad de que pueda comprimir una cadena binaria aleatoria de cualquier longitud por [math] k [/ math] bits o más es menor que [math] 2 ^ {- k }[/mates]. Por lo tanto, la probabilidad de que pueda comprimir más de unos pocos bits es astronómicamente baja. Y para poder hacerlo, necesitaría usar un código que realmente expanda la mayoría de las entradas.

Los datos aleatorios son incompresibles.

Con eso fuera del camino, voy a tomar esta pregunta un poco más literalmente: ¿cuál es la relación de compresión máxima posible? Bueno, voy a lanzar una moneda [matemáticas] n [/ matemáticas] veces. Acordemos con el siguiente código: si todos los flips resultan en caras, entonces representaré este resultado con la secuencia binaria “0”. De lo contrario, representaré el resultado con la secuencia binaria “1”, seguida de todos los resultados de los lanzamientos de monedas. Ahora lanzo las monedas y ¿qué sabes? ¡Todos son cabezas! Eso significa que he comprimido los datos por un factor de [math] n [/ math]. Mejor que eso es imposible: mi palabra clave debe tener al menos un bit de largo, de lo contrario no puedo representar todos los demás resultados posibles. Así que todavía puedes tener una compresión extremadamente buena, pero como indican los resultados anteriores, tienes que ser muy afortunado por eso.

Todo depende del algoritmo.

Para cada algoritmo de compresión es posible construir la cadena, que no se “comprimiría”. Esto se debe a que diferentes algoritmos hacen suposiciones estadísticas específicas sobre los datos que comprimiría mejor.
Por ejemplo, Huffman / aritmética supone una distribución de símbolos no uniforme (uniforme generaría un árbol que en el mejor de los casos se asignaría a los mismos símbolos), LZ supone que habría secuencias repetidas (si no hay ninguna o rara vez o el diccionario no es lo suficientemente grande) tendríamos que volver a guardar los símbolos tal como están), RLE espera encontrar repeticiones de símbolos, etc.

Y viceversa, si lograra crear una cadena de un carácter, Huffman produciría 1 bit por símbolo, RLE sería el mejor, indicaría char y N de repeticiones, LZ estaría en algún lugar en el medio en términos de relación de compresión.

Volviendo a la compresión del ruido blanco: debe especificar la relación de compresión a partir del algoritmo que desea estimar y cuáles son las propiedades estadísticas relevantes de la secuencia comprimida.
Si desea un “algo de compresión genérico”, piense en eso: suponga que conoce la ley exacta que produjo el ruido blanco (como un buen PRNG), ¡entonces la compresión sería absoluta! Solo necesita saber el tipo de PRNG, la semilla, el desplazamiento inicial de la secuencia y la longitud, y reproducirá el resultado perfectamente, y la compresión (tamaño guardado / tamaño original) estaría cerca del 100%.