openopt
2nd order methods?
Sure
On Sat, May 9, 2020, 11:14 Geoffrey Negiar [email protected] 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 https://github.com/openopt/copt/issues/43, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACDZB6NVFY3D2R7U6JZMMTRQVXLLANCNFSM4M42Y7PQ .
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 [email protected] wrote:
Sure
On Sat, May 9, 2020, 11:14 Geoffrey Negiar [email protected] 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 https://github.com/openopt/copt/issues/43, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACDZB6NVFY3D2R7U6JZMMTRQVXLLANCNFSM4M42Y7PQ .
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?
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.