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

Expected behavior of math.ceil, math.floor, math.trunc, and round #143

Closed
casevh opened this issue May 29, 2017 · 6 comments · Fixed by #499
Closed

Expected behavior of math.ceil, math.floor, math.trunc, and round #143

casevh opened this issue May 29, 2017 · 6 comments · Fixed by #499

Comments

@casevh
Copy link
Collaborator

casevh commented May 29, 2017

Note: I am specifically discussing float/mpfr inputs.

The behavior of the math.ceil, math.floor, math.trunc, and round changed between Python 2 and Python 3. In Python 2.x, a float was always returned. In Python 3.x, math.ceil, math.floor, and math.trunc return an integer type instead of a floating point type. round returns an integer type if the requested numbers of digits is 0 but returns a floating point type for in the requested number of digits is either greater than 0 or less than 0.

What should gmpy2 2.1 do?

  1. Follow the behavior of the Python version?
  2. Continue to use the Python 2 behavior even in Python 3?
  3. Use the Python 3 behavior on Python 2?
  4. Add a context option to allow the user to select a specific behavior?
@videlec
Copy link
Contributor

videlec commented Jun 15, 2017

I would like to propose another alternative that sounds more consistent to what gmpy2 is.

  1. implement floor, ceil and round as methods of mpfr objects (as specified in the mpfr library with mpfr_floor, mpfr_ceil and mpfr_round) and ignore the Python behavior of math.ceil, math.floor and math.trunc with gmpy2 arguments.

@asmeurer
Copy link

asmeurer commented Jun 9, 2020

I would like to strongly advise that gmpy2 follow the Python 3 behavior and return integer types for the built-in Python math functions. I don't see a need for gmpy2 to continue to support Python 2 at this point, but if you do, you should match the behavior of the Python version that is running (option 1), unless that makes the code too complicated in which case just use Python 3 behavior everywhere (option 3) (although if the code is too complicated, that's a good sign you should drop Python 2 support).

The @videlec suggestion to not implement math.ceil, etc. is a bad one. Not only would that break compatibility with existing code, but it breaks with the design of gmpy2 which is to have Python duck-typed numeric types that wrap GMP types. I don't really follow the argument as to how this would be more consistent with what gmpy2 is.

@skirpichev
Copy link
Contributor

skirpichev commented Jul 22, 2024

I would like to strongly advise that gmpy2 follow the Python 3 behavior and return integer types for the built-in Python math functions.

There are no options. The Python documentation says: "If x is not a float, delegates to x.floor, which should return an Integral value." (c) Same for __ceil__() and __trunc__() dunders. We have only options: mpz or int. Probably we should choose mpz.

skirpichev added a commit to skirpichev/gmpy that referenced this issue Jul 22, 2024
@skirpichev skirpichev mentioned this issue Jul 22, 2024
@asmeurer
Copy link

Yes the result should definitely stay as a gmpy type as long as Python allows it.

@casevh
Copy link
Collaborator Author

casevh commented Jul 23, 2024

Would this be considered a bugfix and appropriate for v2.2.2 or must it wait for v2.3.0? I personally am ok with it as a bugfix.

@skirpichev
Copy link
Contributor

For me this looks as a bugfix as well. Probably, you should create a dedicated branch for 2.2.x releases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants