Leaving JuliaOpt - where to?

[pkofod]

Edit: Just to clarify the "breaking up :broken_heart:" thing was a joke. Optim is simply moving out of JuliaOpt due to restructuring of JuliaOpt, and as a part of those organizational changes, we (in JuliaOpt) have decided that it's better for Optim to move to a separate org. No drama here :)

JuliaOpt and Optim are breaking up :broken_heart: This is happening in full cooperation between the MathProg-stack, and Optim+friends, but hasn't been official until now. Since @johnmyleswhite it fine with the change, I am not going to argue against it.

(and, to be honest, I can see the value in having a clear org for MathProgBase at the center of the modeling extensions and the backends).

This means that we're moving to a new home. The packages involved are Optim, OptimTests, LsqFit, and then hopefully also LineSearches (I thought it was in JuliaOpt actually) and NLsolve if @sebastien-villemot is in on it, and we can work out the licensing question I've raised in private (I prefer a MIT licensed stack, as I really want anyone to take full advantage of the code - even make money without me/us making a dime off of it).

So, this thread is mainly about finding an appropriate name and setup. I must say, that this will probably not be a completely democratic setting, as some people's voice weights more than others', but I'd still love some feedback.

As stated above, I think an org with BasePackage+Optim+LineSearch+NonLinearSolvePackage would be a great thing to have. I hope we can leverage NLsolve, but if we can't, then I'm sure we can quickly use the infrastructure in Optim to get something working for us. My suggested name would be JuliaSolvers. I know this is quite generic, but I do hope that this new org can be the home of a Optimization+Rootfinding combination that shares as much code as possible and also shares API to the extent possible. At least the name is no more generic than JuliaPlots, JuliaStats, and so on.

Let me hear your opinions, and I guess we'll reach a decision quite fast.

@KristofferC @sebastien-villemot @anriseth @cortner @timholy @blakejohnson @mlubin + all the people I forgot

[Evizero]

All your points make sense to me

I prefer a MIT licensed stack, as I really want anyone to take full advantage of the code

I share that hope

[cortner]

JuliaSolvers : that doesn't seem descriptive enough? JuliaOpt would be the canonical name for this I think, too bad it cannot be used?

[cortner]

Maybe worthwhile including JuliaSmoothOptimizers? Maybe even migrate to that specific domain?

[timholy]

"Solver" seems to imply a focus on solving equations, whereas in my world optimization is more often about finding extrema. JuliaOptimization is available, although seems a bit like name-piracy with respect to JuliaOpt. JuliaNativeOptimization?

[pkofod]

Maybe worthwhile including JuliaSmoothOptimizers? Maybe even migrate to that specific domain?

I think they have a quite clear idea about what they're doing/want to do with that org, and I'm not sure it's exactly what we are doing - even if we share a lot of "interests".

[pkofod]

"Solver" seems to imply a focus on solving equations, whereas in my world optimization is more often about finding extrema. JuliaOptimization is available, although seems a bit like name-piracy with respect to JuliaOpt. JuliaNativeOptimization?

I think that it's quite normal to refer to a specific implementation of a given algorithm/idea as a solver, even if it's optimization and not equations solving, but it's fine to do something else.

I don't think our friends in JuliaOpt would really appreciate JuliaOptimization.

[cortner]

JuliaNonlinearSolvers

[Evizero]

JuliaNLOptim, JuliaNLSolvers, JuliaNativeOptim

[cortner]

I think I like JuliaNLSolvers

[anriseth]

Solver for optimization/programming software seems to be legitimate. +1 for JuliaNLSolvers.

And yes, let's put LineSearches in there as well.

[pkofod]

JuliaNLSolvers is fine by me. It's kind of goofy, but not too important to me either. I actually kinda like it now.

[abelsiqueira]

@dpo

[dpo]

Maybe worthwhile including JuliaSmoothOptimizers? Maybe even migrate to that specific domain?

I think they have a quite clear idea about what they're doing/want to do with that org, and I'm not sure it's exactly what we are doing - even if we share a lot of "interests".

What is it you want to do? (And out of curiosity, why the breakup?)

[pkofod]

What is it you want to do? (And out of curiosity, why the breakup?)

