Closed pdb5627 closed 9 months ago
Thanks for the PR.
While this change does avoid retrying the same scenario with the same solution from the hub, I think it does not ensure that every scenario is eventually tried.
If the hub algorithm is moving at approximately the same speed as this spoke, this implementation will try the same few scenarios over and over again.
I have an idea for how to do both, but I won't have a chance to implement it for a week or two. Basically, the scenario cycler should store the first index tried with the current solution from the hub, and if it comes back to that index it should stop and wait for a new solution from the hub.
Can you explain why it would keep trying the same few scenarios again and again? One of my changes was that starting a new epoch does NOT reset the _cycle_idx
. When a new solution comes in, the epoch reset clears out which scenarios have been tried but the looper continues with the next scenario. I have done some runs with this proposed change, and I could be wrong, but I don't think see it repeating the same few scenarios.
Can you explain why it would keep trying the same few scenarios again and again? One of my changes was that starting a new epoch does NOT reset the
_cycle_idx
. When a new solution comes in, the epoch reset clears out which scenarios have been tried but the looper continues with the next scenario. I have done some runs with this proposed change, and I could be wrong, but I don't think see it repeating the same few scenarios.
You are correct. I should do fewer code reviews on my mobile device.
Partially fixes #357. Instead of starting a new epoch immediately at the end of the last one, start epochs when new solution sets are loaded. Scenario index is set at instantiation and does not reset with new epoch.