This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: [Minor] bug in integer true division algorithm
Type: behavior Stage: resolved
Components: Interpreter Core Versions: Python 3.6, Python 3.5, Python 2.7
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: mark.dickinson, python-dev, serhiy.storchaka, vstinner
Priority: low Keywords:

Created on 2015-11-12 08:44 by mark.dickinson, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (5)
msg254523 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2015-11-12 08:44
There's a harmless but annoying (for code readers) bug in the code for true division of (long) integers.  In `long_true_divide` in `Objects/longobject.c`, we have the following code for manipulating the bits of a 55- or 56-bit long to get something that will be exactly representable as a float:

    /* The number of extra bits that have to be rounded away. */
    extra_bits = MAX(x_bits, DBL_MIN_EXP - shift) - DBL_MANT_DIG;
    assert(extra_bits == 2 || extra_bits == 3);

    /* Round by directly modifying the low digit of x. */
    mask = (digit)1 << (extra_bits - 1);
    low = x->ob_digit[0] | inexact;
    if (low & mask && low & (3*mask-1))
        low += mask;
    x->ob_digit[0] = low & ~(mask-1U);

    /* Convert x to a double dx; the conversion is exact. */

The last code line above is supposed to be masking out all the bits that we don't want to keep. Instead, it's masking out all but one of those bits.  The line

    x->ob_digit[0] = low & ~(mask-1U);

should be replaced with

    x->ob_digit[0] = low & ~(2*mask-1U);

As it stands, the comment about the conversion to double being exact is false. (I've verified this by converting x both to a 64-bit unsigned integer and to a double and checking that the integer and double don't always match in value; with the fix above, they do.)

I don't *think* this bug actually affects the output on any platform whose arithmetic and ldexp functions do correct rounding with round-ties-to-even: the extra bit will always get rounded away (in the correct direction) by either the conversion to float (for the non-subnormal case) or by the ldexp operation (for the subnormal case). Still, the bug makes the code a bit more susceptible to platform arithmetic quirks.
msg254531 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-11-12 13:34
msg273283 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-08-21 09:23
New changeset b9e12ca6fdb6 by Mark Dickinson in branch 'default':
Issue #25604: Fix minor bug in integer true division, which could
msg273287 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-08-21 09:59
New changeset 370bbeba21b3 by Mark Dickinson in branch '2.7':
Issue #25604: Fix bug in integer true division that could have resulted in off-by-one-ulp results in unusual cases.
msg273288 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2016-08-21 10:01
Fixed for 2.7 and 3.6. I don't think it's worth backporting the fix to 3.5 without evidence of actual incorrect results arising from this bug.
Date User Action Args
2022-04-11 14:58:23adminsetgithub: 69790
2016-08-21 10:01:24mark.dickinsonsetstatus: open -> closed
resolution: fixed
messages: + msg273288

stage: resolved
2016-08-21 09:59:57python-devsetmessages: + msg273287
2016-08-21 09:23:43python-devsetnosy: + python-dev
messages: + msg273283
2015-11-12 13:34:16serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg254531
2015-11-12 08:54:22vstinnersetnosy: + vstinner
2015-11-12 08:44:45mark.dickinsoncreate