Implement isfinite, isinf, isnan ufuncs

[juntyr]

Fixes #111

[juntyr]

I get some weird runtime warnings in the isfinite and isinf ufuncs:

tests/test_quaddtype.py: 10 warnings
  /workspaces/numpy-user-dtypes/quaddtype/tests/test_quaddtype.py:113: RuntimeWarning: invalid value encountered in isfinite
    quad_result = op_func(quad_val)

tests/test_quaddtype.py: 10 warnings
  /workspaces/numpy-user-dtypes/quaddtype/tests/test_quaddtype.py:113: RuntimeWarning: invalid value encountered in isinf
    quad_result = op_func(quad_val)

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html

Any idea what I'm doing wrong?

[seberg]

IEEE says comparisons with NaNs trigger FPEs (floating point error; FPEs are a flag set on the CPU when one occurs basically). That means normally also nan == inf.
C99 has special comparison functions for this purpose (not that all compilers used to get it right). Maybe sleef gets these warnings right, maybe not. But the best solution would be to avoid the function triggering it. Maybe sleef has a quiet comparison or just a way to test for this without a comparison.

[juntyr]

IEEE says comparisons with NaNs trigger FPEs (floating point error; FPEs are a flag set on the CPU when one occurs basically). That means normally also nan == inf. C99 has special comparison functions for this purpose (not that all compilers used to get it right). Maybe sleef gets these warnings right, maybe not. But the best solution would be to avoid the function triggering it. Maybe sleef has a quiet comparison or just a way to test for this without a comparison.

This definitely got me on the right track but wasn't the issue in the end. In fact, Sleef_cast_from_doubleq1(std::numeric_limits<double>::infinity()) raised the flag (no idea why), so I switched to using constants defined with sleef_q (the recommended way).

[seberg]

Seems plausible that the sleef casts uses the wrong type of comparisons internally and nobody noticed/cares (or the compilers mess it up later).

@juntyr one thing I forgot is, that we should definitely add -ftrapping-math (compare NumPy meson.build for Clang builds. The default is just terrible for NumPy here since it honors FPEs (NumPy does, clang doesn't). If you were using Clang, it may well be that just setting this flag fixes the issue. (We should set it either way.)

[juntyr]

@SwayamInSync I've rebased this PR and it should now also be good to go

[SwayamInSync]

Thanks @juntyr this looks good, just a small suggestion here.

[SwayamInSync]

It seems QUAD_ZERO and QUAD_ONE aren't used so you can remove them, also
sleef_q internally handles the biased exponent addition which managed to convert this to IEEE validated infinity representation but I am kind of biased here to keep this hardcoded as it can be easily defined as Sleef_cast_from_doubleq1(1.0 / 0.0) (Dividing a non-zero finite number by zero)

[juntyr]

Whoops, my rebase was messed up then as I originally used the constants

[juntyr]

I originally tried the above but converting from infinity double caused numpy warning to appear, which I was only able to remove with the constants