-
Notifications
You must be signed in to change notification settings - Fork 121
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
Dev plan #320
Comments
I'm ok with at least the high-priority you defined above |
For those following this plan: there’s a brief detour to #328, which came about partly trying to get the tests working for MPB and MOI simultaneously, with the plan of supporting both— at least until it’s inconvenient; since Convex has a few points of contact with the middle layer, at this point it’s not really a problem to support both because the MPB code is already written. If we get to my speculative point above, I’d probably drop MPB. Edit: this also solves another minor problem, namely we no longer need the can_solve* methods, since we get regex excludes with the problem depot. |
We can’t super easily support both MPB and MOI simultaneously because they each represent SDP constraints in a different way, and we’d need a different conic_form! for each. We could propagate down the tree the information of whether or not we’re using an MOI solver. But I’m not sure that’s worth it, since it’s adding complexity to support superseded code. |
See #361 for new thoughts on v0.13. |
0.13 is out! The next steps that I see are #346 and #358 to setup a coherent public API as a minor release, with deprecations for the breaking changes, then a 1.0 release with that API (and the deprecations removed). After that I’d like to focus on a non-breaking internals revamp for performance and ideally #310 as feature versions. I’m not sure when all that will happen though though, possibly not for months, so if someone else has a different plan they want to pursue sooner, that seems fine as well :). |
A bit of an update:
One other note: as I mentioned in my JuliaCon talk (https://www.youtube.com/watch?v=iczcGK6G_sE), I may not be working on Convex.jl as often from now on. (But this MOI updating thing has gotten me excited again...) |
I haven't been working on this since July 2020, so this isn't really an active plan, and I'll close it at this point. |
I'm planning on making some changes and improvements, and I thought I'd write out my plan, in case there are objections and just so these changes aren't coming out of nowhere. It's hard to say how much of this I'll actually get done, but I've consistently been feeling pretty motivated on weekends to work on this, so hopefully it's not too wildly ambitious.
Ordered priorities:
src
folder so there should be little chance of breaking anything.id_to_variables
). This is half the cause of Memory leak #83, and I think there's a relatively easy fix. The hard bit is to make sure to not hurt perf too much, since we will have to do the work locally in the problem instead of once at variable construction time, so benchmarking is key.can_solve_sdp
type methods, and clean up the code a bit (either get rid of MBP or make Convex usable with both MBP and MOI). Benchmarking is important here too, to make sure we haven't hurt model formulation speed with the new internals generating MOI functions and constraints. Ideally, we might get improvements.AbstractVariable
interface; allow variables to carry constraints #358) with an aim towards 1.0Optional:
AbstractTrees
dependency + methods, so a Convex.jl problem can be seen as anAbstractTree
. I thought I might need this for getting rid ofid_to_variables
, but I think I won't now, so it's kind of optional. It's nice because you can useAbstractTrees.print_tree(p::Problem)
to generate a nice representation of the problem. This might actually give a nicer way to show the problem in the REPL which we could use forshow
. You can also use GraphPlots master and doplot(TreePlot(p))
wherep::Problem
and get a visual representation of the problem (which was my motivation for AddAbstractTrees
plotting JuliaPlots/GraphRecipes.jl#80). The only downside is the dependency, which is 700 lines of Julia with no dependencies itself, which doesn't seem too bad. I might PR this one soon because it's already done locally.(WIP) Allow variables to carry constraints, custom variable types #313AbstractVariable
interface; allow variables to carry constraints #358. This PR touches almost every use ofVariable
(if only trivially replacing it byAbstractVariable
) so it will need rebasing with each of the above changes. But it's really an enhancement / feature, not blocking for MOI, and MOI is probably more important. It shouldn't have any perf consequences, but benchmarking would be nice to confirm. I see this as opening the door to DSLs based on top of Convex, and it may be better to wait for some of the big internals changes (e.g. switch to MOI) first, so that there's a stable base for those DSLs.solve!
s? #318: seems important for makingfix!
andfree!
have meaningful perf advantages for model formulation.Speculative:
conic_form!
works to be closer to MOI. Theoretically, eachconic_form!
could be directly generating MOI functions and constraints, instead of usingConicObj
's. This would give nicely typed objects which would hopefully address performance issues like Massive RAM for moderate problem #254, and maybe others (which I haven't looked into too much). The end-state of this would be Convex being a front-end to MOI like JuMP, but with different syntax, DCP checking, and some pseudo-bridges on top. I think that's a reasonable place to be, and positions Convex well to take advantage of MOI's fast + high quality development. This would likely involve rewritingconic_form!
for every atom.The text was updated successfully, but these errors were encountered: