Tim Peters <t...@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 <rep...@bugs.python.org> <https://bugs.python.org/issue38813> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
