-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Solvers API slightly inconsistent #1197
Comments
Heads-up to @mehrhardt and @adler-j for comments. |
This falls down to what I always ask: consistency with the paper or not? :-p As long as the documentation is clear I don't think it really matters. |
My suggestion is either rename to |
I think it would be good if our algorithms are consistent. That is more important than the consistency with the papers. To me, it is more natural that f is composed with an operator as the data term often comes first and f < g in a lexiographic sense. I suppose some of you feel the other way :) |
Not so sure about that. For some algorithms that are not really of primal-dual type (like ADMM?) the names "primal" and "dual" would be quite a stretch.
I fully agree with this. In papers, authors use whatever they like best, and if we mirror every paper notation we end up with a hopeless mess. There's also a practical side to it: when you want to switch between two solvers that handle exactly the same type of problem (like PDHG and ADMM), you shouldn't have to switch the roles of the functionals every time. The same holds when using Forward-Backward or Douglas-Rachford with just one
This point is perhaps more a matter of taste and practicality. Going with |
Did we arrive at a decision here, I'm currently doing this at @kohr-h's suggestion, but I'm not quite sure what to do. For sure, only changing pdhg is the easier route. |
I think both here and at other places, it would be good to make a decision such that we can go forward. Given that every solver has their own range of problems that it is applicable to, this "decision" can and should be handled in a flexible manner. However, for the most standard problem class it seems that we now settled on |
Can this be considered done, given #1286 where the interface of PDHG was changed? |
Oh yes, of course. |
Of the convex solvers we have so far, most have the structure that
f
is not composed, and the compositions with operators happen in theg
functional(s). Only PDHG does it the other way around.Should we change it?
I'm asking since I'm gonna add linearized ADMM which solves the same problems as PDHG, and I want this to be settled before.
The text was updated successfully, but these errors were encountered: