Author vstinner
Recipients lemburg, mark.dickinson, rhettinger, steven.daprano, stutzbach, tim.peters, vstinner
Date 2020-01-11.17:28:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1578763720.24.0.746643464734.issue39288@roundup.psfhosted.org>
In-reply-to
Content
Mark:
> 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.

Do you mean nextafter(x, y=inf, /): toward positive infinity by default? I prefer to keep the second parameter mandatory, to make the direction more explicit. As Tim showed, it's easy to implement nextUp() on top of 
nextafter().


> "nextafter" is fine with me.

Good :-) It seems like everybody agrees on nextafter().


> 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 had a test for math.nextafter(+0.0, -0.0). I added a test for math.nextafter(-0.0, +0.0).


> I'd also recommend adding tests for nextafter(smallest_normal, 0.0), nextafter(largest_normal, inf), nextafter(inf, 0),

Done.


> and the like.

Feel free to suggest more tests on the PR.


> The C standard isn't 100% clear on what nextafter(-0.0, inf) should be

I added a test for it, for positive and negative zeros.


> But IEEE 754 is explicit that nextUp(±0) is the smallest positive subnormal

That's what I get.
History
Date User Action Args
2020-01-11 17:28:40vstinnersetrecipients: + vstinner, lemburg, tim.peters, rhettinger, mark.dickinson, stutzbach, steven.daprano
2020-01-11 17:28:40vstinnersetmessageid: <1578763720.24.0.746643464734.issue39288@roundup.psfhosted.org>
2020-01-11 17:28:40vstinnerlinkissue39288 messages
2020-01-11 17:28:39vstinnercreate