Python3制約マニュアルを更新

時間制約は、遅いのですが、場合によっては、Pythonで時間制約を使わずに記述できる場合もあります。そのような例をユーザ様のプロジェクトをそのままお借りして記述しました。
改善前のプロジェクトでは、時間制約だけでもよいのですが、その場合、夜勤6回が出現することがありました。それはまずいということで、夜勤回数も制約化しています。

158.5hと160.25hとなる組み合わせ（夜勤回数、日勤回数、半日回数）は各々一つに限定できるようです。そうするとそれらの条件のAND・ORで制約化すればよいことになります。GUIでは記述できないので、Pythonの出番になる訳です。このプロジェクトで面白いのは、極限的に勤務時間数の平準化を行っていて、休み（公休数）の制約がどこにも入ってこないことです。お聞きしたら、「公休数は決まっているのですが、出来上がった勤務表から「休」を一部手で「公」と変更しております。」　とのことでした。発想が斬新です。
なお、このPython化事例は、以下のような経緯に基づいています。

「夜勤回数を毎月、スタッフ設定から設定し直しています。全員の夜勤回数の総和が日数*4となるようになっております。毎月手で計算しているため、ミスが発生する可能性はあります。
その場合は矛盾でハードエラーが出るわけですが、場合によっては、エラーメッセージからは気づきにくい場合もあります。」

シフト時間が8hまでしか記述できなかったので、そもそも時間制約で記述できなかったのですが、GUIを対応して時間制約で記述してみると、5倍程度時間がかかってしまいました。これは、純粋に技術的な理由により予想されていることです。具体的にはUnitPropagationで記述できないことに起因しています。UnitPropagationするような方法も試してみたのですが、メモリオーバで記述できませんでした。この辺、OR的アプローチでは、むしろ問題なくAlgorithm4では、あまり影響がないはずです。

そこで、Excelで総和一致を確認した後インポートする発想をしていたのですが、ユーザ様プロジェクトの発想をそのままPythonで記述できることに気がつきました。Excelの力を借りることなくPythonでStandAlone的に記述することができました。恐らく、長期休み以外は、この記述で行けると思います。時間も4分の1から5分の1程度になりました。また、各スタッフからみると選択の余地がなかったのが、選択の余地があることになります。解空間は広がりますから、予定が入った場合以前よりも解が得やすくなっている筈です。実際のプロジェクトが入っているので比較してみてください。

いずれにしても、人力でほぼ不可能に思えることを難なくやってのけるのが素晴らしいと思います。ソフトの力を最大限に活用頂いている事例になっていると思います。

特養の記述サンプルとしても価値が高いプロジェクトであると思います。