Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bpo-38629: implement __floor__ and __ceil__ for float #16985

Merged
merged 3 commits into from
Dec 15, 2019

Conversation

isidentical
Copy link
Member

@isidentical isidentical commented Oct 29, 2019

Copy link
Member

@vstinner vstinner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Objects/floatobject.c Outdated Show resolved Hide resolved
Objects/floatobject.c Outdated Show resolved Hide resolved
@mdickinson
Copy link
Member

This PR needs tests.

Copy link
Member

@mdickinson mdickinson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 bpo-37986: Improve perfomance of PyLong_FromDouble() #15611: I'd suggest dropping that and simply sending the output of ceil and floor into PyLong_FromDouble.

@bedevere-bot
Copy link

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
Copy link
Member Author

I have made the requested changes; please review again

@bedevere-bot
Copy link

Thanks for making the requested changes!

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

@isidentical
Copy link
Member Author

I submitted benchmarks to bpo

@brandtbucher brandtbucher added the type-feature A feature request or enhancement label Oct 30, 2019
Copy link
Member

@mdickinson mdickinson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

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

@mdickinson
Copy link
Member

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
Copy link
Member

vstinner commented Dec 5, 2019

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
Copy link
Member

vstinner commented Dec 5, 2019

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 ;-)

Copy link
Member

@vstinner vstinner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

vstinner commented Dec 5, 2019

@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
Copy link
Member

@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
Copy link
Member

@vstinner Merging is fine with me.

@vstinner vstinner merged commit cb8b946 into python:master Dec 15, 2019
shihai1991 pushed a commit to shihai1991/cpython that referenced this pull request Jan 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type-feature A feature request or enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants