On Mon, Feb 7, 2022 at 5:11 PM Victor Stinner <vstin...@python.org> wrote:
> I made a change to require C99 <math.h> "NAN" constant [...]
There's a separate discussion topic lurking here. It's equally in need of
discussion here (IMO), but it's orthogonal to the "should we require C99"
discussion. I've changed the subject line accordingly to try to avoid
derailing that discussion.
Unlike the other things Victor mentions ("copysign", "round", etc.), the
NAN macro is not required to be present by C99. Instead, the standard says
that "NAN is defined if and only if the implementation supports quiet NaNs
for the float type" (C99 ยง7.12p5).
Victor is proposing in GH-31160
<https://github.com/python/cpython/pull/31160> to require the presence of
the NAN macro in order for CPython to build, which under C99 is equivalent
to requiring that the C float type supports quiet NaNs. That's not the same
as requiring IEEE 754 floating-point, but it's not far off - there aren't
many non-IEEE 754 floating-point formats that support NaNs. (Historically,
there are essentially none, but it seems quite likely that there will be at
least some non-IEEE 754 formats in the future that support NaNs; Google's
bfloat16 format is one example.)
So there (at least) three questions here:
- Should we require the presence of NaNs in order for CPython to build?
- Should we require IEEE 754 floating-point for CPython-the-implementation?
- Should we require IEEE 754 floating-point for Python-the-language?
For the first two, I'd much prefer either to not require NaNs, or to go the
whole way and require IEEE 754 for CPython. Requiring NaNs but not IEEE 754
feels like an awkward halfway house: in practice, it would be just as
restrictive as requiring IEEE 754, but without the benefits of making that
requirement explicit (e.g., being able to get rid of non-IEEE 754 paths in
existing code, and being able to tell users that they can reasonably expect
IEEE 754-conformant behaviour).
Note that on the current main branch there's a Py_NO_NAN macro that
builders can define to indicate that NaNs aren't supported, but the Python
build is currently broken if Py_NO_NAN is defined (see
https://bugs.python.org/issue46656). If the answer to the first question is
"No", then we need to fix the build under Py_NO_NAN. That's not a big deal
- perhaps a couple of hours of work.
--
Mark
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/GUIR2HZHFV2TDS7GUQHAHFSA4IC3QLMZ/
Code of Conduct: http://python.org/psf/codeofconduct/
