Conversation
frank wolfe with simplex constraints solver
…ystem Split the monolithic _pyensmallen.cpp file into modular components: - utils.hpp: Common utilities and wrapper classes - newton_type.hpp: L-BFGS implementation - constrained.hpp: Frank-Wolfe algorithm for constrained optimization - first_order.hpp: Adam and its variants Also updated the build system to use setuptools instead of meson for better compatibility.
Created benchmark_performance.py which: - Generalizes the likelihood_comparison notebook into a reusable script - Tests performance across different dataset sizes (n,k) - Compares pyensmallen against other popular optimization libraries - Generates visualizations and summary tables - Includes command-line options for customization This will help demonstrate pyensmallen's performance advantages.
Refactor C++ code into modular files and switch to setuptools build system. Add detailed benchmarks.
gmm implementation with autodiff-ed gradients and bootstrap
add short benchmark paper
|
Hi @apoorvalal, thanks again for making these great optimizers accessible in Python. @gauravmanmode is currently working on wrapping your package in optimagic and this PR would be really helpful to do so. Can you let us know if you are open to go into this direction? |
|
Hi, sorry I've fallen behind on this; excited to see progress and def happy to move forward with it. I'll have more bandwidth soon and will try to get this over the line. |
|
No worries. Thanks for the quick reply! |
|
Thanks, @apoorvalal , if you can review this PR and tell me if this is in the right direction? |
|
Specifically, you want to log both the criterion function value and coordinates to be able to make this figure |
|
Hi @apoorvalal, we collect the data for the figure you linked for every optimizer by modifying the user's objective function. So there is no need to support this in the low-level optimizer libraries. If you are interested in how it works you could look for example here in our `InternalOptimizationProblem. What we mainly need from pyensmallen is the function value evaluated at the optimal parameters (without doing an additional evaluation ourselves). |
There was a problem hiding this comment.
Pull Request Overview
This PR introduces a new callback class to allow passing extra report information via a Python dictionary and updates the L-BFGS optimizer binding to accept an optional report parameter.
- Added inclusion of "report.hpp" and Python binding for the new Report class.
- Modified the optimize method for L-BFGS to incorporate a report callback with a default null value.
Comments suppressed due to low confidence (2)
pyensmallen/module.cpp:44
- Ensure that adding the optional 'report' parameter to the optimize method matches the intended use cases and that the implementation correctly handles a nullptr value for report.
.def("optimize", &PyL_BFGS::Optimize,
pyensmallen/module.cpp:254
- [nitpick] Verify that exposing the C++ class 'PyReport' as 'Report' is intentional and clearly documented to avoid confusion among users regarding the class's origin.
py::class_<ens::PyReport>(m, "Report")
|
Hi @apoorvalal, we would like to complete the pyensmallen wrappers in optimagic during this year's google summer of code. The coding period will end in about 6 weeks. Do you think we could get this PR merged on time? |
|
Hi @apoorvalal, |
3 participants
I have created a copy of the Report class with following signature
PyReport( py::dict resultIn,
bool disableOutput = false,
const double iterationsPercentageIn = 0.1,
const size_t outputMatrixSizeIn = 4) :
this way we can store some extra info by passing a dict, and trigge output with disableOutput = false.
Also, I have made passing a PyReport class optional.
am i heading in the right direction?