接尾辞木と試行。違いはなんですか？

私はTries一般にプレフィックスツリーとして知られているものについて読んでいSuffix Treesます。
のコードをTrie見つけましたが、の例が見つかりませんSuffix Tree。また、aをビルドするコードTrieは、aのコードと同じであるように感じますがSuffix Tree、前者の場合はプレフィックスを格納し、後者の場合はサフィックスを格納する点が異なります。
これは本当ですか？誰かが私の頭の中でこれをクリアするのを手伝ってくれる？サンプルコードは大いに役立ちます！

接尾辞木は、文字列自体をトライに追加するだけでなく、その文字列の可能なすべてのサフィックスを追加する、トライの上に構築されたデータ構造と見なすことができます。例として、接尾辞木で文字列bananaにインデックスを付けたい場合は、次の文字列を使用してトライを作成します。

banana
anana
nana
ana
na
a

それが完了したら、任意のn-gramを検索して、それがインデックス付き文字列に存在するかどうかを確認できます。言い換えると、n-gram検索は、文字列のすべての可能なサフィックスのプレフィックス検索です。

これは、サフィックスツリーを構築するための最も簡単で遅い方法です。このデータ構造には、スペースとビルド時間のいずれかまたは両方を改善する、より洗練されたバリアントが多数あることがわかりました。私はこのドメインに精通しておらず、概要を説明することはできませんが、接尾辞配列またはこのクラスの高度なデータ構造（講義16および18）を調べることから始めることができます。

この回答は、このデータ構造の変形を説明する素晴らしい仕事もします。

単語の接尾辞を付けたTrieを想像すると、文字列の部分文字列を非常に簡単に照会できます。これはサフィックスツリーの背後にある主なアイデアであり、基本的には「サフィックストライ」です。

しかし、この素朴なアプローチを使用すると、サイズnの文字列に対してこのツリーを構築すると、O（n ^ 2）になり、大量のメモリを消費します。

このツリーのすべてのエントリは同じ文字列のサフィックスであるため、多くの情報を共有します。そのため、より効率的に作成できるように最適化されたアルゴリズムがあります。たとえば、Ukkonenのアルゴリズムを使用すると、O（n）時間計算量でオンラインで接尾辞木を作成できます。

違いは非常に単純です。接尾辞ツリーには、接尾辞トライよりも「ダミー」ノードが少なくなります。これらのダミーノードは、ツリーでのルックアップ操作を増やす単一の文字です

Trieのノードには短いコンテキストへのリンクがありますが、「Tree」にはありません。ツリーのノードがより短いコンテキストへのリンクを取得すると、Trieになります; o）