-
Notifications
You must be signed in to change notification settings - Fork 6
implement allclose or something similar #871
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
Comments
This is a follow-up to #488. |
I know... but it is still annoying. We might want to diverge from numpy on this one, like we did for aggregates. |
alixdamman
added a commit
to alixdamman/larray
that referenced
this issue
Aug 26, 2020
alixdamman
added a commit
to alixdamman/larray
that referenced
this issue
Aug 26, 2020
OK. |
alixdamman
added a commit
to alixdamman/larray
that referenced
this issue
Aug 26, 2020
alixdamman
added a commit
to alixdamman/larray
that referenced
this issue
Mar 1, 2021
alixdamman
added a commit
to alixdamman/larray
that referenced
this issue
Mar 1, 2021
gdementen
pushed a commit
to gdementen/larray
that referenced
this issue
Nov 30, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It is simply annoying to have to type:
PS: I am thorn about whether nans_equals should default to True or False in that case. On one hand, in 99.9% cases, I want nans_equal=True, so it would be nice to have a method with such a default to avoid having to type it each time (or worse... usually forgetting to type it then notice my result is False... investigate why... and only notice that it was because it had nans and I forgot to specify the arg). On the other hand having a different default than in equals could be confusing and having it default to True could lead, in some very rare case, to nan results being unnoticed, i.e. a silent error, which is what a library (and larray even more so) should strive to avoid.
The text was updated successfully, but these errors were encountered: