ローズツリーの用途は何ですか?


10

私は最近、ローズツリーのデータ構造について知りましたが、Haskellのdata定義とそのウィキペディアの小さな説明から抜け出しただけで、ローズツリーがどのようなアプリケーションを持っているのかを理解するのに問題があります。

参考までに、Haskellのdata定義:

data RoseTree a = RoseTree a [RoseTree a]

Haskellに不慣れな人にとっては、これは任意の型を持つ再帰的なデータ型定義でaあり、型コンストラクタには型のリテラルがあり、aその後RoseTreeに同じ型のオプションの空の型リストが続きaます。

私の見立てでは:

  • このデータ構造はデフォルトでは順序付けされていません(ただし、ほとんどの実際的なアプリケーションは、検索のために何らかの形式の順序付けを実装していると思います)

  • データ構造は、単一のノードを持たなければならないグローバルルートを除いて、どの時点でもレイヤーごとに固定数のノードを強制しません。

その最小限の情報を考えると、このタイプのツリーをいつ使用できるかを理解するのに苦労しています。

タイトルの質問に加えて、ローズツリーのほとんどのアプリケーションで検索が実際に実装されている場合、これはどのように行われますか?


1
デレクの答えに加えて、XML文書は基本的にはローズツリーというラベルが付けられていると考えてください。
仮名

回答:


16

あなたは過度に「データ構造とアルゴリズム」の考え方を持っているようです。すべてのツリーが何らかの検索ツリーであるとは限りません。多くの場合、データ構造は、ドメインモデルの側面に対応またはキャプチャするように設計されています。

S式はほぼ正確にバラの木です。(または、むしろ、それらが通常どのように考えられているかをバラの木と言います。ウィキペディアは、それらがバイナリツリーに似ていると言っていますが、「適切な」S式と呼ばれるものは、バラの木とわずかに異なります。)とにかく、それらを抽象構文ツリーの一般的な表現として使用できます。これを行う利点は、「すべての変数を見つける」、「パラメーターを交換する」、「このシンボルの名前を変更する」など、一般的な操作を簡単に記述できることです。また、抽象構文に新しいタイプのノードを追加するために、実際には何も変更する必要がない場合も多いので、拡張可能です。欠点は、実際には何の制約もないため、無意味な記述をアプリオリに妨げないことです。これは、ユーザーが標準の抽象データ型手法を使用して軽減することができますが、変換などの実装者は、入力がデータ型不変式によって構造化されていることを「知っている」としても、非構造化表現を処理する必要があります。もちろん、その確実性が誤っていると(状況が変わった可能性があるため)、エラーは予測不可能で、デバッグが困難になる傾向があります。

実際にData.Treeは、標準ライブラリのモジュールはローズツリーを提供しますが、Haskellコミュニティでそれを使用する人はほとんどいません。制約を明示的にキャプチャするカスタムデータ型を定義するのは簡単なので、一般的なライブラリ型を使用する理由はほとんどありません。さらに、カスタム型に対してジェネリック操作を実行することに関して、膨大な量の研究と実践が行われており、ジェネリック表現を使用することの多くの利点を排除しています。最後に、Haskellerは、明示的で強制的な制約に非常に賛成する傾向があり、それを取得するために支払う用意があります。

最後の質問に答えるために、多くの場合、ASTの検索は重要ではありません。また、一般にASTは、全体を歩くだけで十分なほど小さいと想定されています。確かに、ASTへの参照を持つ別のデータ構造で定義を収集することは珍しくありません。これは、一種のインデックスと見なすことができます。同様に、一部の最適化パスでは、(通常はローカルで一時的に)インデックスが作成され、操作が簡略化および高速化されます。ASTの構造は入力に対応しているため、「リバランス」などはできません。そのため、AST自体にインデックス付け情報や「検索」に役立つ情報が含まれることは一般的ではありません。


すばらしい答え、ありがとう!ASTのコンテキストではローズツリーについては考えていませんでしたが、それは理にかなっています。
ジュール
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.