Closed N-Wouda closed 1 year ago
We could also present it as a Python package, and keep the libhgs
as an internal thing. That way we keep some control over the implementation/ABI, and tie everything more tightly to the Python/data science ecosystem.
This whole issue is mostly about positioning. What's our main audience going to be? It's probably not OR people (academics, practitioners) interested in VRP-type heuristics. Those will continue to write their own things anyway, as they have for the past decades.
I think our best proposition is to make our work very easy to use for OR people solving VRP-type problems that are subproblems of some other thing, and for ML people wanting to use a really good heuristic solver to benchmark/compare their own things. For either group, Python is a very safe bet.
Plus, as Wouter has shown in his Colab notebook: once you have the bindings, it is trivial to mix-and-match Python code with the C++ side.
@wouterkool @leonlan what do you think of this?
I think our best proposition is to make our work very easy to use for OR people solving VRP-type problems that are subproblems of some other thing, and for ML people wanting to use a really good heuristic solver to benchmark/compare their own things. For either group, Python is a very safe bet.
I agree with this, but I also think that we can (and should) offer more.
What's our main audience going to be? It's probably not OR people (academics, practitioners) interested in VRP-type heuristics. Those will continue to write their own things anyway, as they have for the past decades.
Plus, as Wouter has shown in his Colab notebook: once you have the bindings, it is trivial to mix-and-match Python code with the C++ side.
I think that OR people working on heuristics can benefit tremendously from this package as well. The bindings provide a very convenient way to conduct new research. Examples could be: trying out different crossover operators (as we did with SISR), or use the LS procedure for your own heuristic (as Wouter’s notebook shows).
I see two “products” in our codebase:
import hgsvrp
result = hgsvrp.solve(instance)
2. a modular interface to the HGS solver, targeting users that want to extend HGS/or use its components.
```python
import hgsvrp.components
alg = hgsvrp.genetic_algorithm(hgsvrp.components.local_search)
alg.add_crossover_operator(my_crossover_operator)
# add other stuff to make HGS complete, and run HGS with your own implemented crossover operator
or
import hgsvrp.components
alg = my_heuristic()
alg.add_local_search(hgsvrp.components.local_search)
result = alg.solve(instance)
This enables researchers to rapidly prototype ideas, with state-of-the-art solver components. If they want to take this further, then can always extend the C++ implementation (right?).
I think this makes our contribution much stronger, as each product supports a completely different research direction.
For the documentation, we could have a section on the “simple usage”, and a section on “advanced usage”.
Same thing for the paper. Additionally, we could highlight all kinds of research ideas and work out an idea for the “simple usage” (e.g., training a neural net to predict costs) and an idea for the “advanced usage” (e.g., trying different crossover operators such as the AOX operator.). [Not sure if the latter is necessary, just an idea.]
I see two “products” in our codebase:
From what you describe, all I see is one thing: a Python package :-).
I see two “products” in our codebase:
From what you describe, all I see is one thing: a Python package :-).
Oh, I completely tunnel-visioned here :-) Yes a Python package!
We're doing a Python package, so I am closing this issue as resolved.
Right now, we compile:
libhgs
. This contains most of the compiled components.hgs
. This thing can be called from the command line to solve a problem. Useslibhgs
.hgspy
. This thing can be imported from Python as a regular module.The odd one out here is
hgs
, the executable. All other things present themselves as libraries. I suggest we providelibhgs
andhgspy
as 'core products', and keep the executable around only for testing and profiling.