Bisakah PRNG digunakan untuk mengompresi benda secara ajaib?

Gagasan ini muncul pada saya sebagai seorang anak yang belajar memprogram dan pada awalnya menghadapi PRNG. Saya masih tidak tahu seberapa realistis itu, tapi sekarang ada pertukaran tumpukan.

Berikut skema anak berusia 14 tahun untuk algoritma kompresi yang luar biasa:

Ambil PRNG dan seed dengan seed suntuk mendapatkan urutan panjang pseudo-random byte. Untuk mengirimkan urutan itu ke pihak lain, Anda hanya perlu mengkomunikasikan deskripsi PRNG, seed yang sesuai dan panjang pesan. Untuk urutan yang cukup panjang, deskripsi itu akan jauh lebih pendek daripada urutan itu sendiri.

Sekarang anggaplah saya bisa membalikkan prosesnya. Dengan cukup waktu dan sumber daya komputasi, saya bisa melakukan pencarian dengan kekuatan besar dan menemukan benih (dan PRNG, atau dengan kata lain: program) yang menghasilkan urutan yang saya inginkan (Katakanlah foto lucu kucing yang nakal).

PRNG mengulangi setelah sejumlah besar bit telah dihasilkan, tetapi dibandingkan dengan siklus "tipikal" pesan saya cukup pendek sehingga hal ini sepertinya bukan masalah besar.

Voila, cara efektif (jika rube-Goldbergian) mengompres data.

Jadi, dengan asumsi:

• Urutan yang ingin saya kompres terbatas dan diketahui sebelumnya.
• Saya tidak kekurangan uang tunai atau waktu (Asalkan jumlah terbatas keduanya diperlukan)

Saya ingin tahu:

• Apakah ada kelemahan mendasar dalam alasan di balik skema ini?
• Apa cara standar untuk menganalisis eksperimen pemikiran semacam ini?

Ringkasan

Sering kali jawaban yang baik menjelaskan tidak hanya jawabannya, tetapi apa yang sebenarnya saya tanyakan. Terima kasih atas kesabaran semua orang dan jawaban terinci.

Inilah usaha saya yang ke-1 untuk ringkasan jawaban:

• Sudut PRNG / seed tidak berkontribusi apa-apa, itu tidak lebih dari sebuah program yang menghasilkan urutan yang diinginkan sebagai output.
• Prinsip pigeonhole: Ada lebih banyak pesan panjang> k daripada ada program (menghasilkan pesan) panjang <<k. Jadi beberapa urutan tidak bisa menjadi keluaran dari program yang lebih pendek dari pesan.
• Perlu disebutkan bahwa penerjemah program (pesan) harus diperbaiki terlebih dahulu. Dan desainnya menentukan subset pesan (kecil) yang dapat dihasilkan ketika pesan dengan panjang k diterima.

Pada titik ini ide PRNG asli sudah mati, tetapi setidaknya ada satu pertanyaan terakhir untuk diselesaikan:

• T: Bisakah saya beruntung dan menemukan bahwa pesan panjang (tapi terbatas) saya kebetulan merupakan hasil dari program dengan panjang <k bit?

Sebenarnya, ini bukan masalah kebetulan karena makna dari setiap pesan (program) yang mungkin harus diketahui sebelumnya. Entah itu adalah arti dari beberapa pesan dari <k bit atau tidak .

Jika saya memilih pesan acak> = k bit secara acak (mengapa saya harus melakukannya?), Dalam kasus apa pun saya akan memiliki kemungkinan lenyap untuk dapat mengirimnya menggunakan kurang dari k bit, dan hampir pasti tidak dapat mengirim itu sama sekali menggunakan kurang dari k bit.

OTOH, jika saya memilih pesan spesifik> = k bit dari yang merupakan output dari program kurang dari k bit (dengan asumsi ada pesan seperti itu), maka pada dasarnya saya mengambil keuntungan dari bit yang sudah dikirim ke penerima (desain interpreter), yang dianggap sebagai bagian dari pesan yang ditransfer.

Akhirnya:

• T: Apa semua bisnis kompleksitas entropi / kolmogorov ini ?

