Perché il rapporto di compressione utilizza bzip2 per una sequenza di "a" è così instabile?

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()

Il rapporto di compressione inizia da 37 per "a" e raggiunge il pareggio a 39 "a" s (rapporto di compressione = 1). Il grafico inizia abbastanza liscio e diventa improvvisamente tagliente per 98 "a" se da lì a intervalli sempre più piccoli.

I bassi locali e le sezioni lisce sembrano anche abbastanza irregolari e casuali. Qualcuno può spiegarmi perché bzip2 mostra questo comportamento in questo esempio?

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}$

Poiché il rapporto di compressione è troppo vicino al rapporto inverso della lunghezza per l'osservazione visiva, ecco i dati per una piccola lunghezza nella mia implementazione (questo potrebbe dipendere dalla versione della libreria bzip2, poiché ci sono diversi modi per comprimere alcuni input ). La prima colonna indica il numero di a's, la seconda colonna è la lunghezza dell'output compresso.

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 è molto più complesso di una semplice codifica di lunghezza. Funziona in una serie di passaggi e il primo è un passaggio di codifica di lunghezza di esecuzione , ma con un limite di dimensioni fisse. Il primo passaggio funziona nel modo seguente: se un byte viene ripetuto almeno 4 volte, sostituire i byte dopo il 4 con un byte che indica il conteggio delle ripetizioni dei byte cancellati. Ad esempio, aaaaaaaviene trasformato in aaaa\d{3}(dove si \d{003}trova il carattere con valore byte 3); aaaaviene trasformato in aaaa\d{0}e così via. Poiché ci sono solo 256 valori di byte distinti, solo le sequenze in cui il byte viene ripetuto fino a 259 volte possono essere codificate in questo modo; se ce ne sono altri, inizia una nuova sequenza. Inoltre, l'implementazione di riferimento si interrompe con un conteggio ripetuto di 252, che codifica una stringa di 256 byte.

$\mathtt{a}^n$$1 \le n \le 3$$4 \le n \le 258$aaaa\d{252}\d{252} è il conteggio delle ripetizioni, non ho verificato) viene ripetuto e quindi compresso dai passaggi successivi.

aaaa\374aa$n=258$a

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

La mia analisi di questo esempio è lungi dall'essere esaustiva. Per capire altri effetti, dovresti studiare gli altri passaggi della trasformazione: mi sono fermato per lo più dopo il passaggio 1 di 9. Spero che questo ti dia un'idea del perché i rapporti di compressione diventano un po 'instabili e non variano monotonicamente. Se vuoi davvero capire ogni dettaglio, ti consiglio di prendere un'implementazione esistente e osservarla con un debugger.

Per la maggior parte, tali minime variazioni non sono al centro dell'attenzione nella progettazione di un algoritmo di compressione: in molti scenari comuni, come algoritmi di compressione generici o multimediali, una differenza di pochi byte è irrilevante. La compressione cerca di spremere ogni bit a livello locale e cerca di incatenare le trasformazioni in modo tale da ottenere spesso mentre raramente perde e quindi non di molto. Esistono tuttavia situazioni come protocolli di comunicazione per scopi specifici progettati per la comunicazione a larghezza di banda ridotta in cui ogni bit è importante. Un'altra situazione in cui la lunghezza esatta dell'output è importante è quando il testo compresso è crittografato: quando un avversario può inviare parte del testo da comprimere e crittografare, le variazioni della lunghezza del testo cifrato possono rivelare la parte del testo compresso e crittografato a l'avversario; Exploit CRIME su HTTPS .