List of Open Problems/Potential New Features

[davidhallac]

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.

Thanks!
The SnapVX Team