適用前に確認
実際の動作を期待する結果と比較します。検証に失敗した場合は、次の変更を加える前に原因を調べてください。
● ● ●TreeSentinel●
ワークフロー · 二分探索木の厳密な順序 ×
def is_strict_bst(root):
pending, seen, checks = [(root, None, None)], set(), []
while pending:
node, low, high = pending.pop()
if node is None:
continue
if type(node) is not list or len(node) != 3 or type(node[0]) is not int:
raise ValueError("tree.node")
if id(node) in seen or len(seen) == 1000:
raise ValueError("tree.structure")
seen.add(id(node))
value, left, right = node
checks.append((value, low, high))
pending.extend([(right, value, high), (left, low, value)])
return all((low is None or low < value) and
(high is None or value < high) for value, low, high in checks)✳二分探索木の厳密な順序
✓ 変更内容適用前に確認 ↗
ワークスペースのイメージ
モデル
OpenAI互換またはAnthropicのエンドポイントを、ベースURLと必要なAPIキーで設定し、接続をテストします。ローカルのモデルサーバーは起動が必要です。リモートツールは別途データを送信する場合があります。
プロジェクト
空の木と祖先境界を試し、重複キーは偽とし、循環、共有する子、不正なノード、1000超のノードを拒否してください。
ワークフロー
def is_strict_bst(root):
pending, seen, checks = [(root, None, None)], set(), []
while pending:
node, low, high = pending.pop()
if node is None:
continue
if type(node) is not list or len(node) != 3 or type(node[0]) is not int:
raise ValueError("tree.node")
if id(node) in seen or len(seen) == 1000:
raise ValueError("tree.structure")
seen.add(id(node))
value, left, right = node
checks.append((value, low, high))
pending.extend([(right, value, high), (left, low, value)])
return all((low is None or low < value) and
(high is None or value < high) for value, low, high in checks)内部の値を信頼する前に構造をレビューする
TreeSentinelは構造化データの保守向けに、Windowsのプロジェクト環境とソースファイルに結び付いたAIの会話を提供します。まずアプリケーションが構造を受け取る場所と、検証結果の使い方を示してください。より単純なチェックや別の走査を提案する前に、境界全体をモデルに確認させます。
例えばbst_order.pyでは、直下の子は順序どおりに見えても、深い位置の値が祖先の境界に違反する木を調査できます。失敗する構造と期待結果を含めてください。続いて不正なノードと繰り返し参照の扱いを尋ね、順序の修正で走査対象の形状の前提を見落とさないようにします。
提案を、有効な木、順序の違反、不正な構造という異なる結果についてレビューします。関連するプロジェクトチェックを実行し、各結果が利用側にどう届くか確認してください。重複キーの方針を変えるなら明示します。小さな比較の編集に見えても、周囲のアプリケーションが受け入れるデータを変え得ます。
TreeSentinelは対応するOpenAI互換またはAnthropicのエンドポイントに、必要な認証情報を使って接続します。エンドポイントが提供する場合はアブリテレーション済みAIモデルを選択できます。プロバイダーの制限、コンテキスト上限、利用可能なツールはその構成の一部です。モデルの自信ではなく、具体的な構造と観測できる結果に基づいてレビューしてください。
構造化データの検証作業に関する質問
直下の子より深い位置の違反をテストするのはなぜですか？
局所的な比較が通っても、子孫が前の祖先の境界に違反し得るためです。その違いが表れる小さな入れ子のテストデータと期待結果を示します。検証ロジックの簡略化を採用する前に、そのデータで走査案を確認してください。
重複キーは構造のエラーですか、順序の判断ですか？
アプリケーションの仕様で定義してください。この例は厳密な順序を強制するため、等しいキーを除外します。利用側が不正な入力と形は正しいが順序違反の構造を区別するか確認し、その応答規約を変更案でも維持します。
同じノードへの繰り返し参照は何を変えますか？
個々の値が適切でも、入力がルーチンの期待する木の形でないことを意味する場合があります。適切なら共有参照や循環のテストデータを含めてください。通常の入れ子の例だけに頼らず、停止と拒否の動作を確認します。
検証を、出力が整列済みかのチェックに置き換えられますか？
呼び出し側に必要な構造と失敗動作を考慮した後に限ります。平坦化した値のチェックは不正なノードや走査の前提を隠し得ます。検証仕様を変える前に、実際のソースを使ってその兼ね合いをモデルに説明させてください。
TreeSentinel · 更新日 2026-10-25