Loosen strictness on hermitian checks #78
Conversation
|
This is currently failing for GPU arrays. How should we proceed for not. @kshyatt , what is the best way to proceed? Simply comment out the hermiticity check from the GPU |
|
Can you add a simple test to see if the error calculation is now correct. Something like: A = randn(T, (m, m))
A = A + A' + sqrt(eps(real(T))) * randn(T, (m, m))
ϵ = norm(A - A')
@test !ishermitian(A; atol = (999//1000) * ϵ)
@test ishermitian(A; atol = (1001//1000) * ϵ) |
lkdvos
force-pushed
the
ld-hermitian
branch
2 times, most recently
from
61dab5a to
872c7b9
Compare
| return strided_ishermitian_exact(A, Val(true); kwargs...) | ||
| end | ||
| function isantihermitian_approx(A; atol, rtol, kwargs...) | ||
| return norm(project_hermitian(A; kwargs...)) ≤ max(atol, rtol * norm(A)) |
There was a problem hiding this comment.
Do we want to use the norm provided in kwargs here? Or do we not want to support this option (would be fine with me, I am very happy with the standard Frobenius norm).
There was a problem hiding this comment.
Also above for ishermitian_approx.
There was a problem hiding this comment.
I don't think I want to support that option for now, because I don't think I really want to deal with the strided_ishermitian_approx implementation that would be required for that.
|
Thanks @kshyatt for the GPU additions, I think this PR is now passing everything. I'll let the tests finish, and then I think this is good to go, there shouldn't be any interference with the tests that got added to |
Codecov Report❌ Patch coverage is
🚀 New features to boost your workflow:
|
* Bump v0.6 * rename `gaugefix` -> `fixgauge` * reduce unnecessary warnings * fix `copy_input` signatures in Mooncake tests * Add changelog to docs
This PR addresses #76:
ishermitianchecks from the YALAPACK implementations. Since these already take an argumentuplo, and are pretty low-level, I feel like these should not check for hermitian properties, as you may want to provide an upper or lower triangular array instead.hermitian_tolargument to the algorithm structs to control the precision with which the input is verified.The main issue is that the previous implementation of the approximate hermitian check actually has to allocate a new array, so I adapted this to no longer require the temporary array. However, I don't think I can do this for arbitrary
normfunction handles. Currently, I just removed this feature. I think in general we could have differentp-norms, but I'd say we just add that option if we ever need it?