2nd order methods?

[GeoffNN]

Are second-order methods in the scope of the project?

[fabianp]

Sure

…

On Sat, May 9, 2020, 11:14 Geoffrey Negiar ***@***.***> wrote: Are second-order methods in the scope of the project? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#43>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACDZB6NVFY3D2R7U6JZMMTRQVXLLANCNFSM4M42Y7PQ> .

[fabianp]

But scipy.optimize already has some of these. Did you have any particular method in mind?

…

On Sat, May 9, 2020, 16:57 Fabian Pedregosa ***@***.***> wrote: Sure On Sat, May 9, 2020, 11:14 Geoffrey Negiar ***@***.***> wrote: > Are second-order methods in the scope of the project? > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#43>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AACDZB6NVFY3D2R7U6JZMMTRQVXLLANCNFSM4M42Y7PQ> > . >

[GeoffNN]

Right. I was thinking about other stochastic 2nd order methods. One question is: are we trying to have most state-of-the-art solvers implemented efficiently here, are we complementary to scipy.optimize ; in general, what are we aiming for?

[fabianp]

I would like a library that complements scipy.optimize, implementing methods that are not in that library without competing with it.

That said, I propose to meet after NeurIPS deadline and discuss the project vision, as well as specific goals.