Reasoning behind the Problem class

[adler-j]

When writing some examples I have come to realize that we pretty much always write:

prob = proximal.Problem(...)
prob.solve()

Looking through the proximal code base, the only place I see a divergence from this pattern is where the set_ methods are tested, never in use.

Is there a reason that the Problem class exists? Why could the above not simply be written in a functional manner:

proximal.solve(...)

[SteveDiamond]

Right now it's true the problem class doesn't do much. But eventually it could be used to cache work when the same problem is solved repeatedly for different data/hyper-parameters, or to store the solver status and things like that. This is what happens in cvxpy and at least I personally find it useful.

[adler-j]

It certainly makes sense for that, we had a very similar discussion in ODL, but our decision was to leave this as a detail and go for the proximal.solve(...) syntax as the "default".

A short suggestion in order to make your syntax more concise would be to add `solve´ to proximal, something like

def solve(*args, **kwargs):
    problem = Problem(*args, **kwargs)
    problem.solve()

since this seems to be the most common use case.

Another suggestion would be to remove the solver related parameters from Problem, i.e. solver, lin_solver etc and move them to Problem.solve. That would make the distinction of a problem and a solution to that problem more clear.