Try to generalize QUBO independetly of framework used

[BrunoRosendo]

This problem came because CPLEX and DWave implementations are very similar, even though they use different frameworks. It would be different to refactor the code so that I have an adapter to both frameworks and can simply set vars/constraints/objective one time

[BrunoRosendo]

I also think solution conversion should be in the models while build_var_dict should be in the solvers

[BrunoRosendo]

Since creating all the logic about linear expressions, iterators, vars, etc. would be too much trouble, I'm thinking of instead using either cplex or dimod for my custom model and then adapt to the other.

I need to weight the advantages and disadvantages of each

[BrunoRosendo]

CPLEX good points:

• Easy to retrieve var information
• Constraints seem relatively easy to parse. Possible to re-use expression parsing from the objective
• docplex is more of a standard for optimization

CPLEX bad points:

• Objective and expressions seem tricky to parse

dimod good points:

• Objective (and other expressions) seem a bit easier to parse, but still bad
• Constraints seem relatively easy to parse. Possible to re-use expression parsing from the objective

dimod bad points:

• Var retrieval is a bit more cumbersome
• docplex doesn't have the string or tuple versions for adding constraints/objective, which is useful here (dimod does)
• dimod is more specific for dwave

Based on this analysis, I think cplex is slightly better. However, converting linear expressions from one model to the other will be tricky...

[BrunoRosendo]

Tomorrow I'll try this approach. I think if I use cplex and the tuple version of dimod for conversion then it's not too bad

[BrunoRosendo]

the refactor went well but there's some kind of bug. The trip requests in RPP are not being respected in either of the solvers