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
math.modf() change integer returned part as integer instead of float #82994
Comments
The description for this function reads: Since the second returned value is "integer parts", I submit that the value should be integer. |
This is odd. The underlying C library modf() returns an integer for the second part. Likewise the Python math.frexp() function returns an integer for the second part. So, I'm not sure why Python's math.modf() returns a float for the second field. |
Raymond, I think you've tricked yourself ;-) The prototype for C's duoble modf is double modf(double x, double *intptr); Yes, after the call *intptr is an exact integer, but in the double format. >>> math.modf(1e300)
(0.0, 1e+300) I don't think it would be doing anyone a real favor by returning 1000000000000000052504760255204420248704468581108159154915854115511802457988908195786371375080447864043704443832883878176942523235360430575644792184786706982848387200926575803737830233794788090059368953234970799945081119038967640880074652742780142494579258788820056842838115669472196386865459400540160 instead of 1e300 for "the integer part".
>>> math.frexp(1e300)
(0.7466108948025751, 997) A better analogy would be to math.floor(), which does return an int, even for cases like floor(1e300). In Python 2 it did not (it returned an integer but in float format), and I believe it was a mistake to change it to return an int. Building giant ints is not what C does, so is surprising on that count alone, and is far more expensive than returning (as C does) a float. That is, we didn't improve on C's floor, we introduced a surprising difference that sometimes hurts and rarely helps (if anyone really wanted an int, they could apply int() to the float result). |
Yup. |
[Tim]
Agreed.
Also agreed. |
What about math.trunc() and round()? Should they return int or float? And what about the result of the floor division of floats? Should it be int or float? |
[Serhiy]
math.trunc was deliberately introduced to be an explicitly-value-modifying conversion to int (as opposed to "int" itself, which is used for both lossy and lossless conversions to int); so from that perspective it should return int. round is less problematic than floor and ceil because it provides a way to preserve the type (by using Single-argument round frequently turns out to be the right way to convert a float to an int in practice (e.g., in something like Floor division of floats already returns a float, and I can't see a strong reason to change that. It's not exactly the most useful floating-point operation in the first place, so it's hard to find use-cases that argue for one return type over the other. But I think all of this is academic: it's another case of "Should we have done this differently in the first place?" versus "Should we change it now?". The answer to the first question *might* be "Yes" for some pieces, but the answer to the second is almost certainly "No". |
Thanks for the suggestion. I'm closing this as rejected, for the reasons Tim gave. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: