Perché la codifica di Huffman elimina l'entropia che Lempel-Ziv non fa?

Il popolare algoritmo DEFLATE utilizza la codifica Huffman in cima a Lempel-Ziv.

In generale, se disponiamo di una fonte di dati casuale (= 1 bit entropia / bit) , è probabile che nessuna codifica, incluso Huffman, li comprima in media. Se Lempel-Ziv fosse "perfetto" (che si avvicina alla maggior parte delle classi di fonti, poiché la lunghezza va all'infinito), la codifica post con Huffman non sarebbe di aiuto. Certo, Lempel-Ziv non è perfetto, almeno con una lunghezza finita, e quindi rimane un po 'di ridondanza.

È questa ridondanza residua che la codifica di Huffman elimina parzialmente e quindi migliora la compressione.

La mia domanda è: perché questa ridondanza residua viene eliminata con successo dalla codifica Huffman e non da LZ? Quali proprietà di Huffman contro LZ fanno sì che ciò accada? Semplicemente eseguendo nuovamente LZ (ovvero codificando i dati compressi LZ con LZ una seconda volta) si otterrebbe qualcosa di simile? In caso contrario, perché no? Allo stesso modo, prima comprimere con Huffman e poi con LZ funzionerebbe, e se no, perché?

AGGIORNAMENTO: È chiaro che anche dopo LZ rimarrà un po 'di ridondanza. Diverse persone hanno sottolineato questo punto. Ciò che non è chiaro è: perché la ridondanza residua è meglio affrontata da Huffman che da LZ? Cosa c'è di unico in contrasto con la ridondanza della sorgente originale, in cui LZ funziona meglio di Huffman?

Questo era originariamente un commento, ma è diventato troppo lungo.

Se guardi DEFLATE, ciò che viene compresso da Huffman è l'output di LZ77; LZ77 funziona (quando richiede meno bit rispetto ai dati non elaborati) inviando un puntatore prima nella stringa da comprimere e una lunghezza della corrispondenza che indica quanti simboli assumere dopo il puntatore. La teoria mostra che, anche senza ulteriore compressione, questa tecnica alla fine converge all'entropia di origine. Tuttavia, nella compressione dei dati, ogni volta che si dispone di una distribuzione non completamente casuale, è possibile comprimerlo. Non c'è motivo di credere che l'output di LZ77 — i puntatori e le lunghezze delle corrispondenze — siano completamente casuali. Devono convergere per completare la casualità nel limite asintotico, poiché LZ77 è asintoticamente ottimale, ma in pratica si utilizza solo un dizionario finito, quindi presumibilmente rimangono abbastanza lontani dall'essere completamente casuali da vincere vincendo ulteriormente su di essi. Naturalmente, usi un codice Huffman per i puntatori e un altro per le lunghezze delle partite, poiché questi due processi hanno statistiche diverse.

Perché usare Huffman anziché LZ per il secondo round di compressione? Il grande vantaggio che LZ ha su Huffman è nel trattare le dipendenze tra i simboli. In inglese, se una lettera è una 'q', è molto probabile che la successiva sia una 'u', e così via. Se i simboli sono eventi indipendenti, allora Huffman è più semplice e funziona altrettanto bene o meglio per stringhe brevi. Per l'output di LZ77, la mia intuizione è che i simboli dovrebbero essere abbastanza indipendenti, quindi Huffman dovrebbe funzionare meglio.

La compressione dei dati riguarda due cose: la modellazione e la codifica. Gli algoritmi della famiglia LZ modellano il testo come una concatenazione di ripetizioni esatte, che è asintoticamente ottimale per molte fonti casuali e ragionevolmente buono per molti testi reali. Per alcuni input, tuttavia, questo modello può essere piuttosto negativo. Ad esempio, non è possibile utilizzare LZ per comprimere direttamente una matrice di suffissi, anche se la matrice di suffissi è comprimibile come il testo originale.

$(p, \ell, c)$$p$$\ell$$c$

$\log n$$n$

Quindi in breve, Huffman batte LZ nel comprimere le tuple, poiché il suo modello (distribuzione fissa vs. ripetizioni esatte) è una corrispondenza migliore per i dati.

Credo che la risposta risieda nella dimensione del dizionario di ricerca.

I dati hanno un senso di localizzazione (vale a dire, se un dato è stato utilizzato, è probabile che verrà utilizzato di nuovo presto) e l'algoritmo LZ ne approfitta nella costruzione del dizionario di ricerca. Genera un trie con una quantità finita di possibili nodi, per mantenere le ricerche veloci . Quando raggiunge il limite di dimensione, crea un altro trie, "dimenticando" quello precedente. Quindi deve ricostruire la tabella di ricerca per i caratteri più semplici, ma se alcune parole non vengono più utilizzate, non vengono più conservate in memoria, quindi è possibile utilizzare una codifica più piccola.

Pertanto, un output LZ può essere ulteriormente ridotto con la codifica Huffman, poiché questa ridondanza nella creazione dei tentativi di ricerca può essere rilevata mediante analisi statistiche.

Forse sono fuori strada qui, ma la codifica di Huffman guarda l'intero input per costruire la sua tabella di codifica (albero), mentre Lempel-Ziv codifica mentre procede. Questo è sia un vantaggio che uno svantaggio per Huffman. Lo svantaggio è ovvio, vale a dire che dobbiamo vedere l'intero input prima di poter iniziare. Il vantaggio è che Huffman terrà conto delle statistiche che si verificano in qualsiasi punto dell'input, mentre Lempel-Ziv deve svilupparsi progressivamente. O per dirla in modo diverso, Lempel-Ziv ha una "direzione" che Huffman non ha.

Ma tutto questo è solo il mio modo ingenuo di immaginare come stanno le cose. Avremmo bisogno di una vera prova qui per vedere come esattamente Huffman supera Lempel-Ziv.

La risposta breve è che LZ è un algoritmo "universale" in quanto non ha bisogno di conoscere l'esatta distribuzione della fonte (ha solo bisogno di supporre che la fonte sia stazionaria ed ergodica). Ma Huffman non lo è; deve conoscere l'esatta distribuzione da cui viene campionato l'origine (per creare l'albero di Huffman). Queste informazioni aggiuntive consentono a Huffman di ottenere strette garanzie di compressione. Tuttavia, per gli algoritmi di compressione dei file pratici, Huffman potrebbe essere meno favorevole poiché dovrà prima raccogliere statistiche empiriche del file e quindi eseguire la compressione effettiva nella seconda metà, mentre LZ può essere implementato online.

Maggiori dettagli sono disponibili nei testi di teoria dell'informazione standard, ad esempio Elements of Information Theory di Cover e Thomas.