2019年8月19日月曜日

one drive 版32ビット版

一日がかりでコンパイルしました。開発は、1年以上64ビット環境でしか行っていませんでしたが、
意を決して、ソースから全部のコンパイルを行いました。使っているライブラリの量が尋常ではないです。多分エディタのソースまで含めたら50万行はあると思います。

C#系のDLLは、一つあれば足りるので便利です。C++Native系は、どうしても32ビットと64ビットで分けざるを得ないです。

とりあえず、HomeMachineは32ビットなので、これからはHome MachineでPythonコードを書きます。

2019年8月13日火曜日

2019年8月11日日曜日

ClosedXML DLL エラー

ExcelのImport・Exportに使用しているClosedXMLで、クラッシュします。(Excel書き込み読み込み時)
原因を見てみるとDependencyDLLの一つでFASTMEMBERxxが見つからないというエラーです。
このClosedXMLは、結構な量のDLLが必要で、それらを全て最新にしてみても状況は変わりません。

原因は、特定のDLL Versionが必要なようでした。明示的に読み込ませる必要があります。schedule_nurse3.exe.config というファイルを添付することで、明示読み込みが出来るようですので、今後添付するようにします。Onedrive上の更新は、Excel読み込みライブラリの更新を含めて8月13日を予定しています。

2019年8月10日土曜日

凸最適化 first-orderに注目

OR学会誌 6月号で、一次法の特集が組まれています。タイムリーな特集です。一次法の逆襲という的を得たタイトルです。

線形目的関数の世界では、Simplexと内点法が幅を利かせていますが、大規模な制約の場合、例えば、NSPで言うと6ヶ月とか1年とかになってくると、Simplexでは苦しくなってきます。そこで内点法の出番ですが、商用ソルバーはともかく手に入る実装では、やはり厳しいものがあります。そこで最近、注目しているのが、first-orderです。

http://www.orsj.or.jp/archive2/or64-6/or64_6_314.pdf
http://www.orsj.or.jp/archive2/or64-6/or64_6_316.pdf
http://www.orsj.or.jp/archive2/or64-6/or64_6_335.pdf

画像解析、機械学習で注目されていますが、NSPでは、未だ論文が発表されていません。

現在、SC3 algorithm4は、未完成です。汎用化まであと一歩なのですが、殆どの実用的な問題ではalrogithm1に負けます。優勢なのは、ほぼ学会ベンチマークのみです。しかし、実務問題の中でも大規模かつ複雑な最適化問題でalgorithm4は,より厳密解に近い解を得られる可能性があると見ています。実用的な意味で、algorithm1が最適なことは変わりありません。しかし、エラー数が多種、多様、多数ある場合、つまり探索時間が一桁・二桁余計にかかるような問題では、数理的なアプローチが有利になってくる、ということだと理解しています。

数理的なアプローチとしては、線形ソルバーを使うことになる訳ですが、今までは、Simplex・内点法のアプローチしか考えられなかったのですが、first orderソルバーも可能性が出てきた、ということです。

2019年8月9日金曜日

週あたりの勤務回数 の実装

これを制約開始日ベースで記述しようとすると


制約表示日制約開始日
オフセット0123456789101112131415
1234560123456012
端数第一週第二週




最後の週が2月28日を除いて端数になってしまいます。
そこで、曜日ベースで記述することにします。


制約表示日制約開始日
オフセット0123456789101112131415
第一週      


その場合、毎月、曜日集合をGUIで指定します。制約開始日または、それ以前の月曜日を基点として、以降未来永劫月曜日基準で制約することにします。

ユーザは、毎月の月曜日を指定する必要があります。年間カレンダで年単位一回でGUI指定することは出来ます。しかし、その場合でも最後の週に対して目標値の修正は、必要です。やはり面倒なので、Pythonで記述することにします。

<プロジェクト名_property.pyの記述を利用する>

プロジェクト名_property.pyを覗いてみると、
次のように定義されています。

今月は、Dayオフセット6-36まであることが分かります。(上図どおり)
これで、月は、Dayオフセット3,10...
であることが分かります。最後のところだけ、31,32,33,34,35,36の6日間になり端数処理が必要となります。

#daycollection
今月=[6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36]
日=[2,9,16,23,30]
月=[3,10,17,24,31]
火=[4,11,18,25,32]
水=[5,12,19,26,33]
木=[6,13,20,27,34]
金=[0,7,14,21,28,35]
土=[1,8,15,22,29,36]
全日=[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36]
祝=[16]

月曜日のDayオフセットテーブルを読み込んで各週の制約を書けばよい事になります。

<スタッフプロパティに定義されたスタッフを見る>
週当たりの勤務回数は、特定の契約スタッフのみについて行われます。この情報は、スタッフプロパティで記述されていて、以下の通りプロジェクト名_property.pyで記述されています。

#digited group
公休数={1:13,2:13,3:13,4:13,5:13,6:13,7:13,8:13,9:13,10:15,11:13,12:13,13:13,14:13,15:13,16:13,17:13,18:13,19:13,20:13,21:13,22:17,23:13,24:13,25:13}
週あたりの勤務回数={22:3}

公休数と、週あたりの勤務回数がMapで記述されています。PersonOffset:回数の形式に
なっています。PersonOffsetは、0ベースでのスタッフナンバーです。Person1の公休数は13、Person22の週あたりの勤務回数は、3という風に定義されています。定義されていないスタッフについては、該当Mapでは記述されません。例えば、Person0の公休数は定義されていません。定義されていないのは、制約対象外となります。

週あたりの勤務回数対象者は、上記Mapから得ることが出来ます。

最後は、端数処理です。週の日数が7であるときは、通常処理、それ以外のときは、端数処理で、
目標値をリニア補間で修正します。つまらないところで、ハードエラーは起こしたくないので、エラー許容量は、多めに設定(4)します。この値は、GUIでは修正されません。


<確認方法ー単独で試験する>
各週の値を、GUIでは表示することは出来ません。また、その他の制約により、上記制約がエラー0で動く保証がないので、それ以外の全てのソフト制約と予定を外して、必ず上記制約がエラー0で出来る環境を整えてやります。


以下のログを得ました。

コンパイルの準備中ソルバを呼び出し中です。
 python propertyファイル生成を開始します。
 python propertyファイル生成が終了しました。

A23の週当たりの勤務回数は3回に制約
月曜日 3
月曜日 10
月曜日 17
月曜日 24
月曜日 31
2に目標値を設定しました。


予定通り、エラーは、出ていません。person22(A23)の週当たりの勤務日数をGUI上の解で確認します。
確認後、消した予定を元通りにして(取り消し動作)、ファイル保存して終了です。

これで、カレンダ参照設定は必要なく、将来の変更(週あたりの勤務日数、対象者)に対しても強い記述が出来ました。Excel上のスタッフプロパティだけで指定が可能となります。



2019年8月8日木曜日

Python EditorをScintillaNETに変更

AvalonEditからScintillaNETに変更しました。

https://github.com/jacobslusser/ScintillaNET

Pythonでは、インデントそのものが文法になっており、スペースとタブとの混在等が、文法エラーとなります。その手のエラーで悩まされる時間を少なくするにはWhiteSpaceをVisibleにしてくるエディタが必要です。AvalonEditでその設定を探したのですが、見つけられませんでした。

そこで、NotePad++で使っているライブラリScintillaNETを試したみたところ、すんなり実装できたので、エディタを変更することにしました。

下のようにちょっと見栄えが悪くなりますが、タブが→で明示されており、これでインデント絡みのエラーは、解消できると思います。