2019年9月16日月曜日

最適化の先

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

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

<速度アップのTIPS>
1)リソースがない(自明な)ところには、(意味がない)のでソフト制約化しない。
2)ソフト制約の数を減らす
3)ソフト制約の種類を減らす

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

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

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

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

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




2019年9月14日土曜日

OneDrive版ダイエット

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

2019年9月11日水曜日

リリース遅延

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

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

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

2019年9月10日火曜日

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

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

2019年9月5日木曜日

Python3での制約を計数表示

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

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

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


2019年9月4日水曜日

自動勤務表による勤務表作成の仕方

2019年度版をつくりました。ユーザさまにテストモニアルズをお願いし、最後に掲載しました。
未だ、リンク等、完成ではないのですが、とりあえずアップします。先に、実務で看護師長をやりながら、大学院に通われている研究生の方にお見せしましたが、そこからも少し追加しています。

今までの知見をまとめたのですが、最新のソルバーと人力との比較は興味深いのではないかと。
人力データは、Excelを読み込むのですが、人が書いた勤務表はとにかくハード制約を破りまくるので、ハード制約→ソフト制約に修正が多かったです。このデータは、開発中の勤務表で今年9月の実データを使っています。

Youtubeで動画による説明もそのうち作ろうと思います。アプリ版が出るころの話です。
制約の仕方は、講義にして5分x30回位になるような気がします。(TOEICの関先生のようなイメージで。)
ナレーションは、AITALKが実に自然で素晴らしいと思ったのですが、高いので二の足を踏んでいます。自身の出演は滑舌が悪く止めとけと言われたのでやりません。

2019年9月1日日曜日

one drive版更新

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

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