Implementazione efficiente di Trie per stringhe unicode

Ho cercato un'implementazione efficiente di String trie. Principalmente ho trovato un codice come questo:

Implementazione referenziale in Java (per Wikipedia)

Non mi piacciono queste implementazioni per principalmente due motivi:

1. Supportano solo 256 caratteri ASCII. Devo coprire cose come il cirillico.
2. Sono estremamente inefficienti dalla memoria.

Ogni nodo contiene una matrice di 256 riferimenti, ovvero 4096 byte su una macchina a 64 bit in Java. Ognuno di questi nodi può avere fino a 256 nodi secondari con 4096 byte di riferimenti ciascuno. Quindi un Trie completo per ogni stringa di caratteri ASCII 2 richiederebbe un po 'più di 1 MB. Tre stringhe di caratteri? 256 MB solo per array nei nodi. E così via.

Ovviamente non ho intenzione di avere tutti i 16 milioni di tre stringhe di caratteri nel mio Trie, quindi molto spazio è solo sprecato. La maggior parte di questi array sono solo riferimenti null poiché la loro capacità supera di gran lunga il numero effettivo di chiavi inserite. E se aggiungo Unicode, gli array diventano ancora più grandi (char ha 64k valori invece di 256 in Java).

C'è qualche speranza di creare un trie efficiente per le corde? Ho preso in considerazione un paio di miglioramenti rispetto a questi tipi di implementazioni:

• Invece di usare una matrice di riferimenti, potrei usare una matrice di tipo intero primitivo, che indicizza in una matrice di riferimenti a nodi la cui dimensione è vicina al numero di nodi effettivi.
• Potrei spezzare le stringhe in parti a 4 bit che consentirebbero array di nodi di dimensione 16 al costo di un albero più profondo.

Per cosa stai usando questo trie? Qual è il numero totale di parole che prevedi di contenere e qual è la scarsità dei loro caratteri costitutivi? E, cosa più importante, un trie è persino appropriato (rispetto a una semplice mappa del prefisso all'elenco di parole)?

La tua idea di una tabella intermedia e la sostituzione di puntatori con indici funzionerà, a condizione che tu abbia un set relativamente piccolo di parole brevi e un set di caratteri sparsi. Altrimenti rischi di rimanere senza spazio nella tabella intermedia. E a meno che tu non stia guardando un set di parole estremamente piccolo, non risparmierai davvero tanto spazio: 2 byte per un breve periodo contro 4 byte per un riferimento su una macchina a 32 bit. Se stai utilizzando una JVM a 64 bit, i risparmi saranno maggiori.

La tua idea di suddividere i personaggi in blocchi di 4 bit probabilmente non ti farà risparmiare molto, a meno che tutti i tuoi personaggi previsti non siano in un intervallo estremamente limitato (forse OK per parole limitate a maiuscole US-ASCII, probabilmente con un corpus Unicode generale ).

Se hai un set di caratteri sparsi, allora HashMap<Character,Map<...>>potrebbe essere la tua migliore implementazione. Sì, ogni voce sarà molto più grande, ma se non hai molte voci otterrai una vittoria complessiva. (come nota a margine: ho sempre pensato che fosse divertente che l'articolo di Wikipedia su Tries mostrasse - forse lo fa ancora - un esempio basato su una struttura di dati con hash, ignorando completamente i compromessi spazio / tempo di quella scelta)

Infine, potresti voler evitare del tutto un trie. Se stai osservando un corpus di parole normali in un linguaggio umano (10.000 parole in uso attivo, con parole lunghe 4-8 caratteri), probabilmente starai MOLTO meglio con un HashMap<String,List<String>, dove la chiave è l'intero prefisso.

se si codificano le stringhe in UTF8 è possibile utilizzare il trie di ramificazione standard 256 ed essere ancora compatibili con Unicode

inoltre, dovresti notare che solo 70 o più caratteri su 128 caratteri ASCII possibili (che codificano tutti su 1 byte in UTF8) saranno trovati più pesantemente che puoi ottimizzare per quello (come includere i digraph comuni al posto dei caratteri di controllo non utilizzati )