Excel Import追加

Day集合の読み込みと、マクロの読み込みに対応しました。(OneDrive版更新しました)
詳しくは、マニュアルをごらんください。

原因解析の実装

実装しました。最初に切り分けそれぞれのルーチンに飛んで行きます。

エラー：
　　ハード制約エラーかソフト制約エラーか切り分け（ハード制約のみで求解し充足したならソフト制約エラー解析）
　　○ハード制約エラー解析
　　○ソフト制約エラー解析

本来、ソフト制約エラーは、解がない事態は引きおこさないのですが、基数制約については、常にハード制約とセットにしています。従いこのハード制約の影響により解が無い事態があり得ます。SC2では、実は、この辺の考え方がごちゃごちゃして色々な箇所にハード制約が入り込んでいました。SC3では、基数制約だけに、ハード制約を入れるという統一した考え方にしています。

SC3ではさらに、単に該当制約箇所の提示のみならず、Person/Dayについても明示しています。
さらに、GUIで、該当箇所に飛ぶ機能も実装しました。解析もマルチスレッド化しているので、速くなっています。
下の例は、4つのエラーグループが示されています。エラーグループ内のエラーは、各々一つだけですので、エラーを解消するには、このうちのどれか一つを解消すれば十分であることが分かります。●ラインをダブルクリックすると当該箇所を開いてくれます。

　
　　

原因解析系の再構築

やはり、積年の課題としてありますが、今回、基本特許技術を用いて再構築することにしました。
なお、この特許は未だどの企業にもライセンスしていません。大企業・中小企業の皆様、どうぞSC3を見てご検討ください。Reasonを得るための強力な基本特許です。

＜間違いを生む人間＞
ナーススケジューリングにおいて重要なのは、「最適解を求める」　ことだけではありません。それと同じ位重要なことがあります。それは、「解がない原因を得る」ことにあります。確かに、全てをソフト制約にすれば、「解がないことは無い」　状態になります。従って「解がない原因を得る」その事の必要がなくなります。で、それで実用的なシステムになるか？と言われれば、それでは十分ではありません。なぜなら、ルールは、間違いをしでかす人間が作るものだからです。確かに、間違いがない世界なら、原因解析は必要ありません。学術系の視点で欠けているのは、ルールそのものには誤りがない、という暗黙の前提が入ってしまっていることです。人間が、ハード制約であると信じるならば、それはハード制約であり、そうでないならソフト制約です。そして現実のシステムには、制約そのものに誤りがあるかもしれないのです。何十、何百、サブ制約を含めれば、何十万といったオーダの制約のAND集合体である制約システムは、人間には、複雑すぎ、特に開発過程においては、必ず誤りが発生します。ルール構築には、原因解析が不可欠であり、それなしには、ルール設計さえもままならないと言ってもよいでしょう。勤務表の毎月のルールの修正過程においても誤りが発生する可能性があります。つまり原因解析は、極々普通のことであり日常的な事です。
まとめると

