Warum ist die Komprimierungsrate bei Verwendung von bzip2 für eine Folge von "a" so sprunghaft?

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

Das Kompressionsverhältnis beginnt bei 37 für "a" und erreicht die Gewinnschwelle bei 39 "a" (Kompressionsverhältnis = 1). Das Diagramm beginnt ziemlich glatt und wird plötzlich für 98 "a" s und von dort in immer kleineren Intervallen nervös.

Die lokalen Tiefs und glatten Abschnitte wirken ebenfalls recht unregelmäßig und zufällig. Kann mir jemand erklären, warum bzip2 dieses Verhalten in diesem Beispiel zeigt?

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

Da das Komprimierungsverhältnis für die visuelle Beobachtung dem inversen Verhältnis der Länge zu nahe kommt, sind hier die Daten für die kleine Länge in meiner Implementierung (dies kann von der Version der bzip2-Bibliothek abhängig sein, da es mehrere Möglichkeiten gibt, einige Eingaben zu komprimieren ). Die erste Spalte gibt die Anzahl der an a, die zweite Spalte die Länge der komprimierten Ausgabe.

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 ist weitaus komplexer als eine einfache Lauflängencodierung. Es funktioniert in einer Reihe von Schritten, und der erste Schritt ist ein Schritt für die Lauflängencodierung , jedoch mit einer festen Größenbeschränkung. Der erste Schritt funktioniert wie folgt: Wenn ein Byte mindestens viermal wiederholt wird, ersetzen Sie die Bytes nach dem vierten durch ein Byte, das die Anzahl der Wiederholungen der gelöschten Bytes angibt. Zum Beispiel aaaaaaawird transformiert nach aaaa\d{3}(wo \d{003}ist das Zeichen mit dem Bytewert 3); aaaaverwandelt sich in aaaa\d{0}und so weiter. Da es nur 256 verschiedene Bytewerte gibt, können nur Sequenzen, in denen das Byte bis zu 259 Mal wiederholt wird, auf diese Weise codiert werden. Wenn mehr vorhanden sind, beginnt eine neue Sequenz. Darüber hinaus stoppt die Referenzimplementierung bei einer Wiederholungszahl von 252, die eine Zeichenfolge von 256 Bytes codiert.

$\mathtt{a}^n$$1 \le n \le 3$$4 \le n \le 258$aaaa\d{252}\d{252} ist die Wiederholungszahl, die ich nicht überprüft habe) wird selbst wiederholt und daher durch nachfolgende Schritte komprimiert.

aaaa\374aa$n=258$a

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

Meine Analyse dieses Beispiels ist alles andere als erschöpfend. Um andere Effekte zu verstehen, müssten Sie sich mit den anderen Schritten der Transformation befassen: Ich hörte meistens nach Schritt 1 von 9 auf. Ich hoffe, dies gibt Ihnen eine Vorstellung davon, warum die Komprimierungsverhältnisse etwas unruhig werden und nicht monoton variieren. Wenn Sie wirklich jedes Detail herausfinden möchten, empfehle ich, eine vorhandene Implementierung zu übernehmen und mit einem Debugger zu beobachten.

Meist sind solche winzigen Abweichungen nicht das Hauptaugenmerk beim Entwerfen eines Komprimierungsalgorithmus: In vielen gängigen Szenarien, z. B. Allzweck- oder Medienkomprimierungsalgorithmen, ist ein Unterschied von wenigen Bytes irrelevant. Die Komprimierung versucht, jedes Bit auf lokaler Ebene herauszudrücken und Transformationen so zu verketten, dass sie oft gewinnen, selten verlieren und dann nicht viel. Es gibt jedoch Situationen, in denen jedes Bit wichtig ist, z. B. spezielle Kommunikationsprotokolle für die Kommunikation mit geringer Bandbreite. Eine andere Situation, in der es auf die genaue Ausgabelänge ankommt, ist, wenn der komprimierte Text verschlüsselt wird: Wenn ein Gegner einen Teil des zu komprimierenden und zu verschlüsselnden Textes übermitteln kann, können Variationen der Länge des Chiffretextes den Teil des komprimierten und verschlüsselten Textes preisgeben der Gegner;CRIME- Exploit auf HTTPS .