Skip to content
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

List of Open Problems/Potential New Features #12

davidhallac opened this issue Jan 16, 2016 · 0 comments

List of Open Problems/Potential New Features #12

davidhallac opened this issue Jan 16, 2016 · 0 comments


Copy link

davidhallac commented Jan 16, 2016

Hi SnapVX Users,

We are using this page to include a list of ideas that we hope to eventually add to SnapVX in future releases. Please let us know if you have any ideas and/or comments, or if anything is unclear. Furthermore, if you are interested in contributing to SnapVX, this is a good place to start!

  1. Additional Examples - It is always nice to have more examples/applications. If you think of any good ones (ideally from new and relevant fields, with interpretable results), feel free to send them our way. We can include them in the download package and on the website, so users have a better grasp of how to apply SnapVX to real-world problems

  2. Adding fast solvers - Often, users of SnapVX solve problems where all nodes and/or edges share a common form (see: bulk loading). In these examples, the same general problem will be solved thousands or even millions of times. Therefore, there is a real incentive to speed up this repeated operation. If users are experienced with optimization, they should be able to define a function which solves the proximal operator problem, and pass to the solver that as an attribute of the node/edge (instead of the cvxpy (objective, constraint) tuple). Then, ADMM subproblems can check if that node/edge has defined a ProxOp function or a CVXPY problem. If it’s the ProxOp, it gathers the relevant parameters and calls the function. The program should then write the solution back to shared memory, so the overall problem doesn't even notice the difference between this and just calling CVXPY (except that it is faster!)

  3. Database of Common Proximal Operators - Once we implement part 2, users will want a database of common proximal operators. That way they will not need to write their own from scratch every time. See "Proximal Algorithms" by Boyd and Parikh for a comprehensive list of proximal operators to implement.

  4. Catching Common Problems - Once part 3 is built out, if the user defines CVXPY objectives, we can look through to “catch” ones with fast solutions. Then, behind the scenes, we can switch out the CVXPY call for our proximal function. The user doesn’t notice, but the problem will solve much faster

  5. Distributed SnapVX - Currently, SnapVX is set up to run on a single machine, parallelizing across different threads of a single computer. This was a deliberate choice, as it is meant to have “out-of-the-box” functionality for casual users. While large memory machine are able to scale to tens or even hundreds of millions of unknown variables, there are always examples which are too big... The ADMM algorithm behind SnapVX is fully capable of being implemented in a distributed computing setting. As such, it would be possible to implement a distributed version of SnapVX.

The SnapVX Team

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

1 participant