どうやら、変数にラベルを付けようとすると「いいえ」になるため、問題を FD に「正しく」マップしなかったようです。
Constraint Logic Programming で行うことは、ドメインを持つ変数 (この場合はドメイン [0,1] を持つブール値) と、これらの変数間のいくつかの制約を持つ制約モデルをセットアップすることです。各制約には、制約がポストされる変数のドメインの一貫性を達成しようとする伝播規則があります。一貫性のない値はドメインから削除されます。一貫性にはいくつかの種類がありますが、共通点が 1 つあります。それは、通常、制約だけでは完全な解決策が得られず、制約モデルの解決策があるかどうかさえわからないということです。
例として、2 つの変数 X と Y があり、どちらもドメインが [1..10] で、X < Y という制約があるとします。この場合、伝播ルールは Y のドメインから値 1 を削除し、ドメインから 10 を削除します。ドメインが一貫しているため、停止します。一方のドメインの各値に対して、もう一方のドメインに値が存在するため、制約が満たされます。
ソリューション (すべての変数が値にバインドされている) を取得するには、変数にラベルを付ける必要があります。各ラベル付けは、ラベル付けされた変数に関連付けられた制約を起動し、別のラウンドの伝播をトリガーします。これは、解決 (値にバインドされたすべての変数、答え: はい) または失敗 (検索ツリーの各ブランチで、一部の変数が空のドメインで終わる、答え: いいえ) につながります。
各制約は、それが投稿された変数のドメインの一貫性のみを目的としているため、制約の組み合わせから生じる実行不可能性が伝播段階で検出されない可能性があります。たとえば、ドメイン [1..2] を持つ 3 つの変数 X、Y、Z、およびペアワイズ不等式制約。これは、制約モデルで発生したようです。
パズルの解決策があるはずだと確信している場合、制約モデルにはいくつかの実行不可能性が含まれています。おそらく、制約をよく見るだけで、それを見つけるのに十分です。
明らかな実行不可能性 (たとえば、上記の不等式の例のような矛盾する制約) が見られない場合は、プログラムをデバッグする必要があります。可能であれば、組み込みのラベル付け述語を使用せずに、独自の述語を記述してください。次に、インスタンス化された変数と、それによって引き起こされたブール決定変数の変更、または失敗につながったかどうかを追跡できる出力述語を追加できます。