You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
isclose(a, b, *, rel_tol=1e-09, abs_tol=0.0)
Determine whether two floating point numbers are close in value.
rel_tol
maximum difference for being considered "close", relative to the
magnitude of the input values
abs_tol
maximum difference for being considered "close", regardless of the
magnitude of the input values
Return True if a is close in value to b, and False otherwise.
For the values to be considered close, the difference between them
must be smaller than at least one of the tolerances.
-inf, inf and NaN behave similarly to the IEEE 754 Standard. That
is, NaN is not close to anything, even itself. inf and -inf are
only close to themselves.
numpy.isclose provides its own version, which includes the following implementions:
import numpy as np
from uncertainties import unumpy as unp
from uncertainties.unumpy import uarray
xx = uarray([1, 2], [3, 4])
np.isclose(xx[0], xx[1]) # TypeError: ufunc 'isfinite' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''
unp.isclose(xx[0], xx[1]) # AttributeError: module 'uncertainties.unumpy' has no attribute 'isclose'
It's kinda wild to think so, but uncertainties needs to override this (to pass some pint_pandas tests). Looking around I see the uarray/unfunc code avoiding array dispatch as a concept (wrapping things instead). Should it continue to avoid, or take the plunge, or?
The text was updated successfully, but these errors were encountered:
Honestly, updating the interface to a more modern (and widely available) NumPy/Pandas mechanisms for handling arrays of objects of a different type is something that has been in my mind for a while, so this would be great.
I haven't looked closely enough to know whether unumpy could almost disappear altogether, but if it does (or almost does), this would offer some nice transparency to users.
PS: if you can use PEP 8 for any code submitted to this repository, that'd be useful (because it the end all code here will be PEP 8). I'm saying this because inline comments should have two spaces before # (so as to visually separate code from comment). Thanks!
PPS: also, including links to the relevant documentation (such as the NumPy/Pandas array interface) in the code would allow me to check that the implementation is the most robust one. :)
math.isclose
provides this:numpy.isclose
provides its own version, which includes the following implementions:Code to demonstrate problem:
It's kinda wild to think so, but uncertainties needs to override this (to pass some pint_pandas tests). Looking around I see the uarray/unfunc code avoiding array dispatch as a concept (wrapping things instead). Should it continue to avoid, or take the plunge, or?
The text was updated successfully, but these errors were encountered: