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 vstinner
Recipients lemburg, mark.dickinson, rhettinger, stutzbach, tim.peters, vstinner
Date 2020-01-11.00:43:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> NumPy has nextafter.

That's why I proposed math.nextafter() name.

Moreover, in the math module, most functions reuse the same names than C function names: expm1(), atan2(), erf(), etc.

> IEEE 754, on the other hand, requires instead nextUp and nextDown, which take a single argument and move towards +inf or -inf (respectively).

When I played with bpo-39277, I used nextafter() to try to implement manually a conversion from an integer to a float using rounding towards zero. So I prefer nextafter() than nextUp()/nextDown(): it gives more features.

> but nextAwayFromZero doesn't match any of these

It seems easy to reimplement it using nextafter(), no?

def nextAwayFromZero(x):
    if x < 0:
        return math.nextafter(x, -float("inf"))
        return math.nextafter(x, +float("inf"))

> Python's Decimal type has a two-argument next_toward method.

It also has next_minus() and next_plus() which don't match "nextUp and nextDown" names requires by IEEE 754.

I'm not comfortable with math.next_after() or math.next_toward() name: use a different than the libc function name (add an underscore). For me, the math module is a thin wrapper to libm function, as the os module is a thin wrapper to libc functions.
Date User Action Args
2020-01-11 00:43:44vstinnersetrecipients: + vstinner, lemburg, tim.peters, rhettinger, mark.dickinson, stutzbach
2020-01-11 00:43:44vstinnersetmessageid: <>
2020-01-11 00:43:44vstinnerlinkissue39288 messages
2020-01-11 00:43:44vstinnercreate