Pada akhirnya, keduanya memberi tahu kita hal yang sama dengan prinsip lubang pancang (yang lebih sederhana) memberi tahu kita tentang seberapa banyak kita dapat mengompres: mungkin tidak sama sekali, mungkin beberapa, tetapi tentu saja tidak sebanyak yang kita sukai (kecuali kita menipu).

Anda punya skema kompresi baru yang brilian, eh? Baiklah kalau begitu...

♫ Ayo kita semua bermain, game entropi ♫

Sederhananya, saya akan menganggap Anda ingin mengompres pesan dengan tepat bit, untuk beberapa n tetap . Namun, Anda ingin dapat menggunakannya untuk pesan yang lebih lama, jadi Anda perlu cara membedakan pesan pertama dari yang kedua (tidak bisa mendua dengan apa yang telah Anda kompres).$n$$n$

Jadi, skema Anda adalah untuk menentukan beberapa keluarga PRNG / benih sehingga jika Anda ingin mengompres, katakanlah, , maka Anda cukup menulis beberapa angka k , yang mengidentifikasi beberapa combo seed / PRNG yang telah dikomputasi (dan dibagi) yang menghasilkan bit-bit tersebut setelah n pertanyaan. Baik. Berapa banyak bit-string panjang n yang ada? 2 n (Anda memiliki n pilihan antara dua item; 0 dan 1 ). Itu berarti Anda harus menghitung 2 n dari kombo ini. Tidak masalah. Namun, Anda perlu menulis k dalam biner agar saya membacanya. Seberapa besar k dapat? Yah, itu bisa sebesar $01000111001$$k$$n$$n$$2^n$$0$$1$$2^n$$k$$k$ . Berapa bit yang harus saya tuliskan 2 n ? log 2 n = n .$2^n$$2^n$$\log{2^n} = n$

Ups! Skema kompresi Anda membutuhkan pesan selama apa yang Anda kompres!

"Haha!", Katamu, "tapi itu dalam kasus terburuk! Salah satu pesanku akan dipetakan ke , yang hanya membutuhkan 1 bit untuk diwakili! Kemenangan!"$0$$1$

Ya, tetapi pesan Anda harus jelas! Bagaimana saya membedakan diikuti oleh 0 dari 10 ? Karena beberapa kunci Anda panjang n , semuanya harus, atau saya tidak tahu di mana Anda memulai dan berhenti.$1$$0$$10$$n$

"Haha!", Katamu, "tapi aku hanya bisa meletakkan panjang string dalam biner dulu! Itu hanya perlu dihitung menjadi , yang dapat diwakili oleh log n bits! Jadi 0 saya sekarang datang diawali dengan hanya log n bit, aku masih menang! "$n$$\log{n}$$0$$\log{n}$

Ya, tetapi sekarang angka-angka yang sangat besar diawali dengan bit n . Skema kompresi Anda telah membuat beberapa pesan Anda bahkan lebih lama! Dan setengah dari semua angka Anda dimulai dengan 1 , jadi setengah dari pesan Anda lebih lama!$\log{n}$$1$

Anda kemudian melanjutkan untuk mengeluarkan lebih banyak ide seperti karakter penghentian, gzipping nomor, dan mengompresi panjang itu sendiri, tetapi semua itu berjalan ke dalam kasus di mana pesan yang dihasilkan hanya lebih lama. Bahkan, untuk setiap bit yang Anda simpan pada beberapa pesan, pesan lain akan mendapat respons lebih lama. Secara umum, Anda hanya akan bergeser di sekitar "biaya" pesan Anda. Membuat beberapa lebih pendek hanya akan membuat orang lain lebih lama. Anda benar-benar tidak dapat memasukkan pesan yang berbeda dalam ruang yang lebih sedikit daripada menulis 2 n string biner dengan panjang n .$2^n$$2^n$$n$

"Haha!", Anda berkata, "tapi aku bisa memilih beberapa pesan sebagai 'bodoh' dan membuat mereka! Ilegal Lalu aku tidak perlu menghitung semua jalan ke , karena saya tidak mendukung bahwa banyak pesan!"$2^n$

