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:10:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
"nextafter" is fine with me. I just wanted to make sure that we'd considered the options, and weren't choosing nextafter simply because it's the easiest thing to implement.


> It mentions for example "If x== y, y (of the type x) shall be returned" and "If x or y is NaN, a NaN shall be returned". It's good to know that it's specified ;-)

Agreed; it would be good to make sure that we have tests for the behaviour matching the spec, particularly with respect to signed zeros: the first clause here implies nextafter(0.0, -0.0) is -0.0, while nextafter(-0.0, 0.0) is 0.0. I'd also recommend adding tests for nextafter(smallest_normal, 0.0), nextafter(largest_normal, inf), nextafter(inf, 0), and the like. 

The C standard isn't 100% clear on what nextafter(-0.0, inf) should be: it could be argued that the "next" representable float after -0.0 in the direction of infinity is 0.0. But IEEE 754 is explicit that nextUp(±0) is the smallest positive subnormal, and we should have a test for that, too.

Making the second argument optional sounds reasonable to me, but doesn't necessarily have to happen in the existing PR; we can always add that option later.
Date User Action Args
2020-01-11 17:10:04mark.dickinsonsetrecipients: + mark.dickinson, lemburg, tim.peters, rhettinger, vstinner, stutzbach, steven.daprano
2020-01-11 17:10:04mark.dickinsonsetmessageid: <>
2020-01-11 17:10:04mark.dickinsonlinkissue39288 messages
2020-01-11 17:10:04mark.dickinsoncreate