I PRNG possono essere usati per comprimere magicamente roba?

Questa idea mi è venuta in mente da bambino che impara a programmare e al primo incontro con PRNG. Non so ancora quanto sia realistico, ma ora c'è lo scambio di stack.

Ecco uno schema di 14 anni per un incredibile algoritmo di compressione:

Prendi un PRNG e seminalo con seed sper ottenere una lunga sequenza di byte pseudo-casuali. Per trasmettere quella sequenza a un'altra parte, devi solo comunicare una descrizione del PRNG, il seme appropriato e la lunghezza del messaggio. Per una sequenza abbastanza lunga, tale descrizione sarebbe molto più breve della sequenza stessa.

Supponiamo ora di poter invertire il processo. Dato abbastanza tempo e risorse computazionali, potrei fare una ricerca della forza bruta e trovare un seme (e PRNG, o in altre parole: un programma) che produca la sequenza desiderata (diciamo una foto divertente di gatti maliziosi).

I PRNG si ripetono dopo che è stato generato un numero sufficiente di bit, ma rispetto ai cicli "tipici" il mio messaggio è piuttosto breve, quindi questo dosaggio non sembra un gran problema.

Voila, un modo efficace (se rube-goldbergiano) per comprimere i dati.

Quindi, supponendo:

• La sequenza che desidero comprimere è limitata e nota in anticipo.
• Non sono a corto di contanti o di tempo (solo se è richiesto un importo limitato di entrambi)

Mi piacerebbe sapere

• C'è un difetto fondamentale nel ragionamento alla base del regime?
• Qual è il modo standard per analizzare questo tipo di esperimenti mentali?

Sommario

Spesso le buone risposte chiariscono non solo la risposta, ma quello che stavo chiedendo davvero. Grazie per la pazienza di tutti e risposte dettagliate.

Ecco il mio ennesimo tentativo di riepilogo delle risposte:

• L'angolo PRNG / seed non contribuisce a nulla, non è altro che un programma che produce la sequenza desiderata come output.
• Il principio del buco del piccione: ci sono molti più messaggi di lunghezza> k di quanti siano i programmi (generazione di messaggi) di lunghezza <= k. Quindi alcune sequenze semplicemente non possono essere l'output di un programma più breve del messaggio.
• Vale la pena ricordare che l'interprete del programma (messaggio) è necessariamente fissato in anticipo. E il suo design determina il (piccolo) sottoinsieme di messaggi che può essere generato quando viene ricevuto un messaggio di lunghezza k.

A questo punto l'idea del PRNG originale è già morta, ma c'è almeno un'ultima domanda da risolvere:

• D: Potrei essere fortunato e scoprire che il mio messaggio lungo (ma finito) è solo l'output di un programma di lunghezza <k bit?

A rigor di termini, non è una questione di probabilità poiché il significato di ogni possibile messaggio (programma) deve essere conosciuto in anticipo. O è il significato di qualche messaggio di <k bit o non lo è .

Se scelgo un messaggio casuale di> = k bit in modo casuale (perché dovrei?), Avrei comunque una probabilità evanescente di poterlo inviare usando meno di k bit, e quasi la certezza di non essere in grado di inviare usando assolutamente meno di k bit.

OTOH, se scelgo un messaggio specifico di> = k bit da quelli che sono l'output di un programma inferiore a k bit (supponendo che ci sia un tale messaggio), allora in effetti sto sfruttando i bit già trasmessi al destinatario (il design dell'interprete), che conta come parte del messaggio trasferito.

Finalmente:

• D: Cos'è tutto questo business di complessità entropia / kolmogorov ?

Alla fine, entrambi ci dicono la stessa cosa del principio (più semplice) del buco del piccione ci dice su quanto possiamo comprimere: forse per niente, forse alcuni, ma certamente non tanto quanto immaginiamo (a meno che non imbrogliamo).

Hai un nuovo brillante schema di compressione, eh? Bene, allora ...

♫ Giochiamo tutti, il gioco dell'entropia ♫

Per essere semplice, suppongo che tu voglia comprimere i messaggi esattamente di bit, per alcuni n fissi . Tuttavia, vuoi essere in grado di usarlo per messaggi più lunghi, quindi hai bisogno di un modo per differenziare il tuo primo messaggio dal secondo (non può essere ambiguo ciò che hai compresso).$n$$n$

Quindi, il tuo schema è determinare una famiglia di PRNG / seed in modo tale che se vuoi comprimere, diciamo, , allora scrivi solo un numero k , che identifica un combo seed / PRNG precompilato (e condiviso) che genera quei bit dopo n query. Tutto apposto. Quante stringhe di bit diverse di lunghezza n ci sono? 2 n (puoi scegliere tra due voci; 0 e 1 ). Ciò significa che dovrai calcolare 2 n di queste combo. Nessun problema. Tuttavia, è necessario scrivere k in binario affinché io possa leggerlo. Quanto può arrivare k ? Bene, può essere grande quanto $01000111001$$k$$n$$n$$2^n$$0$$1$$2^n$$k$$k$ . Di quanti bit ho bisogno per scrivere 2 n ? log 2 n = n .$2^n$$2^n$$\log{2^n} = n$

