QuadDtype Wishlist

[juntyr]

This is my personal list of patches around numpy-quaddtype that I currently have in my own project that I'd like to fix upstream - I will work on most of them myself and will reach out if I need help with some:

Constants

• expose precision: could just be hardcoded to 33, the precision of np.float128 on a platform with native float128 support Add bits, precision, resolution constants #132

Ufuncs

• sign ufunc: implemented in Implement copysign, sign, and signbit ufuncs #122
• sinh, cosh, tanh, asinh, acosh, atanh ufuncs: implemented in Implement hyperbolic ufuncs #128
• fix mod ufunc: fixed in Fixing mod's behaviour to numpy from IEEE #125
• isnan, isinf, isfinite ufuncs: implemented in Implement isfinite, isinf, isnan ufuncs #121
• nextafter and spacing ufuncs: implemented in FEAT: nextafter ufunc implementation #190 and FEAT: spacing ufunc implementation #191

Dtype

• support np.issubdtype(dtype, np.floating): implemented in QuadDtype finfo support & Nightly CI #165
• finfo support: implemented in QuadDtype finfo support & Nightly CI #165
• nan_to_num ufunc: depends on finfo support
• custom dtype kind character, not '\0', tracked in SleefQuadPrecDType kind, char, num #110, not yet possible

Binary

• cast to an equal-sized unsigned integer type

[ngoldbaum]

It'd also be nice to have proper API docs for the Python API generated by e.g. Sphinx. We should also make sure there are docstrings (preferably doctested in CI) on the full public Python API.

[juntyr]

Once we get to writing documentation, we should also document the guaranteed rounding error in ULPs for each operation - thankfully SLEEF documents it fully - since people who need float128, myself included, then likely also care about rounding errors

[juntyr]

@ngoldbaum @SwayamInSync Would it be possible to implement np.issubdtype(dtype, np.floating) support by making QuadPrecision a subclass of np.floating? While something like finfo would still be blocked on other issues, it would still be an improvement

[SwayamInSync]

It is possible and we did that back when it is in early development, and it leads to some issues like np.finfo got populated with the float64 properties, which later leads to some precision issues in tests

[ngoldbaum]

I encourage you both to not think of NumPy as a static thing that can't be changed or fixed. We should definitely make finfo play nicer with user dtypes, it'll just take some work inside NumPy to get that going. Happy to mentor on contributing to NumPy.

[SwayamInSync]

it'll just take some work inside NumPy to get that going. Happy to mentor on contributing to NumPy.

Yes after fixing the packaging and setting things up on conda-forge, I'll be studying the DType API more on extending to these ideas. AFAIK JAX team also got these issues and they are using monkey patching for this. We can do that too but it'll be ugly

[juntyr]

@SwayamInSync Could we add a test for np.nan_to_num now working (since you added finfo support)?

[juntyr]

@SwayamInSync Is it still true that the dtype character will be '\0'?

[SwayamInSync]

@SwayamInSync Could we add a test for np.nan_to_num now working (since you added finfo support)?

It works but array printing is having some issues, the operation itself works. I'll keep this in mind and debug

[SwayamInSync]

@SwayamInSync Is it still true that the dtype character will be '\0'?

the kind is '\x00'

[SwayamInSync]

@SwayamInSync Could we add a test for np.nan_to_num now working (since you added finfo support)?

It works but array printing is having some issues, the operation itself works. I'll keep this in mind and debug

It'll work but in the environment following this has to be set

np.set_printoptions(formatter={'float_kind': lambda x: str(x)})

Otherwise the operation will properly work, its just you can't be able to print it