ルールのビルドアップ　
　ルールを作るのは人間
　　人間は誤りをする存在である(誤りをしない人間はいない）
　　　　絶対であると思っていたルール(ハード制約)が衝突(Conflict)する
　　　　　　解がない　→　原因不明　→原因解析
　　　　　　


＜原因解析は、OR系AI系？＞
前に最適化のアプローチは、OR系とAI系の二つのアプローチがあることをお話ししました。
原因解析については、間違いなくAI系です。人口知能研究では、論理を推論するという歴史があり、前述の特許もその系譜の末端にあります。学術系では、あまり着目されていませんが、実用的なシステムでは、必ず原因解析は必要になります。

＜原因解析は難しい＞
解がない原因は、実は無限に存在します。多分、一つの学術論文になります。
実用的に重要なのは、間違いをしでかす人間にとって、いかに自分の間違いを正しく指摘してくれるかです。

循環参照によるSTACK OVERFLOW対策

ずっと、いつか対策しようと思っていて手付かずだった問題の一つにDay集合の循環参照問題があります。

Day集合は、下のように、定義したDay集合をさらに、別なDay集合の要素として定義できるようにしています。これを繰り返すことで任意のDay集合が定義できる筈です。（証明は出来ていません。）

C#は、便利な集合演算が行えるので、実装は楽です。クリックすると該当のDay集合を表示するようにしているのは、中々便利な機能です。(制約の開発には、嬉しい機能です。)

問題は、例えば、上のように日祝の定義が二つあり、さらにそれを参照していると循環参照となります。プログラム上は、再帰呼び出しによる無限ループでスタックオーバフローとなる古典的な問題です。
循環参照の検出をどうしようか？と少し悩みましたが、単純な解決策が見つかりました。呼び出し回数を引き数にして、一定回数以上の呼び出しで循環参照を検出します。多分、これで副作用なくWarningが可能となる筈です。

自動勤務表ソフトによる勤務表作成の仕方更新

今月だけ制約の例を追加しました。

Excel Import GroupProperty改善

Excelでスタッフプロパティで
　■夜勤1回以下
を定義したとします。これに対応して行制約を定義したとします。

次月のインポートで、夜勤1回以下の定義が無くなり、代わりに
■夜勤2回以下
が新しく定義されたとします。そうすると行制約夜勤1回以下の制約で参照している夜勤1回以下というグループプロパティが消えてしまっているのでエラーとなってしまいます。

そこで、Excel　Import時のグループプロパティは、現プロジェクトに追加することにしました。そうすると参照がDeadすることはなくなり(夜勤1回はEmpty集合)、エラーを解消することが出来ました。

最適化の先

＜リソースの確認＞
最近、ユーザさんのプロジェクトファイルをよく見ます。総じて、期待通りに使いこなしている方が多いのですが、過剰な設定も目に付きます。（一つ一つGUIに計数エントリするのも面倒なので、全て挿入という、項目を作りました。結果をすべて出し、Excelで表示させています。レベル7違反は、赤表示にしました。Excelだと全体が黄色赤具合が一目瞭然なのでそのような利用をしています。）

最適化が効くのは、リソースがあるときです。リソースがないところでは無力に近いです。まずは、初心に戻って必要なリソースが確保されているかということを確認しましょう。確認の手順については、AdvancedUnserManualの方に書きます。　

＜速度アップのTIPS＞
１）リソースがない（自明な）ところには、（意味がない）のでソフト制約化しない。
２）ソフト制約の数を減らす
３）ソフト制約の種類を減らす

いずれも、ソフト制約に関することになります。なぜ、ソフト制約が速度に効いてくるかというと、
2値問題から最適化問題になるからです。SAT/UNSATの判定には、SATを広大な探索空間から一つ見つければ十分です。ところが最適化問題になると、それだけでは足りず、SATの中でも、どのSAT組み合わせが最適か？という問題になります。これだけでも、遅くなりそうだということが分かると思います。

さらにソフト項、例えば、基数制約における許容エラー量＋１の増加は、軽く探索空間の桁オーダを増やします。

こういった事情で、ソフト制約項が直接速度と関わってくるのです。まとめると、
ソフト項の増大→探索空間増大→速度低下
というのが大枠的なイメージとなります。

　この中でも、基数制約のソフト制約が支配的、つまりパターン制約は、ハード制約で、列制約がソフト制約で構成される場合は、数理的ソルバーが有効なことが分かっています。(日本の勤務表では、こういった例は皆無に近いのですが)そのような場合にAlgorithm4は、有効に作用します。

いずれにしても、元々の人力解と比べれば、圧倒的に高品質なのですから、適当なところで、
打ち切るのもありだと思います。下界が早期に分かれば、それ以上は絶対に良くなることは分かるので、この辺で止めておこうかという判断ができるのですが、それにはAlogithm4のRUNが必要になります。

OneDrive版ダイエット

パッケージ450MBぐらいあったものを150MB程度にダイエットしました。
ClosedXMLは、完全に除去しExcel関係は、全てsyncfusionに統一しました。
GUIに関して細かな改善を盛り込みました。原因解析関係の実装が足りないので、ここ数日で実装しようと思います。

リリース遅延

諸事情により遅れます。10月のリリースになります。ストアアプリ化は、その後の将来予定になりますが、UWP化(デスクトップブリッジ)でのSANDBOX環境でテストしてみて、何をしなければいけないかを認識して、ある程度それに対処できる目処がついたところでのリリースになります。例えば、レジストリが書けないとか、作業データ(problem.json等)は、現状のインストールフォルダでは書けなくなる、等の問題があります。これらは、APPDATAフォルダに移ります。

既存ユーザのSC2→SC3ライセンスは有効です。問題なく移行可能ですが、急ぎで試したい方は、OneDrive上のβ版をご案内しております。また、SC2プロジェクトをSC3プロジェクトに変換したい、
なんだか遅いので、速度アップの記述方法について相談したい、等ございましたら、SC2プロジェクトをサポートまでお送りください。SC3プロジェクトに変換の上、記述のアドバイスを添付返信いたします。

レンタルサーバ移行を10月に予定しています。メールサーバは、変わりませんのでメール送受信は途切れることはありません。

テスティモニアルが素晴らしい

ユーザ様が書いたテスティモニアルを改めて読んでみたのですが、看護協会の教科書にしたい位素晴らしいです。単に、公平というだけでなく子育てとか介護とか個別の事情を汲んで公平にするという考え方です。言葉だけではなく、スケジュールナースで実践しておられるのを実際に見ておりますので、なおさら素晴らしいと思います。

Python3での制約を計数表示

python3制約プログラミングマニュアルを更新しました。基数制約かつAlgorithm1のみのサポートになりますが、GUIで計数表示できるようになりました。目標値に達していないところは、Pythonで制約したところも含めて黄色で表示されるので、直感的に良し悪しを判断できます。

これで、シフト変数に関わるところは、大体網羅できたと思います。一区切りとします。

実装は、かなり面倒で、ソルバーからファイル出力でGUIが読み込んでいます。（PythonをParseできるのはソルバーのみなので）GUIの読み込みには、JSONを使っています。CEREALでC++上のシリアライズを行って、C#上は、DynamicにJSON構造を読み取るという方式です。構造は同じはずなのですが、CEREAL（C++）とC#で微妙に仕様が異なるので、Dynamicにせざるを得ませんでした。

one drive版更新

Algorithm１のアルゴリズムを少し変更しました。

取得メモリを最後に表示するようにしました。一般に重みの種類が多いとパフォーマンスは、劣化します。
出来れば、重みの種類は、3-4以下であることがパフォーマンス上、望ましいです。それより多い場合は、メモリ取得量に注意してください。

SC3のリリース予定は、9月17日です。