[issue39288] Add math.nextafter(a, b)

STINNER Victor added the comment: I created bpo-39310 to propose to add math.ulp(x). -- ___ Python tracker ___ ___ Python-bugs-list

[issue39288] Add math.nextafter(a, b)

STINNER Victor added the comment: New changeset 54cfbb2feee1f7328c3d6799ec3734b00824b555 by Victor Stinner in branch 'master': bpo-39288: Add examples to math.nextafter() documentation (GH-17962) https://github.com/python/cpython/commit/54cfbb2feee1f7328c3d6799ec3734b00824b555 -- _

[issue39288] Add math.nextafter(a, b)

Mark Dickinson added the comment: > I suggest "next_after" instead of "nextafter". "nextafter" gives us consistency with C, with NumPy and with other compound names in the math module ("isnan", "isclose", "copysign"). My own brain doesn't perceive either of "nextafter" or "next_after" as mor

[issue39288] Add math.nextafter(a, b)

Change by STINNER Victor : -- pull_requests: +17371 pull_request: https://github.com/python/cpython/pull/17962 ___ Python tracker ___ __

[issue39288] Add math.nextafter(a, b)

Raymond Hettinger added the comment: I suggest "next_after" instead of "nextafter". -- ___ Python tracker ___ ___ Python-bugs-list

[issue39288] Add math.nextafter(a, b)

STINNER Victor added the comment: I chose to make y mandatory in nextafter(x, y). Implement your own flavor if nextUp(x) if you want to omit y. I prefer to make y explicit, becauseit has been said in this discussion that "nextafter" name is ambiguous. Thanks all for the constructive discussi

[issue39288] Add math.nextafter(a, b)

STINNER Victor added the comment: New changeset 100fafcf20e8fc67cd8ef512074f9c0a253cb427 by Victor Stinner in branch 'master': bpo-39288: Add math.nextafter(x, y) (GH-17937) https://github.com/python/cpython/commit/100fafcf20e8fc67cd8ef512074f9c0a253cb427 -- ___

[issue39288] Add math.nextafter(a, b)

Mark Dickinson added the comment: > Do you mean nextafter(x, y=inf, /): toward positive infinity by default? Yes; I believe that was what Steven was suggesting in the last part of msg359779. I don't have strong feelings either way. -- ___ Python t

[issue39288] Add math.nextafter(a, b)

Mark Dickinson added the comment: [Steven] > I know Wikipedia isn't a primary source, but it says IEEE 754 recommends > nextafter(x, y). Um. Then it sounds as though Wikipedia is out of date. Which page was this on? IEEE 754-1985 did recommend nextafter, but only in Annex A, which is not s

[issue39288] Add math.nextafter(a, b)

STINNER Victor 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

[issue39288] Add math.nextafter(a, b)

Mark Dickinson added the comment: "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. [Victor] > It mentions for example "If x== y, y (of the type x) shall be returned" an

[issue39288] Add math.nextafter(a, b)

STINNER Victor added the comment: Oh, I forgot to also give the nextafer() link to the POSIX standard: https://pubs.opengroup.org/onlinepubs/009695399/functions/nextafter.html 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 returne

[issue39288] Add math.nextafter(a, b)

STINNER Victor added the comment: PR 17937 is ready to be reviewed. The tests passed on the regular CIs and buildbots: good. > That last assumes you want -0 and +0 to act differently It is the case: I wrote an unit test checking exactly that, and it works as expected on all platforms (Windo

[issue39288] Add math.nextafter(a, b)

Tim Peters added the comment: [Steven] > I think the second argument should also be optional, so > that nextafter(x) returns the next representable float. That's why the name sucks - there are, in general, two adjacent floats, so "next" is ambiguous. I expect you intend that y default to mat

[issue39288] Add math.nextafter(a, b)

Steven D'Aprano added the comment: I agree, "nextafter" is so widely used it's probably pointless to fight against the name :-) Mark: "IEEE 754, on the other hand, requires instead nextUp and nextDown". I know Wikipedia isn't a primary source, but it says IEEE 754 recommends nextafter(x, y)

[issue39288] Add math.nextafter(a, b)

Tim Peters added the comment: No doubt that something along these lines would be useful. `nextafter()` is too widely implemented to fight against, despite the sucky name ;-) I believe the rest should be straightforward (for those who want them) to do with one-liners, so there's not much of

[issue39288] Add math.nextafter(a, b)

STINNER Victor added the comment: > 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,

[issue39288] Add math.nextafter(a, b)

Mark Dickinson added the comment: I'm not opposed to some form of this by any means, but I fear there's some bikeshedding to go through, both on the name and the functionality (one function with two arguments, or two functions each taking a single argument?). C 99 prescribes "nextafter" and

[issue39288] Add math.nextafter(a, b)

Change by STINNER Victor : -- keywords: +patch pull_requests: +17345 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17937 ___ Python tracker ___ _

[issue39288] Add math.nextafter(a, b)

Change by STINNER Victor : -- keywords: +3.3regression nosy: +lemburg, mark.dickinson, rhettinger, stutzbach ___ Python tracker ___

[issue39288] Add math.nextafter(a, b)

New submission from STINNER Victor : Linux manual page of nextafter(): """ The nextafter() function return the next representable floating-point value following x in the direction of y. If y is less than x, these functions will return the largest representable number less than x. If x equal