Comprensione della compressione / codifica in tempo lineare

Sto leggendo l'articolo NJ Larsson, A. Moffat: Compressione basata su dizionario offline , che descrive un algoritmo di compressione che, se lo capisco correttamente, è abbastanza simile alla codifica delle coppie di byte .

Dato una stringa $S$ di lunghezza $n$ , Sto cercando di capire come comprimerlo in modo lineare, $\mathcal O (n)$ , tempo con questo metodo di compressione. Com'è fatto esattamente? Ho letto il documento, ma ancora non capisco come raggiungono il tempo lineare, quindi forse lo capirei spiegato in un modo diverso.

La mia prima confusione sorge nel primo passo dell'algoritmo, in cui troviamo la coppia più comune, ad esempio nella abcababcabccoppia più comune absarebbe sostituita da un nuovo simbolo, diciamo XcXXcXc. Non capisco come possiamo trovare la coppia più comune abbastanza rapidamente. Il mio approccio ingenuo sarebbe quello di guardare prima la prima coppia abe poi contare il numero di occorrenze, quindi guardare la coppia successiva bce contare il numero di occorrenze, ecc. Tuttavia questo già darebbe $\mathcal O (n^2)$ solo per trovare la coppia più comune una volta .

Successivamente, anche se ho capito come trovare la coppia più comune in $\mathcal O(n)$ tempo. Il mio prossimo problema è che, non dobbiamo trovare la coppia più comune fino a $\mathcal O(n)$ volte? E quindi questo darebbe un tempo totale di $\mathcal O(n^2)$ ?

— Eff
fonte

Dovresti porre una domanda più specifica. Ribadire un documento con parole diverse sembra estendersi a questo sito. In quale punto degli articoli ti perdono gli autori?

— adrianN,

@adrianN Ho scritto un po 'di più su ciò che in particolare sono confuso.

— Eff

Il documento ha ipotizzato che utilizzerà la tabella hash e lo ha contato come

O (n)

$\mathcal O(n)$ , che in questo caso potrebbe essere wlog sostituito dall'albero del suffisso

O (n)

$\mathcal O(n)$ . Ho appena sfogliato il testo, la tua domanda è ancora molto impegnativa, ma non vedo davvero perché dovresti spendere

O (n^{2})

$\mathcal O(n^2)$ solo per un oggetto.

— Male

@Evil Quindi stai dicendo che si potrebbe costruire un albero di suffissi

S

$S$ in

Θ (n)

$\Theta (n)$ tempo (A proposito, non riesco ancora a capire quando è possibile costruire un albero di suffissi in tempo lineare e quando ci vuole

O (n \log n)

$\mathcal O (n\log n)$ ). Quindi troviamo la sottostringa più frequente nell'albero dei suffissi in

Θ (n)

$\Theta (n)$ tempo. Corretta?

— Eff

Me? No. Ma Ukkonen ha detto qualche parola al riguardo.

O (n)

$\mathcal O(n)$ per alfabeto di dimensioni costanti e

O (n \log n)

$\mathcal O(n\log n)$ in generale. Quindi possiamo ordinare in base alle frequenze

O (n \log n)

$\mathcal O(n\log n)$ o persino sfruttare piccoli numeri naturali per contare l'ordinamento. Non sono sicuro che qualcosa sia 1 ~ n

Θ (n)

$\Theta(n)$ , scusa nessuna risposta per quella parte.

— Male

Ho controllato il codice, ho riletto il foglio e sembra che l'algoritmo non funzioni $\mathcal O(n)$ nel modo in cui hai descritto.
Le chiamate ricorsive di trovare coppie funzionano $\mathcal O(n \log n)$ diviso per costante se si desidera imballarlo fino alla fine. In effetti la struttura sottostante mantiene i puntatori alla prima occorrenza della coppia, suddivide la coda delle coppie per occorrenze per renderla efficiente, ma comunque loglineare. D'altra parte analizzando il codice scritto da Ph.D. studente dell'autore ho scoperto diversi trucchi: la lunghezza delle coppie (il nome originale) è indicata come parametro (il valore predefinito è 2) e la ricorrenza è limitata dal parametro, che può scartare ulteriori chiamate (il valore predefinito è di circa 5 livelli), con capacità di fare solo un passaggio o spingere fino alla fine. Viene eseguito il codice predefinito $\mathcal O(n)$ , ma non produrrà una compressione ottimale. C'è anche un interruttore per preferire memoria, tempo o essere neutro.

L'articolo e il codice mostrano l'uso dell'hash-table, che viene eseguito solo nel tempo costante previsto, ma la funzione fornita funziona molto bene con i caratteri. Inoltre, il codice limita la lunghezza dell'input mediante costante hardcoded.

Cambiare la tabella hash in suffisso dell'albero e riscrivere la parte della ricorrenza in coppie parziali di contabilità potrebbe produrre risultati migliori - Non sono sicuro che sia possibile farlo $\mathcal O(n)$ , questa sarebbe probabilmente una domanda diversa.

C'è anche un trucco usato per evitare che lo spazio vuoto si attraversi: l'inizio del blocco vuoto punta al primo carattere non vuoto, ma questo accelera solo l'attraversamento, sempre con il tempo loglineare. La parte responsabile di questo comportamento sta sostituendo le coppie con il nuovo carattere ogni iterazione - mantenere solo le regole di riscrittura e operare su di esse sarebbe più veloce, ma comunque l'accesso per verificare se fossero state introdotte nuove coppie richiederebbe di controllare le regole di riscrittura con quelle nuove - nel caso in cui costruiamo un albero binario completo con coppie alle foglie in modo tale che dopo aver sostituito le coppie con un nuovo personaggio e averlo concordato con il genitore abbiamo ottenuto nuove coppie alle foglie fino alla radice - ci sono $n$ chat quindi $\frac{n}{2}$ coppie, quindi $\frac{n}{4}$ , $\frac{n}{8}$ , $\frac{n}{16}$ ... Vedi lo schema, ci sono $2n$ coppie, ma in base alla descrizione dell'algoritmo ciò si verifica $\mathcal O(n\log n + n)$ prendendo tempo solo traversali di input.

— il male
fonte