I'm not sure about the unit tests: not sure if they are portable on any IEEE 754 implementation, and if the test would work on non-IEEE 754 implementation. Maybe the test should be decorated ith @requires_IEEE_754?

Maybe the test should be decorated ith @requires_IEEE_754?

Yes, I think so. There's nothing to guarantee that the existing test would work on a non IEEE 754 system, should Python ever encounter one.

Please could we also have tests covering all the various corner cases: signed zeros, infinities, nans, subnormals, etc.? There's a lot that can go wrong, and I don't think it's safe to trust that the platform's libm does the right thing. (We've tried that before.)

Oh, and once we have more comprehensive tests, it might be worth trying out the new "test on the buildbots" functionality with this PR, to ferret out any platforms that have dodgy implementations of nextafter.

Please could we also have tests covering all the various corner cases: signed zeros, infinities, nans, subnormals, etc.?

I added more tests. Which tests do you want to signed zeros? The sign doesn't seem to matter:

>>> math.nextafter(0.0, 1.0)
5e-324
>>> math.nextafter(-0.0, 1.0)
5e-324
>>> math.nextafter(-0.0, -1.0)
-5e-324
>>> math.nextafter(+0.0, -1.0)
-5e-324

For subnormals, I wrote the following tests, is it what you expect?

        # around 0.0
        self.assertEqual(math.nextafter(0.0, INF),
                         sys.float_info.min * sys.float_info.epsilon)
        self.assertEqual(math.nextafter(0.0, -INF),
                         (-sys.float_info.min) * sys.float_info.epsilon)

There's a lot that can go wrong, and I don't think it's safe to trust that the platform's libm does the right thing. (We've tried that before.)

Do you that if nextafter() behaves differently on a platform, Python should patch the function?

🤖 New build scheduled with the buildbot fleet by @vstinner for commit c12293b 🤖

If you want to schedule another build, you need to add the "🔨 test-with-buildbots" label again.

Oh, and once we have more comprehensive tests, it might be worth trying out the new "test on the buildbots" functionality with this PR, to ferret out any platforms that have dodgy implementations of nextafter.

Let me try this new toy :-)

I don't understand this result, but nextafter() gives me the expected result, whereas 1.0-epsilon gives me a surprising smaller value.

>>> math.nextafter(1.0, 2.0) == 1.0 + sys.float_info.epsilon
True
>>> math.nextafter(1.0, 0.0) == 1.0 - sys.float_info.epsilon
False
>>> math.nextafter(1.0, 0.0), 1.0 - sys.float_info.epsilon
(0.9999999999999999, 0.9999999999999998)
>>> math.nextafter(1.0, 0.0).hex(), (1.0 - sys.float_info.epsilon).hex()
('0x1.fffffffffffffp-1', '0x1.ffffffffffffep-1')

Good: the test passed on all buildbots!

buildbot/PPC64 Fedora PR failed on test_distutils, but it's unrelated to this PR:

• https://buildbot.python.org/all/#/builders/292/builds/13
• https://bugs.python.org/issue39248

I fixed the implementation to use C double rather than C float, rebased my PR and squashed commits.

@mdickinson: Would you mind to review the PR again?

I'm not sure about "If x equals to y, return y": an implementation might return x. But I wrote an unit test to ensure that y is returned: the test using signed zeros.

whereas 1.0-epsilon gives me a surprising smaller value.

Makes sense: assuming IEEE 754, the next Python float down from 1.0 is 1.0 - 0.5*epsilon, so 1.0 - epsilon is two floats away from 1.0.

Do you that if nextafter() behaves differently on a platform, Python should patch the function?

My hope is that all platforms we care about follow the specification, but I'd at least like to know about it if there are platforms that don't.

If it does turn out that some platforms deviate from the specification, we can make an informed decision about how to deal with them. But let's save that for when it happens.

PR rebased to fix a conflict in Doc/whatsnew/3.9.rst and commits squashed.

Once regular CI tests will pass, I will give a second try to buildbots since I added many tests since the previous run.

@mdickinson: "If it does turn out that some platforms deviate from the specification, we can make an informed decision about how to deal with them. But let's save that for when it happens."

Sure, I totally agree. I added tons of unit tests, so different behaviors will be easily catched.

I added tons of unit tests, so different behaviors will be easily catched.

Yep, the tests look very good. :-)

Thanks for the review @mdickinson and for helping to write unit tests.

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot s390x Debian 3.x has failed when building commit 100fafc.

What do you need to do:

1. Don't panic.
2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/105/builds/167) and take a look at the build logs.
4. Check if the failure is related to this commit (100fafc) or if it is a false positive.
5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/105/builds/167

Failed tests:

• test_asyncio

Failed subtests:

• test_start_new_session - test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests

Summary of the results of the build (if available):

==

Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_asyncio/test_subprocess.py", line 168, in test_start_new_session
    self.assertEqual(exitcode, 8)
AssertionError: 255 != 8


Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/asyncio/unix_events.py", line 1302, in _do_waitpid
    loop, callback, args = self._callbacks.pop(pid)
KeyError: 23823