PyHmmer sets CPU float behaviour globally, potentially causing issues in other libraries

[jakobnissen]

When loading pyhmmer v0.10.12 together with NumPy v1.26.4, the following warning are printed to the screen:

/home/jakni/miniconda3/envs/vamb312/lib/python3.12/site-packages/numpy/core/getlimits.py:549: UserWarning: The value of the smallest subnormal for <class 'numpy.float64'> type is zero.
  setattr(self, word, getattr(machar, word).flat[0])
/home/jakni/miniconda3/envs/vamb312/lib/python3.12/site-packages/numpy/core/getlimits.py:89: UserWarning: The value of the smallest subnormal for <class 'numpy.float64'> type is zero.
  return self._float_to_str(self.smallest_subnormal)
/home/jakni/miniconda3/envs/vamb312/lib/python3.12/site-packages/numpy/core/getlimits.py:549: UserWarning: The value of the smallest subnormal for <class 'numpy.float32'> type is zero.
  setattr(self, word, getattr(machar, word).flat[0])
/home/jakni/miniconda3/envs/vamb312/lib/python3.12/site-packages/numpy/core/getlimits.py:89: UserWarning: The value of the smallest subnormal for <class 'numpy.float32'> type is zero.
  return self._float_to_str(self.smallest_subnormal)

From a bit of googling, this is what I found out:

• This happens when NumPy is loaded when the FTZ and/or DAZ (not sure which of the flags it is) are set in the CPU.
• Whether this flag is on/off changes the behaviour of floating point operations. These flags are usually not safe to have enabled and can cause numerical instability in NumPy and many other libraries

It looks like C libraries compiled with either -Ofast or -ffast-math will cause the C library to set this flag when loaded.

Apart from the annoying warning, it is unsafe, and also completely unreasonable that loading one library will globally affect the CPU's behaviour for the whole process, including all other libraries.
I narrowed it down to pyhmmer 0.10.12.

This can be solved by compiling pyhmmer without these flags.

[althonos]

This is unfortunately a known problem (#38) with the CPython binaries distributed in the cibuildwheel containers, where some of them were indeed compiled with -ffast-math for some reason, and the flags were then getting into the default compilation flags reported by sysconfig and used by default in the setup.py script...