Need override of NumPy's _isclose_dispatcher (or something)

[MichaelTiemannOSC]

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]

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]

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