-
-
Notifications
You must be signed in to change notification settings - Fork 30.8k
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
Conversation
There was a problem hiding this 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?
This PR needs tests. |
There was a problem hiding this 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
functionsceil
andfloor
. - 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
andfloor
intoPyLong_FromDouble
.
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 |
e4ff4b8
to
0b36750
Compare
I have made the requested changes; please review again |
Thanks for making the requested changes! @mdickinson: please review the changes made to this pull request. |
I submitted benchmarks to bpo |
There was a problem hiding this 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?
#16991 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 |
b2bd4eb
to
40db4db
Compare
me:
I checked the current implementation of math.floor(): there is a fast-path for exact type float which does something like I'm fine with calling the |
Oh, that's @serhiy-storchaka 's PR #16991 which has just been merged. I didn't notice ;-) |
There was a problem hiding this 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.
@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? |
@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. |
@vstinner Merging is fine with me. |
https://bugs.python.org/issue38629