Skip to content

Conversation

@demroz
Copy link
Contributor

@demroz demroz commented Oct 17, 2025

adds a few gradient optimizers

  • gradient descent
  • nesterov
  • and L-BFGS

everything is policy based, so these should be quite extensible. I may add a few more optimziers in the future, but these are the main ones i think. If there are any specific ones that you guys think should be added, I'd be happy to do so. Also although everything is reverse-mode autodiff centric, as long as you provide the objective function, a way to evaluate it, and a way to evaluate the gradient, everything should work correctly.

For some examples on how to use the optimziers: test_gradient_descent_optimizer.cpp, test_nesterov_optimizer.cpp, and test_lbfgs.cpp should be good starting points.

I'm working on the documentation currently. I wanted to hold off to see if any major revisions are necessary

@codecov
Copy link

codecov bot commented Oct 17, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.32%. Comparing base (2697069) to head (2a63c30).
⚠️ Report is 82 commits behind head on develop.

Additional details and impacted files

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #1328      +/-   ##
===========================================
+ Coverage    95.24%   95.32%   +0.07%     
===========================================
  Files          814      825      +11     
  Lines        69309    67994    -1315     
===========================================
- Hits         66015    64812    -1203     
+ Misses        3294     3182     -112     

see 509 files with indirect coverage changes


Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2697069...2a63c30. Read the comment docs.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@demroz
Copy link
Contributor Author

demroz commented Jan 29, 2026

At this point the code is something I'm relatively happy with. I also updated the docs. Would be great if this could get reviewed cc: @mborland @NAThompson

@mborland
Copy link
Member

@demroz in general this looks very good! Left some comments, and opinions that you can feel free to push back on. I pushed changes to CI and spelling rather than leaving those as TODOs for you.

Copy link
Contributor Author

@demroz demroz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mborland

I updated the PR according to your suggestions. A few points :

  1. I think adding support for C++17 execution policies should be done in a separate PR with dedicated benchmarks.
  2. using <random> instead of <boost/random.hpp>. I'm not sure what should be done here. I agree with your point that this breaks the ability of this being a standalone package. However, <random> doesn't support multiprecision types. We could static_cast to double for multiprecision types, and static_cast back to multiprecision but thats not behavior I would expect as a user. Practically, i doubt it makes much difference as this is just an initialization policy. Any thoughts?

@mborland
Copy link
Member

@mborland

I updated the PR according to your suggestions. A few points :

  1. I think adding support for C++17 execution policies should be done in a separate PR with dedicated benchmarks.
  2. using <random> instead of <boost/random.hpp>. I'm not sure what should be done here. I agree with your point that this breaks the ability of this being a standalone package. However, <random> doesn't support multiprecision types. We could static_cast to double for multiprecision types, and static_cast back to multiprecision but thats not behavior I would expect as a user. Practically, i doubt it makes much difference as this is just an initialization policy. Any thoughts?

I mentioned it above but I think generating a random double and then casting it to a multiprecision type should be fine. I would not expect the lost digits to create much of a difference.

@demroz
Copy link
Contributor Author

demroz commented Jan 31, 2026

@mborland

I updated the docs and removed the boost::random dependency. Let me know if anything else is needed from my end to merge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants