タグ付けされた質問 「trie」

古いHacker Newsのアイテムを調べてみると、あるユーザーからの投稿に出会いました。 （ソフトウェアルーティングテーブルで使用するような）境界サイズの基数トライをLRUリストと結合し、パターンから集約（すべてのIPの1,000の観測値から10.0.0.0/16など）を自動的に合成するAguriツリー挿入の。これらはトラフィック分析で最もよく知られていますが、ランタイムメモリ分析でも使用されています。 〜tptacek 調べてみることにしました 簡単なGoogle検索でF1ドライバーに移動します。 ウィキペディアで検索すると、インドの農業カーストと日本からのいくつかのアイテムにつながります Stack Overflow hits 0 results /programming//search?q=aguri site:stackoverflow.com/questions aguri だから私は最終的にそれをユーザーにリンクしました。彼が彼のブログにリンクを持っているのを見てください http://www.matasano.com/log/1009/aguri-coolest-data-structure-youve-never-heard-of/ しかし、それは死んでいます。 それでは、このAguriデータ構造とは何ですか？それが実際のデータ構造である場合、他のどこにも文書化されていないのはなぜですか？

19 data-structures  terminology  trie 

効率的な文字列トライの実装を探しています。ほとんどの場合、次のようなコードが見つかりました。 Javaでの参照実装（ウィキペディアごと） これらの実装は、主に2つの理由で嫌いです。 256文字のASCII文字のみをサポートします。キリル文字などをカバーする必要があります。 それらは非常にメモリ効率が悪いです。 各ノードには、256個の参照の配列が含まれます。これは、Javaの64ビットマシンでは4096バイトです。これらの各ノードは、それぞれ4096バイトの参照を持つ最大256個のサブノードを持つことができます。したがって、すべてのASCII 2文字列の完全なトライには1MBを少し超えるサイズが必要です。3つの文字列？ノード内の配列にのみ256MB。等々。 もちろん、トライに1600万の3文字列すべてを含めるつもりはないので、多くのスペースが無駄になっています。これらの配列のほとんどは、挿入されたキーの実際の数をはるかに超える容量があるため、単なるヌル参照です。また、Unicodeを追加すると、配列はさらに大きくなります（charの値はJavaの256ではなく64kです）。 文字列の効率的なトライを作成する希望はありますか？これらのタイプの実装に対するいくつかの改善を検討しました。 参照の配列を使用する代わりに、プリミティブ整数型の配列を使用できます。これは、サイズが実際のノードの数に近いノードへの参照の配列にインデックスを付けます。 深いツリーを犠牲にしてサイズ16のノード配列を可能にする4ビットの部分に文字列を分割できます。

12 unicode  trie