-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Inconsistent behavior in sparse matrices when interacting with NaNs #18091
Comments
Yes, this is wrong, our current sparse matrix implementation does not give proper IEEE754 results for operations on the implicit non-stored zeros. Should be fixable with a bit of care. related: #14973 |
Is there any programming language or library that does this properly for all operations? |
Oh, this again. There was also some discussion in #15579 revolving around handling Infs and NaNs in sparse algorithms. |
Cc @Sacha0 |
I'll repeat myself here too:
Calling this a feature instead of a bug runs counter to the purpose of sparse matrices as a representation optimization that shouldn't change visible behavior in a generic programming sense. |
@tkelman I think you and I should get matching shirts and wear them to the next JuliaCon: https://www.amazon.com/Arguing-Engineer-Like-Wrestling-shirt/dp/B01HJ85TTC Ok, if you are really intent on doing things this way, how about structuring the API in this way: function func_unchecked(args...)
# implement the algorithm, not performing any checks
end
function func_checked(args...)
# do checks here
func_unchecked(args...)
end and export both versions, and also link this up to the |
that seems fine, except that I don't think we should export the unchecked version |
Why not? It just unchecked, not unsafe. The functions that do arithmetic don't check for overflow, underflow etc. |
namespace pollution - we should probably be putting these things in an Unchecked module. |
Sounds reasonable. |
Closing in favor of https://github.com/JuliaLang/julia/issues/22733 |
I believe the latter behavior is the correct one
The text was updated successfully, but these errors were encountered: