[issue38813] math.modf() change integer returned part as integer instead of float
Tim Peters
report at bugs.python.org
Fri Nov 15 14:14:36 EST 2019
Tim Peters <tim at python.org> added the comment:
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".
`frexp()` is very different, in that the second part is a (small!) integer exponent - a float would work for that too, but would be surprising.
>>> 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).
----------
_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38813>
_______________________________________
More information about the Python-bugs-list
mailing list