Investigate use with numpy-quaddtype

[ngoldbaum]

Hi!

I'm one of the NumPy maintainers. I'm also an engineer @Quansight-Labs. Last year as part of our internship program @SwayamInSync implemented a new 128 bit floating point data type for NumPy. See his blog post for more detail. You can also see the code here.

Our plan with the quaddtype is to provide a way for users of numpy.longdouble to have access to both a fast hardware 80 bit float as well as a float128 implementation provided by the SLEEF library. You can choose which "backend" you want to use at runtime.

We still have a bit more work to do to improve the packaging of numpy-quaddtype, but I'm also curious if what we have now is generally useful for pulsar timing work.

[dlakaplan]

Thank you for your comments. We have been struggling with this issue for a while (see #1170). I did see the work you and @SwayamInSync did, and was very interested in it, but when I looked at the page I admit I was scared off by "These dtypes are not meant for real-world use yet." I did check back occasionally but didn't see any dramatic changes. But if you think it's ready for testing I will do that.

[dlakaplan]

OK, I just started to test this but couldn't even get the suggested commands at https://github.com/numpy/numpy-user-dtypes/tree/main/quaddtype to run, or the packaged tests. I assume I must be doing something wrong since it seems there are others who have used this correctly. I can file an issue over on https://github.com/numpy/numpy-user-dtypes/tree/main/quaddtype if that's preferred, or if you have any suggestions here I would be grateful.

On a M2 Mac with x64 conda:

• created new environment with python=3.12
• installed numpy, as well as astropy and a few others through conda
• pip install numpy-quaddtype
• Then:

In [1]: from numpy_quaddtype import QuadPrecDType, QuadPrecision
---------------------------------------------------------------------------
ModuleNotFoundError                       Traceback (most recent call last)
Cell In[1], line 1
----> 1 from numpy_quaddtype import QuadPrecDType, QuadPrecision

File ~/pythonpackages/numpy-user-dtypes/quaddtype/numpy_quaddtype/__init__.py:1
----> 1 from ._quaddtype_main import (
      2     QuadPrecision,
      3     QuadPrecDType,
      4     is_longdouble_128,
      5     get_sleef_constant,
      6     set_num_threads,
      7     get_num_threads,
      8     get_quadblas_version
      9 )
     11 __all__ = [
     12     'QuadPrecision', 'QuadPrecDType', 'SleefQuadPrecision', 'LongDoubleQuadPrecision',
     13     'SleefQuadPrecDType', 'LongDoubleQuadPrecDType', 'is_longdouble_128', 
   (...)     18     'set_num_threads', 'get_num_threads', 'get_quadblas_version'
     19 ]
     21 def SleefQuadPrecision(value):

ModuleNotFoundError: No module named 'numpy_quaddtype._quaddtype_main'

Or if I run the tests in the GitHub package, I get 779 failures (don't want to list them all). Is there something wrong with this installation procedure?

[SwayamInSync]

Hey @dlakaplan
You can follow the steps present here https://github.com/numpy/numpy-user-dtypes/tree/main/quaddtype#installation-from-source and please install from the source, pip version is pretty old (we will update it with the upcomong v1.0 release)

The incorrect in above step it seems from the output is that you installed the very older version from pip but since within the folder the python is searching APIs from the current project source

Looking at the issue you mentioned, it seems we have pretty much to be work as the alternative for xprec/ld mentioned in issue.
Let me know I can help in building a patch with numpy-quaddtype to test for that issue.

[dlakaplan]

Thanks for the response. I am attempting to install from source but it's not entirely straightforward. So far I can get sleef installed but still having trouble with quaddtype itself.

For our user base having a package installation (pip and/or conda) is important, but it sounds like that's in your plans. Will that package include sleef as well?

[SwayamInSync]

Will that package include sleef as well?

Yes even the version uploaded currently of PyPI comes with included sleef. So we will be continuing with this it's just current source code has multiple better APIs and support so that's why I am recommending it.

[ngoldbaum]

For our user base having a package installation (pip and/or conda) is important, but it sounds like that's in your plans.

There's a package on conda-forge too: https://anaconda.org/conda-forge/numpy_quaddtype

[ngoldbaum]

@SwayamInSync did a bunch of work the last couple weeks to simplify the packaging situation. Maybe you can try again?

[dlakaplan]

Indeed, I could install it easily and run the sample code. Thanks! It will take longer to see how well this works for us. I tried to just look at the reported finfo but it seems like that's not available, and that you were aware of this (numpy/numpy#27231). So we may need to adjust our tests, but that should be doable.

Any suggestions for how to quickly test for the available precision without finfo? We had a number of tests that used finfo.eps.

[SwayamInSync]

any suggestions for how to quickly test for the available precision without finfo? We had a number of tests that used finfo.eps.

We internally package this within the numpy_quaddtype, it should be as simple as

In [1]: import numpy_quaddtype as npq

In [2]: npq.precision
Out[2]: 33

In [3]: npq.epsilon
Out[3]: QuadPrecision('1.925929944387235853055977942584927e-034', backend='sleef')

[ngoldbaum]

We're aware that np.finfo doesn't know about user dtypes, it's on our list of things to work on...

[dlakaplan]

OK, I finally got around to installing this on a machine under the arm platform. I used a fresh conda install and a fresh environment, with numpy-quaddtype installed through pip. But when I try some of the basic tests I get:

>>> import numpy_quaddtype as npq
OMP: Error #15: Initializing libomp.dylib, but found libomp.dylib already initialized.
OMP: Hint This means that multiple copies of the OpenMP runtime have been linked into the program. That is dangerous, since it can degrade performance or cause incorrect results. The best thing to do is to ensure that only a single OpenMP runtime is linked into the process, e.g. by avoiding static linking of the OpenMP runtime in any library. As an unsafe, unsupported, undocumented workaround you can set the environment variable KMP_DUPLICATE_LIB_OK=TRUE to allow the program to continue to execute, but that may cause crashes or silently produce incorrect results. For more information, please see http://openmp.llvm.org/

I don't know if this is something specific to the machine or to how numpy-quaddtype was packaged. Any ideas?

[ngoldbaum]

I've never seem this before but IMO getting an error like this on import after installing a wheel is bu definition a bug in the quaddtype packaging. Would you mind filing an issue on the numpy-user-dtypes repo about this? It would also help to get information about your system and how you set up your Python environment so we can reproduce the issue.

[dlakaplan]

OK, thanks. numpy/numpy-user-dtypes#168

[dlakaplan]

OK, moving on now. One possible way to implement this is to monkey-patch np.longdouble to QuadPrecDType(backend="sleef"). But having a callable function of the dtype would help with that. Is that something that's in the works? I don't know the tradeoffs.

[ngoldbaum]

Long-term, we probably would need to write a NEP to add the dtype to numpy itself. Out of curiosity, why is monkeypatching numpy needed on your end? Is there a lot of code that uses string type codes or something like that?