Oops! Il tuo schema di compressione necessita di messaggi purché ciò che stai comprimendo!

"Haha!", Dici, "ma è nel peggiore dei casi! Uno dei miei messaggi sarà mappato su , che ha bisogno di solo 1 bit per rappresentare! Vittoria!"$0$$1$

Sì, ma i tuoi messaggi devono essere inequivocabili! Come posso distinguere seguito da 0 da 10 ? Poiché alcune delle tue chiavi sono lunghe n , devono essere tutte, altrimenti non posso dire da dove hai iniziato e fermato.$1$$0$$10$$n$

"Haha!", Dici, "ma posso solo mettere la lunghezza della stringa in binario prima! Questo deve solo contare fino a , che può essere rappresentato da log n bit! Quindi il mio 0 ora ha il prefisso con solo log n bit, vinco ancora! "$n$$\log{n}$$0$$\log{n}$

Sì, ma ora quei numeri veramente grandi sono preceduti da bit. Il tuo schema di compressione ha reso alcuni dei tuoi messaggi ancora più lunghi! E metà di tutti i tuoi numeri inizia con 1 , quindi metà dei tuoi messaggi è molto più lunga!$\log{n}$$1$

Procedi quindi a lanciare più idee come un carattere finale, comprimendo il numero e comprimendo la lunghezza stessa, ma tutti quelli si imbattono in casi in cui il messaggio risultante è solo più lungo. In effetti, per ogni bit salvato su qualche messaggio, un altro messaggio si allungherà in risposta. In generale, ti sposterai sul "costo" dei tuoi messaggi. Accorciare un po 'renderà altri più lunghi. Non puoi davvero inserire messaggi diversi in meno spazio rispetto alla scrittura di 2 n stringhe binarie di lunghezza n .$2^n$$2^n$$n$

"Haha!", Dici, "ma posso scegliere alcuni messaggi come" stupidi "e renderli illegali! Quindi non ho bisogno di contare fino a , perché non supporto così tanti messaggi!"$2^n$

Hai ragione, ma non hai davvero vinto. Hai appena ridotto la serie di messaggi supportati. Se supportato solo e b = 111.111.110.101.000 come i messaggi inviati, allora si può sicuramente basta avere il codice di un → 0 , b → 1 , che corrisponde esattamente quello che ho detto. Qui, n = 1 . La lunghezza effettiva dei messaggi non è importante, è quanti ce ne sono.$a=0000000011010$$b=111111110101000$$a\rightarrow 0$$b\rightarrow 1$$n=1$

"Haha!", Dici, "ma posso semplicemente determinare che quegli stupidi messaggi sono rari! Renderò quelli rari grandi e quelli comuni piccoli! Poi vincerò in media!"

Sì! Congratulazioni, hai appena scoperto l' entropia ! Se si dispone di messaggi, dove la i esima messaggio ha probabilità p i di essere inviato, allora si può ottenere la lunghezza messaggio previsto verso l'entropia H = Σ n i = 1 p i log ( 1 / p I ) di questo insieme di messaggi. È una specie di strana espressione, ma tutto quello che devi sapere è che è più grande quando tutti i messaggi sono ugualmente probabili e più piccoli quando alcuni sono più comuni di altri. All'estremo, se sai praticamente ogni messaggio sarà $n$$i$$p_i$$H = \sum_{i=1}^np_i\log(1/p_i)$ . Quindi puoi usare questo codice super efficiente: a → 0 , x → 1 x altrimenti. Allora la vostra lunghezza del messaggio previsto è fondamentalmente 1 , che è impressionante, e che sta per essere davvero vicino alla entropia H . Tuttavia, H ha un limite inferiore e non puoi davvero batterlo, non importa quanto ci provi.$a=000111010101$$a\rightarrow0$$x\rightarrow1x$$1$$H$$H$

Qualunque cosa che pretenda di battere l'entropia probabilmente non sta fornendo abbastanza informazioni per recuperare in modo inequivocabile il messaggio compresso, o è semplicemente sbagliata. L'entropia è un concetto così potente che possiamo limitare il limite (e talvolta anche il limite superiore ) del tempo di esecuzione di alcuni algoritmi con esso, perché se corrono molto velocemente (o molto lentamente), allora devono fare qualcosa che viola l'entropia .

Ci sono stringhe binarie di lunghezza inferiore a N , e 2 N stringhe binarie di lunghezza esattamente N . Ciò significa che qualunque sia il tuo algoritmo di compressione , ci deve essere una stringa che non può affatto comprimere, solo perché il mapping dalla stringa originale alla stringa compressa deve essere iniettivo (uno a uno). Questa è la forza trainante di molte applicazioni della complessità di Kolmogorov.$2^N-1$$N$$2^N$$N$

