search

N-Wouda / Euro-NeurIPS-2022

OptiML's contribution to the EURO meets NeurIPS 2022 vehicle routing competition.
Other
16 stars 2 forks source link

A generic solver interface #122

Closed N-Wouda closed 2 years ago

N-Wouda commented 2 years ago

This PR:

Configuration is still done at each call site. That's for a later PR (the third - the next PR will deal with strategies and the dispatch mechanism).

N-Wouda commented 2 years ago

I'm using one folder, strategies/, for the dynamic and static solver stuff. In a follow-up PR that'll probably split into somthing with a static/dynamic subdivision, and a dict-based dispatch mechanism. For now it all just needed a home, and python/ felt even more meaningless.

jmhvandoorn commented 2 years ago

So how does this relate to #117 [+ it's 3rd step that's on the shelf, refactoring the dynamic part]? It feels like this is partly doing what's also in #117, that will mainly cause a lot of merge conflicts with #117, that's doing quite the same (and more)

N-Wouda commented 2 years ago

This is what I had intended for #117, before that one grew massively with (IMHO) unrelated features. We could revise #117 to be about config management?

I continued on #117 yesterday but lost the plot about 20min in. So I'm doing the equivalent refactoring in a few small PRs, rather than one large one.

N-Wouda commented 2 years ago

@jaspervd96 can I merge this in?

jmhvandoorn commented 2 years ago

I continued on #117 yesterday but lost the plot about 20min in. So I'm doing the equivalent refactoring in a few small PRs, rather than one large one.

If you feel like that's the way to go, feel free to do so and merge/complete this the way you have in mind.

It will probably mean that every change in #117 has to be redone manually, since it will give merge conflicts everywhere with this PR. Also be aware of the existence of this branch that is on the shelf for a while and builds on #117 and handles the config management for the dynamic as well, including a major cleanup / aligning of functions that are using this configurations.

Both are in a state that everything runs and works. My idea would be to start from there to see what we want different in e.g. the config management, rather than redoing everything. But again, feel free to disagree and continue on the other path.

I think my time is better spend further testing the additional rollout strategies I made a while ago. (Which would be a lot easier based on the latest branch I mentioned, instead of the current main)