Anda benar, tetapi Anda belum benar-benar menang. Anda baru saja menyusut set pesan yang Anda dukung. Jika Anda hanya mendukung dan b = 111111110101000 sebagai pesan yang Anda kirim, maka Anda pasti dapat memiliki kode a → 0 , b → 1 , yang cocok persis dengan apa yang saya katakan. Di sini, n = 1 . Panjang sebenarnya dari pesan itu tidak penting, ada berapa banyak.$a=0000000011010$$b=111111110101000$$a\rightarrow 0$$b\rightarrow 1$$n=1$

"Haha!", Katamu, "tapi aku bisa dengan mudah menentukan bahwa pesan-pesan bodoh itu langka! Aku akan membuat yang langka itu besar, dan yang umum kecil! Lalu aku menang rata-rata!"

Ya! Selamat, Anda baru saja menemukan entropi ! Jika Anda memiliki pesan, di mana saya pesan th memiliki probabilitas p i menjadi pengirimannya, maka Anda bisa mendapatkan panjang pesan diharapkan Anda ke entropi H = Σ n i = 1 p i log ( 1 / p i ) dari himpunan ini pesan. Itu semacam ekspresi aneh, tetapi yang perlu Anda ketahui adalah itu yang terbesar ketika semua pesan memiliki kemungkinan yang sama, dan lebih kecil ketika beberapa lebih umum daripada yang lain. Dalam ekstrim, jika Anda tahu pada dasarnya setiap pesan akan menjadi $n$$i$$p_i$$H = \sum_{i=1}^np_i\log(1/p_i)$ . Kemudian Anda dapat menggunakan kode super efisien ini: a → 0 , x → 1 x sebaliknya. Kemudian panjang pesan diharapkan Anda pada dasarnya 1 , yang mengagumkan, dan itu akan menjadi benar-benar dekat dengan entropi H . Namun, H adalah batas bawah, dan Anda benar-benar tidak dapat mengalahkannya, tidak peduli seberapa keras Anda mencoba.$a=000111010101$$a\rightarrow0$$x\rightarrow1x$$1$$H$$H$

Apa pun yang mengklaim mengalahkan entropi mungkin tidak memberikan informasi yang cukup untuk secara jelas mengambil pesan terkompresi, atau hanya salah. Entropy adalah suatu konsep yang sangat kuat sehingga kita dapat membatasi waktu berjalan (dan kadang-kadang bahkan batas atas ) beberapa algoritma dengan itu, karena jika mereka berjalan sangat cepat (atau sangat lambat), maka mereka harus melakukan sesuatu yang melanggar entropi .

$2^N-1$$N$$2^N$$N$

Dalam kehidupan nyata, kita sering tahu sesuatu tentang urutan yang kita tekan, katakan itu suara atau gambar. Dalam kasus kompresi lossless, teorema pengkodean sumber Shannon menunjukkan bahwa tingkat kompresi optimal sama dengan entropi sumber. Untuk pengkodean lossy ada teorema lain dalam teori informasi (teori tingkat-distorsi). Jadi, bahkan dalam kasus ini ada batasan seberapa banyak Anda dapat mengompres data.

$s$$k$$2^k$$n$$2^n$$n$$s$

(Seperti jawaban lain dicatat, ini akan terjadi untuk fungsi kompresi yang Anda pilih.)

Selain poin-poin lain yang sudah dijawab, saya hanya ingin menambahkan tautan ini: https://www.schneier.com:443/blog/archives/2009/09/the_doghouse_cr.html

Sekarang, keluaran energi tahunan matahari kita adalah sekitar 1,21 × 10 ^ 41 erg. Ini cukup untuk memberi daya sekitar 2,7 × 10 ^ 56 perubahan bit tunggal pada komputer ideal kami; cukup perubahan status untuk menempatkan penghitung 187-bit melalui semua nilainya. Jika kita membangun bola Dyson mengelilingi matahari dan menangkap semua energinya selama 32 tahun, tanpa kehilangan apa pun, kita dapat menyalakan komputer untuk menghitung hingga 2 ^ 192. Tentu saja, itu tidak akan memiliki energi yang tersisa untuk melakukan perhitungan yang berguna dengan penghitung ini.

