Noisy UserWarning is thrown (np.longdouble) when importing nibabel with numpy>=1.25 on WSL1

[joshuacwnewton]

Note

This seems to be a relatively narrow warning, since numpy<=1.24 doesn't throw this warning, nor does WSL2, nor does the native Windows package.

The warning thrown by numpy is:

numpy/core/getlimits.py:542:  
"""
UserWarning: Signature b'\x00\xd0\xcc\xcc\xcc\xcc\xcc\xcc\xfb\xbf\x00\x00\x00\x00\x00\x00' for 
<class 'numpy.longdouble'> does not match any known type: falling back to type probe function.
This warnings indicates broken support for the dtype!
  machar = _get_machar(dtype)
"""

When importing nibabel, the following stack trace occurs:

• import nibabel -> .analyze -> .arrayproxy -> .volumeutils -> .casting -> ok_floats()
• nibabel.casting.ok_floats() -> best_float() -> type_info(np.longdouble) -> np.finfo(np.longdouble) -> warning

Reading the source code of best_float(), I see that nibabel actively tries to avoid np.longdouble on Windows:

nibabel/nibabel/casting.py

Lines 667 to 670 in 0e925ab

	This is nearly always np.longdouble, except on Windows, where np.longdouble
	is Intel80 storage, but with float64 precision for calculations. In that
	case we return float64 on the basis it's the fastest and smallest at the
	highest precision.

Given nibabel's intentions here, it seems as though the warning is largely noise? So, I thought I would mention it here in case nibabel wishes to filter this warning.

Related issues:

• UserWarning of numpy.longdouble trigger when importing h5py with numpy>=1.25 h5py/h5py#2357
• BUG: WSL is missing full longdouble support (WSL, not NumPy probably) numpy/numpy#22187

[effigies]

Seems worth filtering. Any interest in proposing a patch?

[joshuacwnewton]

Sure thing! Feel free to assign me. :)