[Python-bugs-list] [ python-Bugs-444510 ] int() should guarantee truncation

[noreply@sourceforge.net]

Bugs item #444510, was opened at 2001-07-25 09:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444510&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Tim Peters (tim_one)
Summary: int() should guarantee truncation

Initial Comment:
The int() function currently warns that it cannot
guarantee truncation because C doesn't guarantee it. 
However, all known (to us) C implementations *do*
truncate, and the C99 standard requires it, so we might
as well change the code to promise truncation and
tighten the docs.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-07-26 13:42

Message:
Logged In: YES 
user_id=31435

I expect the new code is a little faster, becuase it's 
simpler, requiring fewer tests+branches.  The old code had 
to call one of {ceil, floor}, the new code always calls modf
(), and all of {ceil, floor, modf} should cost about the 
same (they're all picking "the integer part" out of a 
double; modf has the extra expense of returning the 
leftover part too, but ceil and floor have the extra 
expense of examining the leftover part to figure out 
whether to adjust the raw integer part).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-26 13:24

Message:
Logged In: YES 
user_id=6380

I don't know if you worry that what you coded now is slower,
but a config-time test could determine whether it's
necessary.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-07-26 13:19

Message:
Logged In: YES 
user_id=31435

Like your commodities salesman is required to tell you, 
past behavior is no guarantee of future performance.  Heck, 
for all I know, the Cray T3E may not truncate -- don't know 
whether they ever *got* that far in the test suite.  If you 
want a guarantee, you need code that makes it so regardless.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-26 13:10

Message:
Logged In: YES 
user_id=6380

Cool.  But if that test proved it, why bother change the
code?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-07-26 13:05

Message:
Logged In: YES 
user_id=31435

Truncation now guaranteed.

Doc/lib/libfuncs.tex; new revision: 1.81
Lib/test/test_b1.py; new revision: 1.36
Objects/floatobject.c; new revision: 2.83

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-07-26 12:51

Message:
Logged In: YES 
user_id=31435

Assigned to me.

BTW, note that I wasn't guessing about the behavior of "all 
known Python platforms":  Python's test_b1.py has been 
checking all along that int(float) truncates, so if there 
were a platform where that didn't happen, we would have 
heard about it.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444510&group_id=5470