feat: add support for setting initial solutions with cbc

[KnorpelSenf]

This is a first attempt at adding support for initial solutions. For now, only coin_cbc is supported. Compatibility with more solvers can be added in subsequent pull requests.

For some reason, the added test still fails. It's probably a dumb oversight, but until somebody spots it, I would be happy to receive feedback on whether the API and implementation of this feature go in the right direction. If you have complaints about the naming (should we rename set_initial_solution to initial_solution or initial or initialize or init or set_initial or with_initial_solution?), please let me know and I'll change it.

Towards #55.

[lovasoa]

The design seems good to me

[KnorpelSenf]

Awesome! Now I just have to find out why the problem in the test has no solution the second time I compute it

[KnorpelSenf]

I just simplified the test a lot and that fixed it. I am not sure if there is still something wrong now?

@lovasoa do you think we now need a more ergonomic way to construct CoinCbcSolutions? The current changes basically only make it easy to solve a problem once and then recreate it. But what if somebody already has an initial solution without having solved the problem via this library?

[TeXitoi]

But what if somebody already has an initial solution without having solved the problem via this library?

It’s an important case I think. In my usecase, I have a solution that I know is feasible and good quality.

[KnorpelSenf]

But what if somebody already has an initial solution without having solved the problem via this library?

It’s an important case I think. In my usecase, I have a solution that I know is feasible and good quality.

The same is true for me. The question remains if we need a more ergonomic API to construct a solution. Maybe not, because we're going to have a way to give an initial value to each variable? I'm undecided on this so far

[lovasoa]

Yes, I think we need a way to build solutions for this to be helpful. Maybe implement FromIterator<(Variable, Value)>

[KnorpelSenf]

@lovasoa do you want this done in this PR? If no, what else is needed before this can be merged?

[lovasoa]

Yes, I think the feature is not very useful without this

[lovasoa]

Great ! I think we should accept an iterator instead of a vec, and then we are good to merge 👍

[KnorpelSenf]

Nice, will do!

I can imagine that setting each variable individually is not as good as setting the entire solution at once if one has a full solution available. Should we still have a way to set complete initial solutions?

I honestly don't really see how that would be useful because I don't see a way to construct these solutions, but I just wanted to make sure we're on the same page with this:)

[lovasoa]

The current implementation looks good to me. I'll merge it as soon as you make the fix.

[TeXitoi]

If we could modify a model, it could be useful to use the solution. An example is lexicographic objectives:

• you create the problem with the first objective
• you set a constraint "the previous objective must be at least the quality of the solution found"
• you set the next objective
• facultative, but can improve performance a lot: you set the initial solution to the previous found solution
• you continue until all objectives are optimized.

But, as far as I remember, the current interface doesn’t allow this.

[KnorpelSenf]

I agree. I would also like to be able to modify problems and then reuse previous solutions from previous runs. But this is out of scope for the current PR. I might look into this in the future.

[lovasoa]

🚀