The breakup is probably better explained here: https://github.com/EconForge/NLsolve.jl/issues/85 , but in a nutshell JuliaOpt is going to be the JuMP<- MathPRogBase -> Backends organisation. Basically, it will give them a tidier work flow. The subset of people who are developing Optim+family and the subset of people who develop the MathProgBase-stack are very much disjoint, so it makes sense to be so on a more organizational level as well.

So what do we (JuliaNLSolvers?) want to be? To me the most important thing is to keep the Optim-like interface alive and strong. Tried and true solvers that may not be the most performant on any given problem, but have proven to be quite good all-round solvers. I think we have that to some extent now, but we still have some things to do still. I hope to include the equation solving capabilities in NLsolve such that Optim and NLsolve are officially siblings, sharing the same gene pool (an NLSolverBase.jl, LineSearches.jl, NLSolverTests.jl and so on). To me it would be awesome if they were the "goto" packages for everyday optimization and equations solving.

Now, I may be wrong, but it seems to me that JuliaSmoothOptimizers have a slightly different aim. Not that you don't want to be used, but you propose a different API. It also seems like you want to experiment with solver development on more "frontier/experimental"-like solvers. I may be wrong. However, I don't think it would be wrong to say that we are proposing somewhat different APIs.

[abelsiqueira]

Now, I may be wrong, but it seems to me that JuliaSmoothOptimizers have a slightly different aim. Not that you don't want to be used, but you propose a different API. It also seems like you want to experiment with solver development on more "frontier/experimental"-like solvers. I may be wrong. However, I don't think it would be wrong to say that we are proposing somewhat different APIs.

What we have now is an API to create problems. Nothing released on solvers yet.

My main objective inside the organization was to make CUTEst.jl work. In that path, we ended up creating NLPModels.jl too, extending the API. These packages were made thinking that it should be easier to create new solvers, i.e., developers/researches could improve their workflow using these packages. See this tutorial for an example where I create a Newton solver.

Now that the stable versions are released, we are back developing Optimize.jl, which is solver related stuff. It includes, or will include, some general things, like line searching, trust-region, benchmarking-made-easy, unified solver statistics, etc. This also looks at improving the workflow for researchers. We do intend to create some solvers here, hopefully performant and robust. However, there is nothing stopping someone from creating book description algorithms using these tools. In fact, I might gonna put some students on that this year.

On the other hand, we don't have the API to connect models and solvers for users who don't care what solver is being used. And although I think it's very important to have that, it is not in the near future to implement it due to time restrictions. Also, we don't have solvers for non-smooth problems.

Regardless, Optim could choose to look at NLPModels for user input, it could be more in line with https://github.com/JuliaOpt/Optim.jl/issues/309.

Mildly related, I'm experimenting extending NLPModels to Nonlinear Least Squares: https://github.com/abelsiqueira/NLSModels.jl.

[pkofod]

All right, so I guess we're seen some suggestions. JuliaNLSolvers seems to have some traction with some of the more active people here. @johnmyleswhite suggested JuliaOptim at discourse, and I could go with that, but I think JuliaOpt might thing it's too close? ( @mlubin @IainNZ @joehuchette ) Then there's JuliaOptimization which is very similar, but a bit further away from JuliaOpt. And then there are the versions with Native in them.

Personally, these are the ones I prefer of the bunch (in no order): JuliaNLSolvers, JuliaOptim, JuliaOptimization.

[mlubin]

The precedent here is that we had a discussion with @abelsiqueira and @dpo about their organization which was previously named "JuliaOptimizers". We objected to having "JuliaOpt" as a substring of the name, so they kindly renamed it to "JuliaSmoothOptimizers". I don't know if our objection is still tenable post-reorganization.

Either way, I'd ask if we as a community would like to have three GitHub organizations named "JuliaOpt", "JuliaOptim", and "JuliaOptimizers" all with quite different focuses.

[johnmyleswhite]

Let's just pick some name at random. I'd even tolerate using the Julia hash 0x3576fb94315fe94d of the string "JuliaOpt" to get us out of deadlock. My belief is that no one who's using Optim.jl is going to be worried about the account that its repo lives under -- except insofar as their Git links break. And, IIUC, that's going to happen no matter what new name we use.

[dpo]

I don't know if our objection is still tenable post-reorganization.

If it isn't, my preference would be to go back to JuliaOptimizers (with @mlubin's agreement) since my group has had organizations named optimizers and PythonOptimizers for quite a while, and because we'd like to develop solvers for certain nonsmooth problems.

