STINNER Victor <vstin...@python.org> added the comment: 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue39288> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
