2024年6月13日木曜日

Q 解をCSVで出力するには?

マニュアルは、次のExcel出力方法その1 です。

https://www.nurse-scheduling-software.com/japanese/manuals/user_manuals/chapter13/


その他に、CSVを簡易的に出力する方法があります。



すると、プロジェクト名_shift.csvが、プロジェクトフォルダに生成されます。

タスク画面でも同様に、

プロジェクト名_task.csvが、プロジェクトフォルダに生成されます。

ハイブリッド画面でも

プロジェクト名_task.csvが、プロジェクトフォルダに生成されます。


2024年6月12日水曜日

AL5の評価

 AL5(開発中)の評価結果は、以下です。

マシンは、Rezen5950。インスタンスは、instanceXがスケジューリングベンチマークから、その他は、Realプロジェクトです。

Currentが現行1コア、AL5が3コアのプロジェクトになります。Realプロジェクトでは、速度向上が認められる頻度は、高いです。池上ベンチは、ついに2秒台となりました。


また、目標としていたicu20、120秒には届きませんでした。一般にエラーの多いプロジェクトでは、全く効果はありません。最新のソルバを駆使すれば、少しは改善するのでは?という期待は見事に打ち砕かれました。

https://ceur-ws.org/Vol-3545/paper6.pdf

3コアの実体は、1コアが現行アルゴリズムと現行ソルバ、1コアが現行アルゴリズムと最新ソルバ、1コアが別なアルゴリズムと最新ソルバです。ポートフォリオ的なアプローチですが、これ以上増やしても効果はなかろうと判断しています。

この状態でリリースするかどうか迷ったのですが、もう少し、最終目標での構造を考えた上で決めることにします。具体的には、Highsの取り込み、数理ソルバAL3/4の取り込み等の検討です。とりあえず、AL1系関わる検討はこれで打ち切り、他のソルバを使ってエラーの多いプロジェクトでの実性能向上を考えることにします。エラーが多いというのは、列と行相互に関係するエラーが多いということでありNSPの本質と考えられます。その状態で、厳密解を高速に出すことは、本当に難しいです。特に難しいのは、厳密解である証明部分です。最後は、Cutting Approachや、Branch&Boundとなるために、とにかく時間がかかります。

しかし、実務的に欲しいのは、「証明は置いておいてよいから近似解をもう少し早く出せないか?」ということです。今後は、その事にフォーカスして考えていきたいと思います。

2024年6月11日火曜日

Algorithm5の時間定義を元に戻す

 どうにも、当初の目論見通りに行かずに、結局元の定義に戻すことにしました。

新しくアルゴリズムを考えたものの、結局、元のアルゴリズムを凌駕できずに、元のアルゴリズムに戻ることにしました。現在のアルゴリズムとソルバが最強である、ということを改めて認識しました。

とはいえ、部分的な改善は可能であるので、並列化によって、少しだけ改善可能な場合は出てきます。HIGHSをどのようにするか等、全体をどのようにするかは未だ決めていませんが、とりあえず、SAT系の並列化の評価中です。


2024年6月10日月曜日

「ブランク予定より良くなることはない」の例外事例 

 これは、あくまで自動勤務割り付けに関する 一般則です。自動割り付け以外の予定入力を前提としている場合は、これに当てはまりません。

例で説明します。

次のブランク勤務表では、目的関数値が0になっていません。これは、

「ブランク予定時、エラーなし、UB=0であること」の原則から逸出しているように見えます。


しかし、非常勤の予定を入れると、エラーなし、UB=0となります。

このプロジェクトでは、非常勤の医師は、自動割り当ては決して割り当てられません。全て予定入力のみが勤務になります。つまり、非常勤医師のリソースは、予定入力をして初めて効力を発揮します。

一番上の図は、非常勤リソースを活用していないので明らかなリソース不足となります。その結果が目的関数値に現れたと考えられます。

常勤医の予定をプラスしてみると、いつものようにUBは上昇します。


上のUB値23は、最適化ソルバが最適化した結果であり、どんなに優秀な人間や機械が頑張って自動割り当てを考えたとしても、これを下回るUB値はありえない、という値です。
なので、この段階で問題ある場合は、予定や制約の重み制約等を修正することが出来ます。
しかし、人力で作成している場合は、そのあとの未来が決して見えないまま、最後は破綻する不安を抱えたまま入力せざるを得ない、これが人力と自動勤務表との大きな違いです。

実際さらに人力解を加えると、さらに上昇するのが普通です。



以上から、

自動割り当て部に関して、ブランク予定より良くなることはない

が、正しい表現です。

2024年6月9日日曜日

最適値に到達したことは、どのようにすればわかるのでしょう?

Algorithm1以外は、殆ど使うことはないと思いますが、一応の回答です。

なお、AL2に関しては、HighsのUpdateを予定しています。これにより中途で止めてもそれまでのbest解(incumbent )を出力するようになります。

最適値に到達したことは、どのようにすればわかるのでしょう? (nurse-scheduling-software.com)

2024年6月7日金曜日

Q.シフト集合のANDは、ないのでしょうか?

 ありません。あり得るのは、OR かNOTの2種のみです。

シフト集合の要素は、シフトのみであることに注意してください。任意のシフトの集合は、ORのみで表現できます。

例えば、A,B,Cというシフトがあったとき、

A,B,CのORは、(A,B,C)

A,BのORは、(A,B)

A,BのNOTは、(C)

もし、AND オペレータを用意したとしても、

A,B,CのANDは、()空集合

A,BのANDは、()空集合

A,AのANDは、(A)

となり、自分自身のANDを取ったときだけ、自分自身になりその他は、空集合となります。

これに対して、DAY集合と、グループ集合は、各々DAY集合、グループ集合に対するオペレータを用意しています。つまりDAY集合の要素は、DAY集合がありえます。同様にグループ集合の要素は、グループ集合もありえます。集合同士の演算をするときだけANDは意味を持ちます。

シフト集合の要素は、シフトのみで、シフト集合を許容していないので、AND操作は用意していません。

シフトは、1スタッフ1日あたり必ずどれか1個が割り当てられます。0個でも、2個以上でもなく必ず1個という特別な性質にしています。これにより内部で行う算術演算を容易にするという深い設計意図があります。

結論を申しますと、混乱を避けるために敢えて用意していません。