Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

bpo-38639: Optimize floor(), ceil() and trunc() for floats.#16991

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged

Conversation

@serhiy-storchaka
Copy link
Member

@serhiy-storchakaserhiy-storchaka commentedOct 30, 2019•
edited by bedevere-bot
Loading

Copy link
Member

@mdickinsonmdickinson left a comment

Choose a reason for hiding this comment

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

Proposed changes LGTM. For things of exact typefloat (and possibly also forfloat subclasses), I think we could dispense with themath_1_to_int complications to get even more speedup. But that doesn't have to happen in this PR.

Do we have tests for the various cases of floats, float subclasses that don't override__floor__, float subclasses thatdo override__floor__, things that aren't floats but provide a__float__ method, etc.? If not, would it be worth adding such tests?

@mdickinson
Copy link
Member

Do we have tests for the various cases ...

It occurs to me that I don't know how a subclass offloat that implements its own__float__ should behave.

>>> class MyFloat(float):...     def __float__(self):...         return 9.0... >>> x = MyFloat(16)>>> math.sqrt(x)4.0>>> float(x)9.0

@serhiy-storchaka
Copy link
MemberAuthor

I think that it would be better to not call__float__ forfloat subclasses,__int__ and__index__ forint subclasses,__complex__ forcomplex subclasses,__str__ forstr subclasses, etc. We already have a content of corresponding class and can convert it to a C value or to a new Python instance.

@serhiy-storchaka
Copy link
MemberAuthor

Thank you for your review@mdickinson, I addressed your comments and added tests. Could you please take another look?

@serhiy-storchakaserhiy-storchaka merged commit5fd5cb8 intopython:masterNov 16, 2019
@serhiy-storchakaserhiy-storchaka deleted the math-floor-float branchNovember 16, 2019 16:00
jacobneiltaylor pushed a commit to jacobneiltaylor/cpython that referenced this pull requestDec 5, 2019
shihai1991 pushed a commit to shihai1991/cpython that referenced this pull requestJan 31, 2020
mdickinson pushed a commit that referenced this pull requestFeb 9, 2023
`math_1_to_whatever()` is no longer useful, since all existing uses of it convert to `float`.Earlier versions of Python used `math_1_to_whatever` with an integer target; seegh-16991 for the PR where that use was removed.
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

1 more reviewer

@mdickinsonmdickinsonmdickinson approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@serhiy-storchaka@mdickinson@the-knights-who-say-ni@bedevere-bot
[8]ページ先頭
©2009-2025 Movatter.jp