Will JuliaOpt remain JuliaOpt or change?

For Optim, I could suggest JuliaSolve, JuliaOptimSolvers or the longer JuliaOptimizationSolvers. Since it's just an org name, length doesn't really matter.

[joehuchette]

What about using the name "Optim" for the organization? On Sun, Feb 12, 2017 at 10:28 PM John Myles White notifications@github.com wrote:

Let's just pick some name at random. I'd even tolerate using the Julia hash 0x3576fb94315fe94d of the string "JuliaOpt" to get us out of deadlock. My belief is that no one who's using Optim.jl is going to be worried about the account that its repo lives under -- except insofar as their Git links break. And, IIUC, that's going to happen no matter what new name we use.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JuliaOpt/Optim.jl/issues/358#issuecomment-279286509, or mute the thread https://github.com/notifications/unsubscribe-auth/ABTzUpIC6AMtWh0oG6T-Vl3U6AFUqCaBks5rb83LgaJpZM4L9PPJ .

[johnmyleswhite]

There's a user named Optim. Otherwise that would be fine. We could probably make OptimJL work as a name. Or we could just restore the repo to my user account where it lived before all of this.

[pkofod]

which was previously named "JuliaOptimizers". We objected to having "JuliaOpt" as a substring of the name, so they kindly renamed it to "JuliaSmoothOptimizers". I don't know if our objection is still tenable post-reorganization.

I think that still makes sense.

Bikeshedding complete, JuliaNLSolvers it is.

except insofar as their Git links break

you mean the github links? No, they still work https://github.com/JuliaOpt/Optim.jl

[pkofod]

@mlubin I don't have admin rights in LsqFit, so maybe you could help me move it ?

@anriseth You can transfer LineSearches to JuliaNLSolvers now

[anriseth]

@anriseth You can transfer LineSearches to JuliaNLSolvers now

Github tells me I don't have permission to do that (I guess I need to be a member of the org)

[mlubin]

@pkofod, you should now have admin permission to LsqFit. Let me know if that isn't sufficient.

[pkofod]

@pkofod, you should now have admin permission to LsqFit. Let me know if that isn't sufficient.

perfect, LsqFit has been moved. I believe all packages are moved now?

[tkelman]

You do need to change the url's in metadata.

Not that my opinion matters much here, but I don't hear unconstrained algorithms called "solvers" anywhere near as often as for constrained MILP/NLP backends.

[timholy]

Since the code in MathProgBase dispatches to pre-existing libraries, isn't the main focus of "JuliaOpt" less on the optimization per se and more about developing a simple (and beautiful) language for specifying the problems? Wouldn't it be better to have that organization choose something like OptimizationModeling and use JuliaOptimization for code that implements (in Julia) the optimization algorithms themselves? One could call it JuliaOptimizationModeling, but that's a little long, and the shorter version prepares for that fast-approaching day when there's little reason to do modeling in any language but Julia :wink:.

[pkofod]

@timholy I think your arguments make a lot of sense, but I guess @dpo and @abelsiqueira would have first pick since they were talked out of using JuliaOptimizers.

@tkelman does that mean that people can't install optim right now?

[blakejohnson]

@pkofod if you have not done it already, can you set up attobot for the repos in JuliaNLSolvers?

[tkelman]

They can, but it's relying on github redirects which are possible to break.

[pkofod]

@pkofod if you have not done it already, can you set up attobot for the repos in JuliaNLSolvers?

It's done

[pkofod]

They can, but it's relying on github redirects which are possible to break.

Okay, thank you.

[mlubin]

Since the code in MathProgBase dispatches to pre-existing libraries isn't the main focus of "JuliaOpt" less on the optimization per se and more about developing a simple (and beautiful) language for specifying the problems?

We already have pure-Julia mathematical optimization solvers like Pajarito which are built around MathProgBase, so I'm not sure that's still an accurate characterization. I'm also coming to dislike the logical abstraction between solving and modeling even though I'm responsible for perpetuating it (I'll leave that for a discussion somewhere else). For both of those reasons I wouldn't support renaming JuliaOpt to something modeling-centric.

On top of that, the feasible consensus to go through with this restructuring was to keep JuMP under the existing JuliaOpt GitHub organization. At this point I don't see JuliaOpt being renamed.

[ranjanan]

@pkofod It looks like the links to documentation break.