Feature/fix resume nm

[KanaiYuma-aist]

Fixed ValueError when resuming twice using NM. (issue #33)

[github-actions]

Unit Test Results

238 tests  ±0   238 ✔️ ±0   36s ⏱️ ±0s
    1 suites ±0       0 💤 ±0 
    1 files   ±0       0 ❌ ±0 

Results for commit ee81787. ± Comparison against base commit 917fd7d.

♻️ This comment has been updated with latest results.

[KanaiYuma-aist]

Fixed a bug that reading (deserialize) fyr_order in work/state/*/optimizer.py failed when resuming twice using NM.
I assume that the proper behavior is appending v instead of appending dict_objects['_history'][key].
I compared the code before the change without resume and the code after the change with resume and confirmed that there is no difference except for the loop_count: in the contents of work/state/*/optimizer.py.

Work without resume before change of code
NM_no_resume_work.tar.gz

Work with resume after change of code (resume in 5,10trial)
NM_resume_fix_work.tar.gz

@tkokada
If there are any problems with implementation, please comment.

---

NMを用いて2回resumeすると、work/state/*/optimizer.py 内の fyr_order の読み込み(deserialize)に失敗する現象を修正しました。
dict_objects['_history'][key] を append するのではなく、 v を append するのが正しい挙動ではないかと推測します。
変更前のコードでresume無しで実行するのと、変更後のコードでresume有りで実行するので比較して、
work/state/*/optimizer.py の内容に差分が loop_count: 以外存在しないことは確認済みです。

実装に問題があれば、コメント下さい。

[aramoto99]

@tkokada
The problem is the list named fyr_order, which is not used for the nm-calcuration in the first place, so I thought it would be OK to remove it.
Is there a possibility that fyr_order will be utilized in the future?

[tkokada]

@KanaiYuma-aist @aramoto99 You are right. fyr_order is not used anywhere...