What do we want to offer?

[N-Wouda]

Right now, we compile:

• A library, libhgs. This contains most of the compiled components.
• An executable, hgs. This thing can be called from the command line to solve a problem. Uses libhgs.
• A Python module, 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 provide libhgs and hgspy as 'core products', and keep the executable around only for testing and profiling.

[N-Wouda]

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?

[leonlan]

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:

1. a complete and easy to use HGS solver, targeting users that simply need to solve the VRP problems for some other use. The interface should be super simple, removing all implementation complexity.

   
   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.]

[N-Wouda]

I see two “products” in our codebase:

From what you describe, all I see is one thing: a Python package :-).

[leonlan]

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!

[N-Wouda]

We're doing a Python package, so I am closing this issue as resolved.