Sıkıştırma oranı neden bir “a” dizisi için bzip2'yi kullanıyor?

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

Sıkıştırma oranı "a" için 37'de başlar ve 39 "a" s'de başabaşa vurur (sıkıştırma oranı = 1). Grafik oldukça pürüzsüz başlar ve 98 "a" s için aniden ve giderek daha küçük aralıklarla sinirli olur.

Yerel alçak ve düzgün bölümler de oldukça düzensiz ve rastgele görünüyor. Birisi bana bzip2'nin bu davranışı neden bu örnekte gösterdiğini açıklayabilir mi?

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

Sıkıştırma oranı, görsel gözlem için uzunluğun ters oranına çok yakın olduğundan, burada uygulamanızdaki küçük uzunluk için veriler var (bu, bazı girişleri sıkıştırmanın birden fazla yolu olduğundan, bzip2 kütüphanesinin sürümüne bağlı olabilir. ). İlk sütun a' sayısını , ikinci sütun sıkıştırılmış çıktının uzunluğunu gösterir.

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, basit bir çalışma uzunluğu kodlamasından çok daha karmaşıktır . Bir dizi adımda çalışır ve ilk adım, çalışma boyu kodlama adımıdır , ancak sabit bir boyut sınırına sahiptir. İlk adım şu şekilde çalışır: bir bayt en az 4 kez tekrarlanırsa, 4. bayttan sonraki baytları, silinen baytların tekrar sayısını gösteren bir bayt ile değiştirin. Örneğin, aaaaaaadönüştürülür aaaa\d{3}(burada \d{003}bayt değeri 3 olan karakter); aaaadönüşür aaaa\d{0}, vb. Yalnızca 256 farklı bayt değeri olduğundan, sadece baytın 259 kata kadar tekrarlandığı diziler bu şekilde kodlanabilir; daha fazlası varsa, yeni bir dizi başlar. Ayrıca, referans uygulaması 256 baytlık bir dizeyi kodlayan 252 tekrar sayımında durur.

$\mathtt{a}^n$$1 \le n \le 3$$4 \le n \le 258$aaaa\d{252}\d{252} tekrarlama sayısıdır, kontrol etmedim) kendisi tekrarlanır ve bu nedenle sonraki adımlarla sıkıştırılır.

aaaa\374aa$n=258$a

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

Bu örnekle ilgili analizlerim kapsamlı olmaktan çok uzak. Diğer etkileri anlamak için, dönüşümün diğer adımlarını incelemeniz gerekir: Çoğunlukla 9'un 1. adımından sonra durdum. Umarım bu, sıkıştırma oranlarının neden biraz dalgalı hale geldiğini ve tekdüze değişmediğini size gösterir. Her ayrıntıyı gerçekten anlamak istiyorsanız, mevcut bir uygulamayı almanızı ve bir hata ayıklayıcı ile gözlemlemenizi öneririz.

Çoğunlukla, bir sıkıştırma algoritması tasarlanırken bu tür küçük değişiklikler ana odak noktası değildir: genel amaçlı veya medya sıkıştırma algoritmaları gibi birçok yaygın senaryoda, birkaç bayt arasındaki fark önemsizdir. Sıkıştırma, yerel düzeyde her bir parçayı sıkıştırmaya çalışır ve dönüşümleri nadiren kaybederken ve çok fazla değil, sık sık kazanacak şekilde zincirlemeye çalışır. Bununla birlikte, her bitin önemli olduğu düşük bant genişliğinde iletişim için tasarlanmış özel amaçlı iletişim protokolleri gibi durumlar vardır. Çıktı uzunluğunun önemli olduğu diğer bir durum, sıkıştırılmış metnin şifrelenmiş olmasıdır: Bir rakip, sıkıştırılacak ve şifrelenecek metnin bir kısmını gönderebiliyorsa, şifre metninin uzunluğundaki değişiklikler, sıkıştırılmış ve şifrelenmiş metnin düşman;SUÇ istismar üzerine HTTPS .