Apakah ada maksimum yang diketahui untuk seberapa banyak string 0 dan 1 dapat dikompresi?

Beberapa waktu yang lalu saya membaca sebuah artikel surat kabar di mana seorang profesor mengatakan bahwa di masa depan kita akan dapat mengompres data menjadi hanya dua bit (atau sesuatu seperti itu).

Ini tentu saja tidak benar (dan bisa jadi ingatan saya tentang apa yang ia nyatakan tidak benar). Dapat dimengerti bahwa tidak praktis untuk mengompresi string apa pun dari 0 dan 1 menjadi hanya dua bit karena (bahkan jika secara teknis memungkinkan), terlalu banyak jenis string yang berbeda akan berakhir dengan mengompresi ke dua bit yang sama (karena kita hanya memiliki '01 'dan' 10 'untuk dipilih).

Lagi pula, ini membuat saya berpikir tentang kelayakan mengompresi string panjang sewenang-wenang 0 dan 1 menurut beberapa skema. Untuk string semacam ini, adakah hubungan yang diketahui antara panjang string (rasio antara 0 dan 1 mungkin tidak masalah) dan kompresi maksimum?

Dengan kata lain, apakah ada cara untuk menentukan berapa panjang minimum (sekecil mungkin) string yang dapat dikompresi menjadi 0 dan 1?

(Di sini saya tertarik pada kompresi maksimum matematis, bukan apa yang saat ini dimungkinkan secara teknis.)

Kompleksitas Kolmogorov adalah salah satu pendekatan untuk memformalkan ini secara matematis. Sayangnya, menghitung kompleksitas Kolmogorov dari suatu string adalah masalah yang tidak dapat diperhitungkan. Lihat juga: Mendekati kompleksitas Kolmogorov .

Dimungkinkan untuk mendapatkan hasil yang lebih baik jika Anda menganalisis sumber string daripada string itu sendiri . Dengan kata lain, seringkali sumber dapat dimodelkan sebagai proses probabilistik, yang secara acak memilih string, menurut beberapa distribusi. Entropi dari distribusi itu kemudian memberi tahu Anda kompresi matematis terbaik (hingga beberapa konstanta aditif kecil).

Pada ketidakmungkinan kompresi sempurna, Anda mungkin juga tertarik pada yang berikut ini.

• Tidak ada algoritma kompresi yang dapat mengompres semua pesan input?
• Fungsi kompresi hanya praktis karena "String bit yang terjadi dalam praktik jauh dari acak"?
• Apakah ada algoritma kompresi optimal yang terbukti secara teoritis?

$N$$\log_2 N$

Juga, dalam banyak kasus kami tidak peduli dengan rekonstruksi yang tepat . Ini disebut kompresi lossy , dan cara musik dan video dikompresi. Dalam hal ini, batas bawah yang disebutkan di atas tidak berlaku, tetapi Anda dapat membuat batas bawah lainnya.

Berikut adalah skema sederhana yang dapat mengompresi string bit sembarang lossless, dengan hasil terkecil menjadi hanya satu bit:

JIKA string adalah pasangan identik untuk merekam simfoni ke-9 Beethoven, gerakan keempat, dalam format AAC yang disimpan di hard drive komputer saya, maka outputnya adalah bit '0'.

JIKA string adalah hal lain, maka outputnya adalah bit tunggal '1', diikuti oleh salinan identik dari string asli.

Skema ini mengurangi satu input yang mungkin menjadi tepat satu bit, dan menambah panjang setiap input lainnya. Ada prinsip umum: Jika algoritma kompresi dapat memetakan string input apa pun ke string terkompresi, dan ada algoritma dekompresi yang cocok yang memetakan string terkompresi kembali ke string asli, dan algoritma kompresi memetakan setiap input ke string yang lebih pendek, maka harus memetakan beberapa string input ke string yang lebih panjang.

Untuk setiap skema kompresi yang dapat Anda buat, adalah mungkin untuk menghasilkan data yang tidak dapat dikompres olehnya. Jadi, bahkan jika skema kompresi Anda sangat efisien dengan beberapa jenis data, skema kompresi Anda tidak akan pernah konsisten ke rasio tertentu.

Cara untuk menghasilkan contoh data yang tidak dapat dikompres untuk algoritma kompresi tertentu adalah sederhana: ambil segala jenis data dan jalankan melalui algoritma kompresi berulang kali, hingga ukurannya tidak lagi berkurang.

Jadi kompresibilitas string bit tidak benar-benar fungsi dari panjang string, tetapi kompleksitasnya dalam kaitannya dengan algoritma kompresi.

Ada algoritma yang menarik dan sangat berbeda yang digunakan oleh sistem cadangan perusahaan. Idenya adalah bahwa jika Anda memiliki perusahaan dengan 10.000 komputer, maka banyak dari komputer ini akan berisi banyak file yang identik. Misalnya, email yang dikirim ke semua orang di perusahaan mungkin berakhir sebagai file yang identik pada setiap hard drive.

Jadi sistem cadangan yang mencoba membuat cadangan file jelas harus mencoba mengompres file untuk menghemat ruang, tetapi pertama-tama sistem cadangan memeriksa apakah file yang benar-benar identik sudah disimpan! Jadi, alih-alih mencadangkan apa pun , semua yang dilakukan sistem cadangan adalah misalnya mengingat bahwa Anda memiliki nomor file 1.487.578 pada sistem cadangan di hard drive Anda.

Ini sangat efisien misalnya ketika 10.000 pengguna semua memiliki sistem operasi dan aplikasi yang sama diinstal. Untuk pengguna tunggal itu tidak terlalu berguna sama sekali.