This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients lemburg, mark.dickinson, rhettinger, steven.daprano, stutzbach, tim.peters, vstinner
Date 2020-01-11.17:30:37
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>

> I know Wikipedia isn't a primary source, but it says IEEE 754 recommends nextafter(x, y).

Um. Then it sounds as though Wikipedia is out of date. Which page was this on?

IEEE 754-1985 did recommend nextafter, but only in Annex A, which is not strictly part of the standard. ("This Appendix is not a part of ANSI/IEEE Std 754-1985, IEEE Standard for Binary Floating-Point Arithmetic [...]")

IEEE 754-2008 (section 5.3.1) added nextUp and nextDown as required operations, and the text for those operations is word-for-word identical in the current IEEE 754-2019, save for "sNaNs" being spelled out as "signaling NaNs".

> My understanding of IEEE-754 is that the functionality is required, not the specific API. That is, it's not required to have literally two functions called "nextUp" and "nextDown", so long as you can get the next larger and next smaller float.

Agreed. It's not really spelled out in the standard exactly what "conformance" would mean, but I agree that providing nextafter should be sufficient if we want to claim that Python supports the nextUp and nextDown operations.

Not that Python makes any claim to conform with IEEE 754 anyway, but I think it's still a useful standard to consider when we're choosing what to do in the math module.

I guess if we *wanted* to claim strict conformance with IEEE 754 (which we don't, right now), we'd probably also want to add a note in the docs explaining how nextUp and nextDown are represented in terms of nextafter. But that seems a bit redundant to me.
Date User Action Args
2020-01-11 17:30:37mark.dickinsonsetrecipients: + mark.dickinson, lemburg, tim.peters, rhettinger, vstinner, stutzbach, steven.daprano
2020-01-11 17:30:37mark.dickinsonsetmessageid: <>
2020-01-11 17:30:37mark.dickinsonlinkissue39288 messages
2020-01-11 17:30:37mark.dickinsoncreate