Jadi hanya iterasi (tanpa perbandingan ...) untuk menemukan konstelasi 187bit yang valid dari data yang Anda inginkan akan mengambil kondisi ideal (tidak dapat dicapai) lebih banyak energi daripada yang dipancarkan matahari selama setahun.

Bukti yang sangat cepat bahwa kompresor universal tidak ada. Misalkan Anda memang membuatnya, dan Anda mengompres input. Sekarang, kompres secara konsisten output dari program Anda. Jika Anda selalu dapat mengurangi ukuran, itu akan semakin kecil di setiap langkah, sampai Anda turun ke 1 bit.

Anda bisa berargumen bahwa, mungkin, output dari algoritma Anda memiliki struktur sedemikian rupa sehingga tidak dapat dikompresi lebih banyak, tetapi kemudian Anda bisa menerapkan shuffle deterministik * sebelum melakukan kompresi ulang.

Catatan Kaki: Beberapa pengocokan deterministik sebenarnya membantu dalam beberapa skema kompresi: http://pytables.github.io/usersguide/optimization.html?highlight=shuffling#shufflingoptim

Penggunaan PRNG untuk "kompresi" pada dasarnya berguna dalam satu situasi: ketika perlu menggunakan sekelompok data "acak" dan secara kompak merekam data apa yang digunakan. Sebagian besar generator pseudo-acak hanya dapat menghasilkan sebagian kecil dari sekuens yang mungkin, tetapi jika seseorang hanya membutuhkan sekuens "acak" yang kecil hingga sedang, fraksi sekuens yang mungkin dihasilkan oleh PRNG akan sering lebih dari cukup.

Jika urutan data yang ingin disimpan terjadi secara kebetulan untuk mencocokkan apa yang akan dihasilkan oleh PRNG tertentu dengan benih yang tepat, menyimpan benih mungkin merupakan alternatif yang ringkas untuk menyimpan data. Namun, kecuali jika sumber datanya sedemikian rupa sehingga kecocokan tersebut mungkin terjadi, mereka akan sangat jarang sehingga pencarian mereka tidak akan bermanfaat.

Sesuatu yang perlu dipertimbangkan untuk menambah hiruk-pikuk jawaban yang menegaskan mengapa ada beberapa string yang tidak dapat dikompresi karena, menurut definisi, sifat injeksi dekompresi, dan alam semesta terbatas string terkompresi dari mana untuk memilih untuk mewakili pesan adalah ini: sebagian besar string tidak dapat dikompresi karena ada sangat banyak entropi lebih tinggi, string tidak teratur daripada ada yang lebih rendah entropi dan terstruktur, oleh karena itu menimbulkan kondisi yang kita lihat dalam praktek bahwa: kompresi sebagian besar waktu berguna, karena pesan kami yang paling sering ingin dikompres adalah yang paling sering memiliki beberapa alikuot tatanan dan struktur, dan dengan ini, merupakan bagian dari alam semesta yang jauh lebih kecil dari objek entropi rendah. Ini berarti ada kemungkinan bahwa, dengan memilih panjang keluaran yang sesuai, kita dapat memampatkan segala sesuatu di alam semesta yang lebih kecil dan terstruktur. Istilah terstruktur, entropi dan dipesan di sini sengaja tidak tepat, untuk mencerminkan definisi subjektif dari semantik dan kegunaan pesan yang mungkin ingin kita kompres.

Dan sebagai jawaban langsung atas permintaan si penanya: * ya, Anda tentu saja bisa saja beruntung dan menemukan hasil PRNG Anda adalah pesan persis yang ingin Anda kompres, hanya saja Anda begitu sering tidak akan menemukan ini masalahnya karena properti yang mencirikan PRNG, yaitu, kemampuannya untuk menghasilkan berbagai (hampir) variasi string yang tak berujung, membuatnya secara bersamaan tidak suka memproduksi milik Anda.

Tentu saja Anda dapat mengurangi kemungkinan yang tidak disukai ini dengan menggunakan PRNG untuk menjelajahi "grafik domain" dari transisi kata ke kata, dan Anda sangat meningkatkan kemungkinan kemunculan pesan Anda, dan juga sekarang Anda harus menambahkan grafik domain ke pesan yang dikompresi. panjangnya.