Solvers are now classes, but many things are expecting CreateSolverType functions

[juropo]

What is the current behavior?

• Solvers were relatively recently updated to be classes, that all seem to implement an init function and a solve function, which is called when the problem should be solved.
• This change is not reflected in many other parts of the code base.
• tools->generics.py still only defines CreateSolverType which is a callable that returns a callable and not a class. There is no generic definition for what a solver class looks like.
• Other code uses the CreateSolverType. For example, tools->utils.py->guess_best_solver claims it returns a CreateSolverType, but in reality returns one of the solver classes. This may cause errors with whatever code uses this function.
• Some of the solvers' init functions claim in the docstring that they return CreateSolverType.

Describe the solution you'd like

• Remove the CreateSolverType and add SolverType (or something) that tells what other code can expect from the solvers.
• Fix all the errors that result from removal of CreateSolverType by updating the code to use the solver classes.

What is the motivation/use case for changing the behavior?

• Right now, what the code does does not match the type hints and documentation, so something needs to be changed.

Describe alternatives you've considered

• An alternative could be to implement some kind of function that adheres to the format of CreateSolverType and that will initialize solver classes and return pointers to the solve() functions within them. This seems unnecessarily convoluted.
• The other alternative would be to reverse solvers back to functions that return functions instead of classes, but there was a reason why this change was made.

Additional context

• This involves going through a lot of code, but is not especially difficult to do.
• We should maybe consider whether solver classes by default should implement some other functions as well, or if just having init and solve functions is enough.

[gialmisi]

Indeed, this should be fixed. As far as I know, this is mostly an issue with the types, which should be definitely checked. Can you elaborate what your mean by

Right now, the code does not work, so something needs to be changed.

I think the changes you suggested

Remove the CreateSolverType and add SolverType (or something) that tells what other code can expect from the solvers.

Fix all the errors that result from removal of CreateSolverType by updating the code to use the solver classes.

should be enough.

For instance, in desdeo/tools/generics.py, CreateSolverType = Callable[[Problem, SolverOptions], Callable[[str], SolverResults]] can be replaced with a generic class, e.g., SolverBase, which could look like

from abc import ABC, abstractmethod

class BaseSolver(ABC):

    @abstractmethod
    def solve(self, problem: str) -> SolverResults:
        pass

I would keep this as simple as possible for now. If we need more guarantees from a solver, other than the solve method, then we can update this. This base class should be compatible with all current solvers.

@Matskuu I am assigning this to you. If you have questions, feel free to ask for more details.

[juropo]

Indeed, this should be fixed. As far as I know, this is mostly an issue with the types, which should be definitely checked. Can you elaborate what your mean by

Right now, the code does not work, so something needs to be changed.

I think I worded that poorly. I'm not aware of any errors that arise because of this. I just meant that the code does not work as it claims to. I'll update the issue to reflect this better.

[juropo]

I believe this has been resolved