ソルバのプロセス解説

エンジンは、下記3つのプロセスから成り立ちます。

■コンパイル　

■求解　

■エラー解析

です。

コンパイルは、求解コードを構築するため処理です。problem.jsonを読み込み、構文解析後に、簡易・自明なエラーは、求解に行くまえに報告・終了となります。自明なエラーとは、例えば、日勤者が3人以下という制約があって、予定入力で4人以上既に割り当てられている場合です。この場合、ソルバに入力しても解がないことは明らかですので、この段階でエラーを報告し終了となります。ただし、予定入力がソフト制約の場合は、この限りではありません。あくまでハード予定入力がされている場合のみエラー報告終了となります。

（現在、この部分の報告は一部英語となっていたので、日本語に書き換えています。）

また、Algorithmによっても、コンパイルコードは、変わるので、前段は、Algorithmに依存しない処理、後段は、Algorithmに依存する処理となり、コンパイル内でも前段・後段があります。

求解は、Algorithmに従って答えを探す処理です。

求解で、答えがタイムアウト等で求められない場合、あるいは、明確に解が存在しないと分かった場合は、エラー解析に行きます。ただし、これは、エラー解析指定がなされた場合のみです。

エラー解析でのアルゴリズムは、私の特許に基づいています。ただし、エラー要因は実は無数にあり、そのこと自体、求解プロセスと同様のNP困難なとても難しい問題です。さらに難しくしているのは、どれが人間にとってのエラー主因か、人間の主観による部分があります。必ずどんぴしゃなエラー主因を導きだせるものではありません。ただし、これなしにはそもそも何の制約が満足していないのかが不明です。制約設計時、これが為にネックになることがあります。制約設計段階での設計支援ツールというのがその主旨であり位置づけになります。

ハードエラー解析は、厄介ですので、月々の制約では、適切にソフト制約を織り交ぜ予定なしでは、生じないようにします。こうしておけば、後は予定入力追加によるエラーしかありえないので問題を予定に特化・限定させることが出来ます。エラーがあったとき、予定を全てソフト化して、解を求め(予定なしでは解があることが保証されるので解はあります）、予定が移動された場合のところが怪しいということになります。(予定が移動された部分は赤枠で表示出来ます。)