-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix check_point for SPD #593
Conversation
LGTM, Manifolds.jl/src/groups/rotation_action.jl Lines 304 to 305 in 8ccd5d8
|
Codecov Report
@@ Coverage Diff @@
## master #593 +/- ##
==========================================
- Coverage 98.90% 98.90% -0.01%
==========================================
Files 98 98
Lines 9897 9896 -1
==========================================
- Hits 9789 9788 -1
Misses 108 108
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Sure, I will remove them. |
The CI seems to indicate that you probably have to adapt tolerances? |
I increased accuracy instead, I hope that's also fine 🙂 |
# symmetrizing for better accuracy | ||
copyto!(q, (q .+ q') ./ 2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is this increasing accuracy? How do you know the error in q
is "symmetric", and reduced by symmetrization? Also, I wonder if this is optimal with respect to memory consumption? Perhaps something like
temp = m * Y * p * Y * m
temp .= temp .+ p .+ X
copyto!(q, temp)
# or
# copyto!(q, Symmetric(temp))
# or
# copyto!(q, (temp .+ temp') ./ 2) # which first allocates the result and then copies it to `q`
# or, starting from Julia v1.10
# hermitianpart!(q, temp)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, it's more accurate than the previous implementation in the sense that the result is numerically closer to the manifold. I should've made a better comment there.
Maybe taking either the upper or lower part instead of average would be a better idea, I didn't check that. I didn't care much about memory consumption here because previous lines are already quite expensive.
A small bugfix.
eigvals
returns complex eigenvalues in the provided test case, which are not comparable to 0. This, also, should be faster.