¿Por qué la relación de compresión usando bzip2 para una secuencia de "a" s es tan nerviosa?

library(ggplot2)

compress <- function(str) {
  length(memCompress(paste(rep("a", str), collapse=""), type="bzip2"))
  / nchar(paste(rep("a", str), collapse=""))
}

cr <- data.frame(i = 1:10000, r = sapply(1:10000, compress))

ggplot(cr[cr$i>=5000 & cr$i<=10000,], aes(x=i, y=r)) + geom_line()

La relación de compresión comienza en 37 para "a" y alcanza el punto de equilibrio en 39 "a" s (relación de compresión = 1). El gráfico comienza bastante suave y se pone nervioso de repente por 98 "a" sy desde allí a intervalos cada vez más pequeños.

Los bajos locales y las secciones lisas también parecen bastante erráticas y aleatorias. ¿Alguien puede explicarme por qué bzip2 muestra este comportamiento en este ejemplo?

a$(\text{header}, \mathtt{\text{"a"}}, n)$a$n$$a + \lg n$$a$$\dfrac{a + \lg(n)}{n}$$\Theta(\lg(n)^p/n)$$p \ge 1$

$\lg n$$n$$a$$n$$a+1$$a+2$$\dfrac{a}{n}$$\dfrac{a+1}{n}$$\dfrac{a+2}{n}$

Dado que la relación de compresión es demasiado cercana a la relación inversa de la longitud para la observación visual, aquí están los datos para una longitud pequeña en mi implementación (esto puede depender de la versión de la biblioteca bzip2, ya que hay varias formas de comprimir algunas entradas ) La primera columna indica el número de a's, la segunda columna es la longitud de la salida comprimida.

1–3       37
4–99      39
100–115   37
116–258   39
259–354   45
355       43
356       40
357–370   41
371–498   43
499–513   41
514–609   45
610       43
611       41
613–625   42
626–753   44
754–764   42
765       40
766–767   41
768       42
769–864   45
…

Bzip2 es mucho más complejo que una simple codificación de longitud de ejecución. Funciona en una serie de pasos, y el primer paso es un paso de codificación de longitud de ejecución , pero con un límite de tamaño fijo. El primer paso funciona de la siguiente manera: si un byte se repite al menos 4 veces, reemplace los bytes después del 4to por un byte que indica el recuento repetido de los bytes borrados. Por ejemplo, aaaaaaase transforma en aaaa\d{3}(donde \d{003}está el carácter con el valor de byte 3); aaaase transforma a aaaa\d{0}, y así sucesivamente. Como solo hay 256 valores de bytes distintos, solo las secuencias en las que el byte se repite hasta 259 veces se pueden codificar de esta manera; si hay más, comienza una nueva secuencia. Además, la implementación de referencia se detiene en un recuento repetido de 252, que codifica una cadena de 256 bytes.

$\mathtt{a}^n$$1 \le n \le 3$$4 \le n \le 258$aaaa\d{252}\d{252} es el recuento de repetición, no lo he comprobado) se repite y, por lo tanto, se comprime en pasos posteriores.

aaaa\374aa$n=258$a

$n=100$$\mathtt{a}^{101}$aaaa\d{97}aaaaaa$n=101$aA$68 \le n \le 83$

Mi análisis de este ejemplo está lejos de ser exhaustivo. Para comprender otros efectos, tendría que estudiar los otros pasos de la transformación: principalmente me detuve después del paso 1 de 9. Espero que esto le dé una idea de por qué las relaciones de compresión se vuelven un poco irregulares y no varían monotónicamente. Si realmente desea descubrir cada detalle, le recomiendo tomar una implementación existente y observarla con un depurador.

En su mayor parte, tales variaciones diminutas no son el foco principal al diseñar un algoritmo de compresión: en muchos escenarios comunes, como los algoritmos de compresión de medios generales o de propósito general, una diferencia de unos pocos bytes es irrelevante. La compresión trata de exprimir cada bit a nivel local, y trata de encadenar las transformaciones de tal manera que gane a menudo mientras raramente pierde y luego no por mucho. No obstante, existen situaciones como protocolos de comunicación de propósito especial diseñados para la comunicación de bajo ancho de banda donde cada bit importa. Otra situación en la que la longitud de salida exacta es importante es cuando el texto comprimido se cifra: cuando un adversario puede enviar parte del texto para ser comprimido y cifrado, las variaciones en la longitud del texto cifrado pueden revelar la parte del texto comprimido y cifrado a el adversarioCRIMEN explotar en HTTPS .