bpo-38629: implement __floor__ and __ceil__ for float

[isidentical]

https://bugs.python.org/issue38629

[vstinner]

What is the performance impact on math.floor(1.0) and math.ceil(1.0)? Faster, slower, no significant impact?

[mdickinson]

This PR needs tests.

[mdickinson]

Thanks for this PR. Some changes are needed:

• The PR needs unit tests.
• The implementations won't do the right thing on machines with 32-bit longs: there's no adjustment for non-integer values in the non-fast path.
• As @vstinner suggested, it would be much simpler to just use the libm functions ceil and floor.
• There's no real need for the fast path, given #15611: I'd suggest dropping that and simply sending the output of ceil and floor into PyLong_FromDouble.

[bedevere-bot]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[isidentical]

I have made the requested changes; please review again

[bedevere-bot]

Thanks for making the requested changes!

@mdickinson: please review the changes made to this pull request.

[isidentical]

I submitted benchmarks to bpo

[mdickinson]

Changes LGTM; thank you! The performance is still a concern, but if some form of #16991 gets merged then that wouldn't be so much of an issue.

@serhiy-storchaka@vstinner Does the current state of the PR seem okay to you?

[serhiy-storchaka]

#16991 will solve the performance issue for exact floats, but not for subclasses.

[mdickinson]

will solve the performance issue for exact floats, but not for subclasses.

I don't think there's too much reason to care about fine-tuning of performance for float subclasses. The most common subclass is NumPy's float64, and if you're using NumPy you're likely using NumPy's floor instead of math.floor anyway.

[vstinner]

me:

What is the performance impact on math.floor(1.0) and math.ceil(1.0)? Faster, slower, no significant impact?

I checked the current implementation of math.floor(): there is a fast-path for exact type float which does something like PyLong_FromDouble(floor(PyFloat_AS_DOUBLE(number))).

I'm fine with calling the __floor__() method for subclasses. That's the purpose of subclasses: being able to override some methods. That's part of the Python semantics.

[vstinner]

I checked the current implementation of math.floor(): there is a fast-path for exact type float which does something like PyLong_FromDouble(floor(PyFloat_AS_DOUBLE(number))).

Oh, that's @serhiy-storchaka 's PR #16991 which has just been merged. I didn't notice ;-)

[vstinner]

LGTM. There is no performance overhead on math.floor() and math.ceil() for exact float.

I'm fine with having a small overhead for float subclasses. I didn't measure the overhead, I expect it to be really small or even not significant.

[vstinner]

@mdickinson@serhiy-storchaka: I'm not sure that you agree, so I didn't merge the PR. I approve the PR, so I'm fine with merging it. What about you?

[vstinner]

@mdickinson@serhiy-storchaka: I plan to merge this PR next Friday (December 21) if no one replies.

@isidentical: Please ping me next Friday if I forget to merge your PR.

[mdickinson]

@vstinner Merging is fine with me.