[ python-Bugs-789290 ] Minor FP bug in object.c

[SourceForge.net]

Bugs item #789290, was opened at 2003-08-15 15:15
Message generated for change (Comment added) made by nmm1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789290&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Maclaren (nmm1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Minor FP bug in object.c

Initial Comment:
This is closely related to the one I have reported
in floatobject.c (789159).  VERY closely.  It is
shown up by the following test on a machine with
64-bit longs and floating-point trapping turned on
(though it might show up as bogus results even with
no trapping):

print int( 9223372036854775200.0)
print int( 9223372036854775800.0)
print int(-9223372036854776800.0)
print int(-9223372036854777000.0)

958,959c958,959
<       double intpart, fractpart;
<       int expo;
---
>       double intpart, fractpart, z;
>       int expo, i, j;
978c978,989
<               if (intpart > LONG_MAX || -intpart >
LONG_MAX) {
---
>               /* Remember that (double)LONG_MAX can
round either way. */
>               if (intpart > LONG_MIN/2 && intpart <
LONG_MAX/2)
>                       z = 0.0;
>               else {
>                       z = (intpart >= 0.0 ? intpart :
-intpart);
>                       for (i =
(sizeof(long)*CHAR_BIT-1)/16; i >= 0; --i) {
>                               x = LONG_MAX;
>                               for (j = 0; j < i; ++j)
x >>= 16;
>                               z -=
ldexp(x&0xffff,16*i);
>                       }
>               }
>               if (z > 0.0) {


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

>Comment By: Nick Maclaren (nmm1)
Date: 2004-03-09 12:20

Message:
Logged In: YES 
user_id=652073

The bug is overflow (i.e. undefined behaviour), and so
the symptoms will vary according to the system.  Under
the conditions I was running, there was no output,
because Python terminated with a SIGFPE.  As I said, it
could as easily show up as erroneous results.

In THIS case, the failure occurs in the input processing,
and the purpose of prefixing it by print and int() is if
you try it on a system where it gives wrong answers.  If
you don't have access to a system where overflow can be
turned on or one that uses unusual arithmetic, you will not
be able to repeat it.  That is why I created a fix.

The reason that I didn't attach is is that attachment was
broken; I don't know why, and have neither the time nor the
inclination to debug a Web interface that I do not manage.
I can trivially send such things by Email, which is far
more reliable.  There doesn't appear to be a mechanism to
try again, so here is a context diff:

*** object.c.org        Wed Feb 19 03:21:21 2003
--- object.c    Fri Aug 15 15:22:50 2003
***************
*** 955,962 ****
  long
  _Py_HashDouble(double v)
  {
!       double intpart, fractpart;
!       int expo;
        long hipart;
        long x;         /* the final hash value */
        /* This is designed so that Python numbers of
different types
--- 955,962 ----
  long
  _Py_HashDouble(double v)
  {
!       double intpart, fractpart, z;
!       int expo, i, j;
        long hipart;
        long x;         /* the final hash value */
        /* This is designed so that Python numbers of
different types
***************
*** 975,981 ****
  #endif
        if (fractpart == 0.0) {
                /* This must return the same hash as an
equal int or long. */
!               if (intpart > LONG_MAX || -intpart >
LONG_MAX) {
                        /* Convert to long and use its hash.
*/
                        PyObject *plong;        /* converted
to Python long */
                        if (Py_IS_INFINITY(intpart))
--- 975,992 ----
  #endif
        if (fractpart == 0.0) {
                /* This must return the same hash as an
equal int or long. */
!               /* Remember that (double)LONG_MAX can round
either way. */
!               if (intpart > LONG_MIN/2 && intpart <
LONG_MAX/2)
!                       z = 0.0;
!               else {
!                       z = (intpart >= 0.0 ? intpart :
-intpart);
!                       for (i =
(sizeof(long)*CHAR_BIT-1)/16; i >= 0; --i) {
!                               x = LONG_MAX;
!                               for (j = 0; j < i; ++j) x
>>= 16;
!                               z -= ldexp(x&0xffff,16*i);
!                       }
!               }
!               if (z > 0.0) {
                        /* Convert to long and use its hash.
*/
                        PyObject *plong;        /* converted
to Python long */
                        if (Py_IS_INFINITY(intpart))


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

Comment By: Tim Peters (tim_one)
Date: 2004-02-17 00:22

Message:
Logged In: YES 
user_id=31435

Sorry, I can't make for this, so unassigned it.

To help the next person,

1. Please say something about what "the bug" is.  You show 4 
lines printing int(big_integer), but don't show any output.  In 
addition, the patch *appears* to be against _Py_HashDouble
(), but that function isn't involved in int() or in printing.

2. Please generate a context diff for patches, and attach the 
patch to the bug report instead of pasting it into the text 
box.  SourceForge destroys the intended line structure and 
indentation in text boxes, and this non-context diff patch is 
very hard to follow in this mangled form.

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

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