Skip to content
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

Need override of NumPy's _isclose_dispatcher (or something) #163

Open
MichaelTiemannOSC opened this issue Oct 18, 2022 · 2 comments
Open

Comments

@MichaelTiemannOSC
Copy link

math.isclose provides this:

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:

def _isclose_dispatcher(a, b, rtol=None, atol=None, equal_nan=None):
    return (a, b)


@array_function_dispatch(_isclose_dispatcher)
def isclose(a, b, rtol=1.e-5, atol=1.e-8, equal_nan=False):
[...]

Code to demonstrate problem:

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?

@lebigot
Copy link
Collaborator

lebigot commented Oct 19, 2022

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. :)

@lebigot
Copy link
Collaborator

lebigot commented Oct 19, 2022

PPPS: and yes, using math.isclose internally is now appropriate (since it was introduced back in 2015).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants