Ans.ご指摘通りバグです。
2025年7月31日木曜日
2025年7月30日水曜日
Graph縮約方法の検討 その2
2番目の方法は、期間の中間部に途中ゲートを置く方式です。例えば、Instane15の期間は、6週間ですが、中間あたりの3週間目にゲートを置きます。
いわば、マラソンゲート方式です。途中関門を決められた時間内に通過する、という制約を付加すると、グラフ容量を削減できることが分かりました。(イラストはCopilotで生成)
2025年7月29日火曜日
Graph縮約方法の検討 その1
1)Secondary Cardinalsの削減
SchedulingBenchmarksの制約を見るとメインは、勤務時間制約で両方向から効いています。が、そのほかにも、特定のシフトに対する最大値パターン数制約があります。これをSecondary Cardinalsと呼ぶことにします。今、Secondary Cardinalsを無視して最適解が求まったとします。その最適解が、(制約していなくとも)最適解を満足するならば、最初から無視しても問題なかった、と言うことが出来ます。
当然のことながら、それは、やってみないと適用できるかどうか分からないのですが、仮に適用できたとして、どれくらいの効果があるか見てみました。
その結果が下記グラフで、E1を削除したとき8MB→6MBになっているので、2MB約25%の効果が得られます。しかし、E1/E2の両方を削除しても全く同じ結果となりました。
2025年7月28日月曜日
Instance15 の厳密解が確定
Ryzon9700X、約一週間廻してようやく確定しました。
LB=3828
UB=3828
です。
十数年に渡り未解決だった問題の最適値が確定しました。
ルートLB=3823.64
2025年7月27日日曜日
Updated Report for Instance15
Subject: Updated Report for Instance15
Dear Tim Curtois-san,
I would like to report the exact objective function value for instance15 in the scheduling benchmarks.
Lower Bound (LB): 3828
Upper Bound (UB): 3828
I have also attached an updated UB dataset that differs slightly from the version previously reported.
Thank you for your attention.
Sincerely,
Tak.Sugawara
2025年7月26日土曜日
2025年7月25日金曜日
SchedulingBenchmarks instance15再挑戦
マルチスレッド化して様子を見てみました。スレッド数は8にしました。下記は、テスト中の様子です。
約2日走らせて、LB=3826.6 UB=3828となっています。なので、UB=3827が発見されれば、即終了です。後、僅かのように見えますが、実際には、BranchingTreeの爆発状態にあり、終了まで2週間程度かかる見込みです。(大体こういうテストをしているとWindows強制アップデートによりテスト途中終了となってしまうのが常です。)
経験的には、ここまで来て未だUB=3827を発見できないということは、その解は本当に存在しない、すなわちUB=3828こそが厳密解である可能性が非常に高い、ということです。ただし、UB=3827解が存在しないという厳密な証明のためには、LB=3827プラスアルファとなるまでBranchingTreeをスキャニングする必要がある、ということです。たとえば、LB=3827.01となれば、整数解は、3828以上ということになります。LB=3827では、未だ、整数解が3827に存在する可能性が残ります。
CPUの稼働率を見ると、
上のように、稼働率100%とはなっていません。Hyperthreadを加味して最低50%程度稼働しているべきなのがそうなっていないのは、キャッシュヒット率によるものであると推察されます。2025年7月24日木曜日
XML converter for Scheduling Benchmarks
未解決のスケジューリングベンチマーク問題について取り組みを始めました。
未解決なのは、
instance15
instance23
instance24
の3問です。
検討を始めるにあたって、スケジュールナースのCSV解をAutoRosterのフォーマット(XML)に読み込ませるためのコンバータを制作しました。これまでは、IFDEFコンパイルオプションにより、AutoRosterに読み込ませる解XMLをスケジュールナース内部で生成していましたが、いちいち再コンパイルする手間をなくすのが目的です。
以下使い方です。
とりあえず、求解を中止しました。2時間程走らせてUB=3828 になっています。この値はは、菅原システムズが所持する世界記録に同じです。
同じフォルダに、tak_solution.xml が出力されます。
AutoRosterを起動して、下記フォルダにtak_solution.xmlファイルを置いて読み込みます。
2025年7月23日水曜日
7月16日リリース機能その5
5)Historyのダイエット
5年程お使い頂いたお客さまのプロジェクトファイルのサイズは、12MBになっていました。これは、予定での状態をスタッフ名:予定のmapを過去も記憶しているからです。通常、過去の予定を覚えておく必要はない、と思われるので、消去できるオプションを作成しました。
以前のヒストリデータを消去:0だと、予定表示開始日より0日以前のデータが消去されます。設定ボタンを押して、スケジュールナースを終了すると、ダイエットが行われます。このお客様の場合、12MB→1.5MB程度とダイエット出来ました。
2025年7月22日火曜日
7月16日リリース機能その4
4)ExcelファイルオープンでNGの場合、ファイルクリエートにしていましたが、既存ファイルを新規ファイルにしてしまう問題がありました。これを改善し、ファイルが存在しない場合のみ、ファイルクリエート方式に変更しました。
この変更により、例えオープン可能でも読み込み不能なシートが含まれる場合(Invalidな外部参照等が含まれる場合)には、読み込みが出来ないメッセージ(Unexpected xml tag)が出て読み込みません。新規ファイルをCreateもしません。
この場合の対処方法としては、Excelファイルに含まれるInvalidリンクを削除してください。2025年7月21日月曜日
All optimal solutions for the 8-week INRC2
All optimal solutions for the 8-week INRC2 (Second International Nurse Scheduling Competition) have been uploaded using our newly developed solver, which is currently under active development.
These solutions have been verified using the official Validator, and the corresponding validation output is also attached.
For most instances, Schedule Nurse was able to obtain exact solutions within eight hours, although a few required nearly a full day of computation (Ryzen 9700X).
Upon completing all exact solutions for the Scheduling Benchmarks, we plan to write a research paper. Our new solver will conclusively address all instances that have remained without known optimal solutions for many years.
2025年7月20日日曜日
7月16日リリース機能その3
3)2026年5月24日以上、カレンダが更新できない問題の対策
カレンダマックスを2100年以上に更新しました。適用は、スケジュールナースPrivateとスケジュールナースサブスクリプションのみです。その他のエディションの適用は行わないのでご注意ください。
2025年7月19日土曜日
7月16日リリース機能その2
2) スケジュールナース のUpdate廃止
現在、3つのversionをメンテナンスしていますが、2つに集約します。
今後、スケジュールナースPrivateと、スケジュールナースサブスクリプションのみが、
今後のメンテナンス対象となります。
「スケジュールナース」は、開発に貢献した方等にも無償配布しておりましたが、スケジュールナースPrivateに移行をお願いします。該当の方は、マイクロソフトアカウントを取得の上、サポートにご連絡頂ければ、引き続き無償で使用できるようにいたします。
後述のように、スケジュールナースは、Updateしないと、2026年5月以降のカレンダが効きませんので、該当するバージョンをお持ちの方は、早めに切り替えをお願いいたします。
2025年7月18日金曜日
Q添付のファイルで予定入力のスタッフ4の2日に「希扱」の予定入力を入れた時のエラーの理由がどうしてもわかりません
Ans.
拘束*拘束制約がハード制約となっており、先月からの連続で見るとスタッフ4が1日に拘束とならざるを得ないことと矛盾するようです。
30日にスタッフ4が拘束であることは変えようがないので、拘束*拘束制約をソフト制約化することにより解が出るようにします。
2025年7月17日木曜日
7月16日リリース機能その1
1)スタッフプロパティシートの書き込みは、グループ定義とグループ集合を除く仕様に変更
従い、以下の3つのシートのみになります。通常は、グループ定義とグループ集合は、スケジュールナース上で操作することになると思いますので、その方が汎用性が高いと判断しました。
2025年7月16日水曜日
2025年7月15日火曜日
7月10日リリース機能その5
5)ユーザの予定原案の赤をロックとして読み込めない問題の対策
下記で、ユーザの予定は、赤フォントで記述されている部分があります。
ARGBではなく、RGB(255,0,0)をロックと解釈するように変更しました。これにより、赤部は、ロックが掛かります。
2025年7月14日月曜日
7月10日リリース機能その4
4)Excel取り込み出力設定の列数10Max→無制限に
2025年7月13日日曜日
7月10日リリース機能その3
3)Excel ExportファイルオープンモードをCreateからOpenに変更しました。
今まで、常に新しいファイルとして処理していたので、既存の別なシートが失われていましたが、DefaultをOpenに変更したので、別なシートが存在する場合には、消すことなく追加となります。
上は、ユーザフォーマット解の書き込みを行ったファイルに、
■スタッフプロパティの書き出しと、
■予定の書き出しを行ったシート群になります。
2025年7月11日金曜日
Q.男性3人、女性3人配置したいため、列制約で制約タイプを最大―最小スタッフ数とし最大3最小3としたが4人以上配置されてしまう。
Q.
下図のように女性が3人のところ”入り”に4人配置されてしまっているのは何故?
当該制約部分で集合をマウスホイールボタンを押して確認すると、”女性”集合にはなっておらず、別な集合名で記述されているようです。
従って、
■仕様:女性3人と
いう仕様に対して、制約は、
■制約:生活介護 休日可女性 3人
になっています。他に”女性”で制約している記述が見当たりません。これが原因と思われます。
Note:
部分集合に対して制約して、全体集合で制約していないことによる問題は、よく遭遇します。(私もよくやらかしてしまいます。)
対策としては、
■スケジュールナースは制約通りに動く
■制約していないところはフリー(何が割り当てられるかは誰も分からない)
ということを常に頭に置くこと。
■制約をしている箇所で、マウスホイールボタンにより、集合(Day集合、グループ集合、シフト集合)をよく確認する。
ということに尽きるかと思います。