Nella vita reale, spesso sappiamo qualcosa sulla sequenza che stiamo comprimendo, diciamo che è la voce o un'immagine. Nel caso della compressione senza perdita, il teorema di codifica della sorgente di Shannon mostra che il tasso di compressione ottimale è uguale all'entropia della sorgente. Per la codifica con perdita di dati ci sono altri teoremi nella teoria dell'informazione (teoria della distorsione della frequenza). Quindi, anche in questo caso, esiste un limite a quanto è possibile comprimere i dati.

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

(Come notato un'altra risposta, questo accadrà per qualsiasi funzione di compressione scelta.)

Accanto ad altri punti già risolti, voglio solo aggiungere questo link: https://www.schneier.com:443/blog/archives/2009/09/the_doghouse_cr.html

Ora, la produzione di energia annuale del nostro sole è di circa 1,21 × 10 ^ 41 erg. Questo è sufficiente per alimentare circa 2,7 × 10 ^ 56 modifiche a bit singolo sul nostro computer ideale; abbastanza cambiamenti di stato per mettere un contatore a 187 bit attraverso tutti i suoi valori. Se costruissimo una sfera Dyson attorno al sole e catturassimo tutta la sua energia per 32 anni, senza alcuna perdita, potremmo alimentare un computer per contare fino a 2 ^ 192. Ovviamente, non sarebbe rimasta l'energia per eseguire calcoli utili con questo contatore.

Quindi solo iterare (senza confrontare ...) per trovare una costellazione valida a 187 bit dei dati desiderati richiederebbe in condizioni ideali (non raggiungibili) più energia di quella che il sole emette in un anno.

Una prova molto rapida che non può esistere un compressore universale. Supponiamo che tu ne faccia uno e comprimi un input. Ora comprimi iterativamente l'output del tuo programma. Se riesci sempre a ridurne le dimensioni, diventerà sempre più piccolo ad ogni passo, fino a quando non scendi a 1 bit.

Potresti sostenere che, forse, l'output del tuo algoritmo ha una struttura tale da non poter essere più compresso, ma poi potresti semplicemente applicare uno shuffle deterministico * prima di ricomprimerlo.

Nota a piè di pagina: alcuni shuffling deterministici aiutano effettivamente in alcuni schemi di compressione: http://pytables.github.io/usersguide/optimization.html?highlight=shuffling#shufflingoptim

L'uso di un PRNG per la "compressione" è sostanzialmente utile in una situazione: quando è necessario utilizzare un gruppo di dati "casuale" e registrare in modo compatto quali dati sono stati utilizzati. La maggior parte dei generatori pseudo-casuali può generare solo una minima parte delle possibili sequenze, ma se si necessita solo di un numero da piccolo a moderato di sequenze "casuali", la frazione di possibili sequenze che un PRNG può generare sarà spesso più che adeguata.

Se la sequenza di dati che si desidera archiviare accade coincidente per coincidenza con ciò che un determinato PRNG genererebbe dato il seme giusto, la memorizzazione del seme può essere un'alternativa compatta alla memorizzazione dei dati. A meno che la fonte di dati non sia tale che è probabile che si verifichino tali corrispondenze, tuttavia, sarebbero così rare che la ricerca di tali dati non sarebbe utile.

Qualcosa da considerare per aggiungere alla cacofonia di risposte che affermano perché ci sono alcune stringhe che non possono essere compresse a causa, per definizione, della natura iniettiva della decompressione e dell'universo limitato di stringhe compresse da cui selezionare per rappresentare i messaggi è questo: la maggior parte delle stringhe non può essere compressa perché ci sono molte più alte entropie, stringhe disordinate rispetto a quelle più basse e strutturate, dando quindi origine alla condizione che vediamo in pratica che: la compressione è il più delle volte utile, poiché i messaggi il più delle volte desiderano comprimere sono quelli più spesso possessivi di qualche aliquota di ordine e struttura, e per questo motivo, fanno parte dell'universo molto più piccolo di oggetti di entropia inferiore. Ciò significa che è possibile che, scegliendo una lunghezza di uscita adeguata, possiamo comprimere tutto nell'universo più piccolo e strutturato. Il termine strutturato, entropia e ordinato qui sono deliberatamente imprecisi, per riflettere le definizioni soggettive della semantica e dell'utilità dei messaggi che potremmo voler comprimere.

E in risposta diretta alla richiesta dell'interrogatore: * sì, ovviamente potresti semplicemente essere fortunato e scoprire che l'output del tuo PRNG è il messaggio esatto che desideri comprimere, è solo che così spesso non troverai questo è il caso perché la stessa proprietà che caratterizza un PRNG, vale a dire la sua capacità di produrre una varietà (quasi) infinita di stringhe diverse, rende concomitantemente improbabile produrre il tuo.

Ovviamente potresti mitigare questa improbabilità usando un PRNG per camminare su un "grafico di dominio" delle transizioni da parola a parola, e aumenti notevolmente la probabilità di apparizione del tuo messaggio, e scopri anche che ora devi aggiungere il grafico di dominio al messaggio compresso lunghezza.