cpython
cpython copied to clipboard
python
Let math.nextafter() compute multiple steps at a time.
Sometimes math.nextafter() needs to be applied multiple times in succession.
x = nextafter(nextafter( nextafter(x, inf), inf), inf) # Three steps up
It would be nice if the function supported this directly:
x = nextafter(x, inf, n=3)
The implementation would just be a for-loop:
def newnextafter(x, y, /, *, n=1):
'Return the floating-point value n steps after x towards y.'
for i in range(n):
x = nextafter(x, y)
return x
The formal paramater can be just n or the longer but more descriptive steps.
This feels like a needless expansion of the API to me; I don't think I've ever encountered a use-case for this. On the rare occasions that such a use-case turns up, what's wrong with the for loop, or with adding an integer multiple of math.ulp(x) to x?
-1 from me.
I wouldn't posted the issue if I hadn't needed this, so it is not "needless".
In 30 seconds of searching, I found another example:
https://github.com/ericherman/libefloat/blob/ad606d566ac5310aabb4fff8890e35200a718e8d/tests/test-distance-64.c#L94
Python is a high level language and it is suitable to incorporate options that are more expansive than used in low level languages like C that tend to focus on atomic steps.
Sure, I don't doubt that you had a genuine need, but that need is trivially addressed with a for loop. My use of "needless" referred to the expansion of the API. You needing the functionality is not the same thing as the math module needing to support the functionality directly.
Sorry, but I don't see this use-case as valuable enough or common enough to warrant expanding the math.nextafter API.
I'm also concerned that this might be a performance trap: a user could easily write nextafter(x, y, steps=10**6) without realising that that means a million invocations of nextafter internally. With an explicit for loop, the effect on running time is much more obvious.
I concur with @mdickinson. It is too niche feature, and it is not difficult to implement a wrapper in Python. BTW, the case you found is in tests.
I wish this wasn't dismissed so casually. All uses of nextafter() are "niche". There are only a handful of people who will ever use it.
I submitted the feature request because I needed to write the replacement function in pure Python (much like the example I posted above) and it was distracting and felt amiss, like something the should have already have been built in to a higher level language.
I wrote the function while working on another problem and had casually created an incorrect result along the way:
>>> sixth_largest_random = 1.0 - 6 * ulp(1.0)
>>> sixth_largest_random
0.9999999999999987
Fortunately, I spotted the problem before going too far with it and wrote the above function giving the correct answer:
>>> sixth_largest_random = newnextafter(1.0, -inf, n=6)
>>> sixth_largest_random
0.9999999999999993
The entire side trip was distracting and annoying. It took the focus away for the error analysis I was working on at the time.
The proposal is an easy thing to do. It isn't even slightly confusing. It would be handy when needed by the few who ever use this function. I don't see any downside.
Note, in numpy and scipy, most interesting functions have many options. That seems to work well for them. But in Python, there seems to be an urge to fight against the simplest of options as "unnecessary API expansion".
@rhettinger @hauntsaninja @mdickinson
You don't need a loop for this. See this pure Python prototype inspired by an old StackOverflow question of mine.
And here's a prototype of a fix of the PR. (Please keep in mind that the C code in the PR isn't tested nor even run. The pure Python version has Hypothesis tests, so it's much more reliable.)
Removing "easy" for now as this needs a resolution between the two maintainers of the math module.
@rhettinger @mdickinson
If the goal here is to produce a one line implementation capable of looping the execution of math.next after, it can be achieved using the reduce function from func tools.
from math import nextafter,inf
from functools import reduce
reduce(nextafter,[-inf]*6,1.0)
The starting point, 1.0, is the third argument, then you must provide an iterator that outputs the direction of nextafter for the desired number of times, in this case I use a list and duplicate -inf 6 times.
Bugfix for the tests, applied by now
The tests are broken. You assert the following ("soll"/"ist" are expected and actual result (better use English)):
assert math.isnan(soll) == math.isnan(ist) or soll == ist
If both values aren't nan, then math.isnan(soll) == math.isnan(ist) is true, and soll == ist doesn't get checked! In fact, I modified your solution code to end with the totally wrong
result = (the expression you return)
return result if math.isnan(result) else 42
and the tests didn't catch it.
You should change == to and:
assert math.isnan(soll) and math.isnan(ist) or soll == ist
Btw, reduce+repeat is about 2-3 times faster than the loop, making your tests run faster (and avoiding the DeadlineExceeded error I get with the loop):
from functools import reduce
from itertools import repeat
def nextafter_reduce(start, goal, steps):
return reduce(math.nextafter, repeat(goal, steps), start)
I want to make sure we stay focused here. Though the original reporter is trying to avoid writing the loop, and others indicate the required loop is small enough that it is of no consequence; the Pure Python Prototype is being pushed as a solution despite being an entire new module. This would seem to be the wrong direction.
What happens here? The issue is coming up on its first birthday. The question for users boils down to this: to loop or not to loop. What is the mechanism that is used to decide when there is this kind of division?
The pure Python prototype would turn into a small C function. Not an entire new module.
@pochmann I implemented your suggestions in https://gist.github.com/matthiasgoergens/28e58abd6beaea72bd2e49085c435966
Removing "easy" for now as this needs a resolution between the two maintainers of the math module.
FWIW, I only care about this a tiny bit. Though I think it would be nice to have, I won't lose any sleep if this gets closed.
I overhauled the C PR https://github.com/matthiasgoergens/cpython/pull/5/files Tests pass now.
I'll point it at the upstream CPython repository, after I polish the git history.
Done in #103881. Thanks to @matthiasgoergens.
Thanks for fixing the PR up at the end, too!