[mlpack-git] [mlpack] WIP: Refactor LRSDP to support more general linear constraints (#580)
Ryan Curtin
notifications at github.com
Wed Mar 23 10:33:20 EDT 2016
Hey Evan,
Sorry for the slow response. Things have been busy and I haven't had a chance to look further into this until now.
I wonder, should we even be including an `Evaluate()` and a `Gradient()` function in these constraint types? Or instead should we simply be allowing access to the A matrix (however it should be represented) and the b vector, and allow the optimizers to do what they need with those? (This is closer to how the current code works, but the current code has a lot of template specializations that I'd love to do away with, favoring just one non-specialized implementation instead.)
This is simple for the sparse and dense constraints, which can just return A as types `arma::sp_mat` and `arma::mat`, respectively, but the linear constraint is a bit harder because we want to represent A as (aa'). We could possibly use the Armadillo type that represents two vectors to be multiplied for this... it'd look something like `arma::glue<arma::Col<eT>, arma::Col<eT>, arma::op_multiply>`. If we return that type for the A matrix and then use that in a larger Armadillo expression, I think we can reasonably expect that the template metaprogramming that evaluates Armadillo expressions will do a decent job.
Is what I'm saying making any sense? Please let me know if not. It has been a while since I have thought about SDPs. My concern though is that ideally we don't want to include to much optimizer-specific logic in the constraints, and it seems like in this case that's what's happening with `EvaluateLR()` and `GradientLR()`; if we were to come up with another technique for solving SDPs, like for instance with block diagonal representations instead of low-rank, we would probably need an `EvaluateBlockDiagonal()` and `GradientBlockDiagonal()` in each constraint, which I'd like to avoid.
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/mlpack/mlpack/pull/580#issuecomment-200369662
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.cc.gatech.edu/pipermail/mlpack-git/attachments/20160323/e3d99fff/attachment.html>
More information about the mlpack-git
mailing list