問題タブ [subtree]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
xml - XPath は XML の 2 つのサブツリーにわたって外部キー検索を実行できますか?
次の XML があるとします...
...「バケット」に「赤」と「青」が含まれていることを返す XPath は何でしょうか?
ldap - LDAP サブツリー全体のコピー
私は実際にこのフォーラムに初めて参加し、LDAP サブツリー全体を別のツリーにコピーする簡単な方法を見つけるために数日間試み続けました。役立つものが見つからなかったので、ここにも質問をドロップすることを考えました. プログラムでこれを行う方法を知っている人はいますか?
追加、削除、検索などの通常の操作には、Spring LDAP を使用しています。
どうもありがとう !
algorithm - 単方向ツリーの効率的なトラバース
各オブジェクトがその親を指す単方向のオブジェクト ツリーがあります。オブジェクトが与えられたら、オブジェクトのコレクションとして、その子孫のサブツリー全体を取得する必要があります。オブジェクトは実際にはどのデータ構造にもありませんが、すべてのオブジェクトのコレクションを簡単に取得できます。
素朴なアプローチは、バッチ内の各オブジェクトを調べ、指定されたオブジェクトが祖先であるかどうかを確認し、それを脇に置いておくことです。これはあまり効率的ではありません... O(N*N) のオーバーヘッドが発生します。ここで、N はオブジェクトの数です。
別のアプローチは再帰的なものです。つまり、オブジェクトの直接の子を検索し、次のレベルのプロセスを繰り返します。残念ながら、ツリーは単方向です...子への直接的なアプローチはありません。これは、以前のアプローチよりもわずかにコストが低くなります。
私の質問: ここで見落としている効率的なアルゴリズムはありますか?
ありがとう、
ユヴァル=8-)
c# - すべてのノードの合計
これは簡単な修正かもしれませんが、バイナリ サーチ ツリーのすべてのノード (Node クラスの Size プロパティ) を合計しようとしています。以下の私の BST クラスには、これまでのところ次のものがありますが、0 が返されます。
Node クラス内には、指定されたプロパティに Size と Name を格納する Data があります。私は全体のサイズを合計しようとしています。提案やアイデアはありますか?
git - Git を使用して、サブモジュールを持つ外部プロジェクトをサブツリー マージする最良の方法は何ですか?
開発中の Web サイトに関連するすべてのものに Git リポジトリを使用しています。リポジトリには、ドキュメント、モックアップ、元の階層化された画像など、サイトに関連するすべてのファイルと、www
サブディレクトリに配置した Web ルートのものがあります。
私は、使用することを選択した CMS をプロジェクトの残りの部分と統合することを開始したいところです。CMS はオープン ソース プロジェクトであり、Git でも管理されています (重要な場合は GitHub でホストされています)。明らかに、CMS はwww
サブディレクトリにある必要がありますが、それだけではありません。CSS ファイル、画像、CMS 用のテンプレートなどがあります。このため、私が選択したのはサブツリー マージ戦略を使用して、外部プロジェクトをリポジトリに追加します。ある時点で元のプロジェクトを変更し、変更を元に戻す場合があるため、GitHub から CMS リポジトリを複製し、クローンからサブツリーのマージを行いました。
問題は、外部プロジェクト (つまり、CMS 用) に、インクルードしたいサブモジュールがあることです。サブモジュールがメイン プロジェクトに統合されていることを確認する最善の方法は何ですか? サブモジュールごとにサブツリーのマージを行う必要がありますか?
サブモジュールを変更したいとは思わないでしょうが、変更したい箇所が 1 つか 2 つある可能性はあります。
search - 一致するサブツリーを見つけるにはどうすればよいですか?
私は大きな二分木を持っています.T.Tは「一致」します。T の一部の部分木も一致します。実際、一致するサブツリーは完全なサブツリーである必要はありません。切り詰めることもできます。切り捨てられたサブツリーとは、サブツリー内のノードに子が完全に含まれていない可能性があることを意味します。子を持つ一部のノードでは、子が削除される可能性があります。
例:このリンクを参照してください。pom1、stanza1、stanza2、line3 で表されるツリーは、切り捨てられたサブツリーの例です。
ツリーが一致するかどうかを判断するには、そのツリー全体で計算を実行する必要があります。プログレッシブではありません。
どうすればすべての一致を見つけることができますか?
git - git: リポジトリのサブパスだけをサブツリー マージできますか?
私はリモコンのFooとBarを持っています。Foo は多数のディレクトリを持つ Web アプリケーションであり、それらの中で関連するのは、/public
さまざまなファイルやその他のディレクトリを含むものです。
Bar はライブラリのセットであり、フロントエンドで使用されないものであるため/public/bar
、Foo に入れる必要があります。Foo にはファイルがありません。
それは、サブモジュールまたはサブツリーのマージのいずれかを使用すると、すべて簡単になります。しかし…</p>
Bar のツリーはごちゃごちゃしており、PSD や FLA などのあらゆる種類のプリプロダクション ファイルが含まれており、その中にあるものだけが本当に便利な部分です/www/tools
。
だから、私がやりたい/www/tools
のは、 Bar を Foo にマージし/public/bar
、Bar のツリーの残りの部分が存在しないふりをすることです。
できる?
(これは、最初に自分のプロジェクトをサブツリーとしてマージしたプロジェクトからマージする方法と非常に似ていると思います。これも方法がわかりません。)
git - 更新をサブツリーにマージするときに Git が混乱する
以前はメイン リポジトリで多くのサブモジュールを使用していましたが、プロジェクトの保守性を高めるために、実験的なブランチを開始し、それらをすべてサブツリーに置き換えました。
これはうまくいきましたが、サブツリーの1つを更新しようとすると、更新がサブツリーではない完全に間違ったディレクトリに誤ってマージされます。
ブランチ「サブツリー」に実験的なブランチが含まれるメイン リポジトリは、次のとおりです: git://github.com/hugowetterberg/goodold_drupal.git
更新をマージするリポジトリ: git://github.com/voxpelli/drupal-oembed.git
実行によるマージ: git merge -s subtree oembed/master
更新をマージするパス: sites/all/modules/oembed/
それらがマージされるパス: modules/aggregator/translations/
更新をサブツリーに入れる方法やエラーの原因を知っている人はいますか?
algorithm - (解析)ツリーのコレクションで最も頻繁なサブツリーを見つける
ノードにラベルが付けられている(ただし一意ではない)ツリーのコレクションがあります。具体的には、ツリーは解析された文のコレクションからのものです(http://en.wikipedia.org/wiki/Treebankを参照)。コレクションから最も一般的なサブツリーを抽出したいと思います。パフォーマンスは(まだ)問題ではありません。ツリーバンク用にこれを行うアルゴリズム(理想的にはJava)またはツールへのポインターに感謝します。子ノードの順序が重要であることに注意してください。
@mjvを編集します。私たちは定型化された言語を持つ限られた領域(化学)で作業しているので、木の多様性はそれほど大きくありません-おそらく子供の読者に似ています。「猫がマットの上に座った」のシンプルな木。
ここで、文には2つの同一の品詞サブツリーが含まれています(実際のトークン「cat」。「mat」はマッチングでは重要ではありません)。したがって、アルゴリズムはこれを検出する必要があります。すべてのnounPhraseが同一であるとは限らないことに注意してください-「大きな黒い猫」は次のようになります。
文の長さは長くなります-15から30ノードの間。1000本の木から有益な結果が得られると期待しています。これに1日以上かからない場合は、許容範囲です。
明らかに、ツリーが短いほど頻繁になるため、nounPhraseが非常に一般的になります。
編集これがツリーを平坦化することによって解決される場合、私はそれが最長共通部分列ではなく最長共通部分文字列に関連していると思います。ただし、必ずしも最長のものが必要なわけではないことに注意してください。「興味深い」(基準はまだ決定されていません)のに十分な長さのリストが必要です。