Skip to content

Add point capability to _produce_type to improve GPU compatibility#577

Draft
mateuszbaran wants to merge 7 commits intomasterfrom
mbaran/produce_type_point
Draft

Add point capability to _produce_type to improve GPU compatibility#577
mateuszbaran wants to merge 7 commits intomasterfrom
mbaran/produce_type_point

Conversation

@mateuszbaran
Copy link
Member

This is a draft of the enhancement discussed in #574 .

cc @zazabap

@mateuszbaran mateuszbaran added enhancement WIP Work in Progress (for a pull request) labels Feb 12, 2026
@mateuszbaran
Copy link
Member Author

Does this test:

s = GradientDescentState(Euclidean(); p = 1.0)
intentionally verify that the solver works with an immutable p? I can make it work, though it would make the code a bit uglier.

@kellertuer
Copy link
Member

intentionally verify that the solver works with an immutable p?

Yes, that test is intentionally, since Euclidean(1) would be vectors of length 1, but Euclidean() is our convention for reals/immutable. Internally we could Ref that – think we even do that already.

Comment on lines 669 to 671
function MomentumGradientRule(M::AbstractManifold, p; kwargs...)
return MomentumGradientRule(M; p = allocate(p), kwargs...)
end
Copy link
Member

Choose a reason for hiding this comment

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

I think this is now a bit inconsistent. For the DistanceOverGradient you did a breaking change and moved the p from a keyword to a positional. Here you did not do that, but introduce a new constructor with p that moves that to a keyword.

I think until now, if needed, the p was a keyword (with rand(M) as default which has the same problem with a point type by the way). To be nonbreaking, maybe keeping that would be nice?

Copy link
Member Author

Choose a reason for hiding this comment

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

I understood the docs of DistanceOverGradient where they claim that p is the "initial point, used to track distance" as "p is the starting point of optimization". Is this just supposed to be an arbitrary point? If so, maybe it would be good to clarify it in the docstring. That's why I thought it's a bugfix rather than a breaking change.

Copy link
Member

@kellertuer kellertuer left a comment

Choose a reason for hiding this comment

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

A small comment

@mateuszbaran
Copy link
Member Author

Yes, that test is intentionally, since Euclidean(1) would be vectors of length 1, but Euclidean() is our convention for reals/immutable. Internally we could Ref that – think we even do that already.

OK, then I think a new method in ManifoldsBase would be the cleanest solution.

@codecov
Copy link

codecov bot commented Feb 13, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (88c7db6) to head (19c3287).

Additional details and impacted files
@@            Coverage Diff            @@
##            master      #577   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           91        91           
  Lines         9975     10013   +38     
=========================================
+ Hits          9975     10013   +38     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

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

@mateuszbaran mateuszbaran added Ready-for-Review A label for pull requests that are feature-ready and removed WIP Work in Progress (for a pull request) labels Feb 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement Ready-for-Review A label for pull requests that are feature-ready

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants