microsoft開発者登録

Windows7ブラウザでは、うまく登録できませんでした。Chromeで登録できました。個人か法人かで登録料が違います。1847円でした。登録が成功するとWindows デベロッパー センター アカウントの作成が完了しましたのメールが届きます。

次のハードルはデスクトップコンバータです。
 https://developer.microsoft.com/en-us/windows/bridges/desktop

その前に認定キットで様子をみようと思います。認定キットはWindows10SDKに含まれます。
https://developer.microsoft.com/ja-jp/windows/develop/app-certification-kit

スケジュールナースⅢオープンβ版リリース

しました。
β版とはいえ、メインソルバの機能は正式版と変わりません。不完全なのは、以下の通りです。

１）公式チュートリアルが整備されていません。
２）タスク・フェーズについてチュートリアルが整備されていません。
３）Algorithm4が開発中です。

今後の計画としては、Algorithm4の整理、海外ベンチマークテストの移植、英語版含むチュートリアル作成を行います。その後Windowsストアアプリ登録を目指します。来年初頭の予定です。
前にも言及したようにストアアプリ登録後は、無料でのリリースはなくなりますが、ここ1年程度は、使えるはずです。その後は、カレンダが動かないので使用できなくなります。現行有償ユーザへのUpDateおよびサポートは継続します。ただし、ストアアプリライセンスは別となります。よろしくお願いいたします。

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程度になりました。また、各スタッフからみると選択の余地がなかったのが、選択の余地があることになります。解空間は広がりますから、予定が入った場合以前よりも解が得やすくなっている筈です。実際のプロジェクトが入っているので比較してみてください。

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

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

仙台も冠水

1号配備とかで、土曜日夕方に妻を泉中央駅まで送ってそのまま病院泊まり、今日、日曜、病院まで迎えに行ってきました。広瀬川が決壊寸前までいきましたがなんとか持ちこたえたようです。帰りの道は、すっかり路面が乾いて日常生活に戻っていましたが、途中、道の真ん中で捨て去られた車を何台か見ました。多分AM３：００頃は、市内全域冠水状態だったと思います。

大手の画一的なプログラム

残念ながら、大手企業の大病院に入っているF社やM社のソフトは、画一的で固定の設定しかできません。
M社には、SC2のエンジンが入っているのですが、残念なことにフレキシビリティを生かしたGUI設定になっていません。エンジンがいかに優秀でも、個別病棟ごとに自由な設定ができないのなら、高速ソルバーをもっている意味が半減、否それ以上に価値が下がってしまうと思います。M社には、勿論SC3エンジンへのUpdateを促しますが、そもそもGUIが対応していないので...

解を高速に解くという面において、ここ数年でスケジュールナースが進歩したように今後も高速なソルバーの進歩は未だあるでしょう。しかし、制約プログラムの考え方、ナーススケジューリングDay集合、スタッフ集合、シフト集合の3要素で、欲しい解を記述するスタイルは、いかにソルバーが高速になろうとも変わることのない普遍的なものです。集合演算をGUIでいじくるスタイルは変わりようがないとも言えます。

看護師長が、個人で使えるように、ソフト自体の価格は、300円/月程度にするつもりです。来年のリリースを目指します。後は、初期設定を行うサービス、サポート体制と教育・啓蒙活動が重要であると考えます。

離散系と連続系

連続系での最適化ソルバーには、Simplexや内点法があります。連続線形領域では、NP困難の世界から脱することができます。連続系の解は、2.5人とか、1.3人とかになります。人を、そんな風に分割することはできないので、整数化した解が欲しい訳です。組み合わせ最適化の世界は、整数の世界です。ところが、整数の世界の最適値と、連続系の最適値は、似て非なるものです。難しいのは、整数化です。連続系からなんとかしようというのがOR的アプローチAlgorithm4になります。一方で、最初から、整数の世界でなんとかしようというのが、AI的アプローチでAlgorithm1です。
最適化解は、時間をかければ、Algorithm4の方が得やすいです。一方、Algorithm1は、短い時間で近似解を得るのが得意です。現在行っているのは、Algorithm4で、近似解でよいから短い時間オーダで解を得るものです。整数化解をいつどのタイミングで得るかということが問題です。INRC2の８Weeksの１インスタンスデータを得るのに数日かかっていますが、これに近い解を１０数分程度内に得ることが目標です。とても不可思議な世界で、整数化世界とは、全く異なる様相です。多分、機械学習させれば、なんらかの法則性や相関性が見出せるのではないかと思いますが、そこまでは行わずに、アイデアをCut＆Tryするということを行っています。

SC3導入2

導入の問い合わせがあったので、SC3ベースで新たにつくりました。Excelベースの方が導入前後の品質がVisualに比較できます。現実のルール（脳内）を可視化・計数化するとどうなるのか、をベースに置いて、そこからこれだけ改善できる、という方が説得力があります。