Чому коефіцієнт стиснення використовує bzip2 для послідовності "a", настільки стриманою?

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

Коефіцієнт стиснення починається з 37 для "a" і досягає беззбитковості при 39 "a" s (коефіцієнт стиснення = 1). Діаграма починається досить гладко і раптово стає різкою на 98 "а", а звідти з все меншими інтервалами.

Місцеві мінімуми та гладкі ділянки здаються також досить хаотичними та випадковими. Чи може хтось мені пояснити, чому bzip2 показує таку поведінку в цьому прикладі?

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

Оскільки коефіцієнт стиснення занадто близький до оберненого відношення довжини для візуального спостереження, ось дані невеликої довжини в моїй реалізації (це може залежати від версії бібліотеки bzip2, оскільки існує кілька способів стиснення деяких входів ). Перший стовпець вказує число as, другий стовпець - довжину стисненого виводу.

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 набагато складніше , ніж просте кодування довжиною виконання. Вона працює в серії кроків, і перший крок - це крок кодування довжиною пробігу , але з фіксованим обмеженням розміру. Перший крок працює наступним чином: якщо байт повторюється щонайменше 4 рази, то замініть байти після 4-го байтом, що вказує на кількість повторень стираних байтів. Наприклад, aaaaaaaперетворюється на aaaa\d{3}(де \d{003}символ із значенням байта 3); aaaaперетворюється на aaaa\d{0}тощо. Оскільки існує лише 256 різних байт-значень, таким чином можуть бути закодовані лише послідовності, де байт повторюється до 259 разів; якщо їх більше, починається свіжа послідовність. Крім того, реалізація посилань зупиняється на кількості повторень 252, що кодує рядок у 256 байт.

$\mathtt{a}^n$$1 \le n \le 3$$4 \le n \le 258$aaaa\d{252}\d{252} це кількість повторень, я не перевіряв), сам повторюється і тому стискається наступними кроками.

aaaa\374aa$n=258$a

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

Мій аналіз цього прикладу далеко не вичерпний. Щоб зрозуміти інші ефекти, вам доведеться вивчити інші кроки трансформації: я здебільшого зупинився після кроку 1 з 9. Я сподіваюся, що це дає вам уявлення про те, чому коефіцієнти стиснення стають трохи хиткими і не змінюються монотонно. Якщо ви дійсно хочете розібратися в кожній деталі, рекомендую взяти існуючу реалізацію та спостерігати за нею відладчиком.

Здебільшого такі хвилинні варіації не є головним фокусом при розробці алгоритму стиснення: у багатьох загальних сценаріях, таких як алгоритми стиснення загального призначення або медіа, різниця в кілька байтів не має значення. Стиснення намагається витіснити кожен шматочок на місцевому рівні і намагається ланцюг трансформацій таким чином, щоб часто отримувати, хоча рідко втрачаючи, а потім не сильно. Тим не менш, існують такі ситуації, як протоколи зв'язку спеціального призначення, призначені для зв'язку з низькою пропускною здатністю, де кожен біт має значення. Інша ситуація, коли має значення точна довжина виводу, коли стислий текст шифрується: коли противник може подати частину тексту для стискання та шифрування, зміни в довжині шифротексту можуть виявити частину стисненого та зашифрованого тексту противник;ЗЛИЧНИЙ експлуатуйте на HTTPS .