Odd floor-division corner case

[mdickinson]

BPO	22198
Nosy	@tim-one, @rhettinger, @mdickinson, @abalkin, @stevendaprano, @encukou, @skrah, @eryksun
Files	issue22198.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2016-07-07.15:31:52.824>
created_at = <Date 2014-08-14.16:47:41.777>
labels = ['interpreter-core', 'type-bug']
title = 'Odd floor-division corner case'
updated_at = <Date 2016-07-07.15:31:52.822>
user = 'https://github.com/mdickinson'

bugs.python.org fields:

activity = <Date 2016-07-07.15:31:52.822>
actor = 'serhiy.storchaka'
assignee = 'none'
closed = True
closed_date = <Date 2016-07-07.15:31:52.824>
closer = 'serhiy.storchaka'
components = ['Interpreter Core']
creation = <Date 2014-08-14.16:47:41.777>
creator = 'mark.dickinson'
dependencies = []
files = ['36568']
hgrepos = []
issue_num = 22198
keywords = ['patch']
message_count = 20.0
messages = ['225305', '225309', '225313', '225314', '225315', '225340', '225359', '225360', '225365', '225386', '225401', '226541', '226542', '227307', '228865', '230958', '234068', '234069', '241088', '241342']
nosy_count = 10.0
nosy_names = ['tim.peters', 'rhettinger', 'mark.dickinson', 'belopolsky', 'casevh', 'Arfrever', 'steven.daprano', 'petr.viktorin', 'skrah', 'eryksun']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue22198'
versions = ['Python 2.7', 'Python 3.4', 'Python 3.5']

[mdickinson]

I'm not sure it's worth fixing this, but it seems worth recording:

>>> -0.5 // float('inf')
-1.0

I was expecting a value of -0.0, and while IEEE 754 doesn't cover the floor division operation, I'm reasonably confident that that's the value it would have recommended if it had. :-)

However, it's difficult to come up with a situation where the difference matters: there aren't any obvious invariants I can think of that are broken by this special case. So unless anyone thinks it should be changed, I'll settle for recording the oddity in this issue, and closing as won't fix after a short period.

[stevendaprano]

On Thu, Aug 14, 2014 at 04:47:41PM +0000, Mark Dickinson wrote:

I'm not sure it's worth fixing this, but it seems worth recording:

-0.5 // float('inf')
-1.0

I was expecting a value of -0.0, and while IEEE 754 doesn't cover
the floor division operation, I'm reasonably confident that that's the
value it would have recommended if it had. :-)

Hmmm. I'm not so sure. -0.5 // something_really_big gives -1:

py> -0.5//1e200
-1.0

Consider something_really_big as it gets bigger and bigger and
approaches infinity, if we *informally* take the limit -> inf I think it
makes sense for it to return -1. Another way of looking at it is that
-0.5/inf returns a negative infinitesimal quantity, and then taking the
floor returns -1. So I think the current behaviour is "correct", for
some definition of correct.

The alternative is a discontinuity, where -0.5//x = -1 for all finite
but huge x and then suddenly 0 when x overflows to infinity. That's
probably a bad idea.

[tim-one]

I'm OK with -1, but I don't get that or -0.0 on 32-bit Windows Py 3.4.1:

Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:38:22) [MSC v.1600 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> -0.5 // float('inf')
nan

So maybe NaN is the best answer ;-)

In favor of -1.0: that _is_ the limit of the mathematical floor(-0.5 / x) as x approaches +infinity.

In favor of -0.0: it "should be" mathematically that floor_division(x/y) = floor(x / y), and floor(-0.5 / inf) = floor(-0.0) = ... well, not -0.0! floor() in Py3 is defined to return an integer, and there is no -0 integer:

>>> floor(-0.0)
0

That's +0. So I see no justification at all for -0.0 in Py3. -1 seems the best that can be done. The NaN I actually get doesn't make sense.

[mdickinson]

Steven: there's a set of (unwritten) rules for how the IEEE 754 operations work. (I think they actually were articulated explicitly in some of the 754r drafts, but didn't make it into the final version.) One of them is that ideally, a floating-point operations works as though the corresponding mathematical operation were performed exactly on the inputs (considered as real numbers), followed by a rounding step that takes the resulting real number and rounds it to the nearest floating-point number. This is how essentially all the operations prescribed in IEEE 754 behave, with a greater or lesser amount of hand-waving when it comes to specifying results for special cases like infinities and nans. In this case, the underlying mathematical operation is x, y -> floor(x / y). The only tricky point is the extension to infinity, but we've got the existing behaviour of regular division to guide us there - the result of dividing a finite value by an infinity is an appropriately signed zero. So there's really not a lot of room for manoeuvre in an IEEE 754-like operation.

The alternative is a discontinuity, where -0.5//x = -1 for all finite
but huge x and then suddenly 0 when x overflows to infinity. That's
probably a bad idea.

Shrug: the underlying mathematical operation is discontinuous; I really don't see a problem here. In any case, if you're worried about discontinuities, what about the one that occurs between positive values and negative values of x in the current implementation (a jump from 0 to -1)? Continuity takes second place to correctness here.

[mdickinson]

[Tim]
>>> -0.5 // float('inf')
nan

Urk! I wonder what's going on there. I think I like that answer even less than -1.0.

IEEE 754's floor does indeed take -0.0 to -0.0.

[rhettinger]

ideally, a floating-point operations works as though the
corresponding mathematical operation were performed exactly
on the inputs (considered as real numbers), followed by a rounding
step that takes the resulting real number and rounds it to the
nearest floating-point number.

FWIW, the Decimal Arithmetic Specification was created around the same principle. Accordingly, it gets the answer that Mark expected:

  >>> from decimal import Decimal
  >>> Decimal('-0.5') // Decimal('Inf')
  Decimal('-0')

[skrah]

I think the intention of the standard is pretty much as Mark
said in msg225314. The fact that decimal behaves that way is
another indicator, since Cowlishaw really tried to mirror the
2008 standard as closely as possible.

[tim-one]

To be clear, I agree -0.0 is "the correct" answer, and -1.0 is at best defensible via a mostly-inappropriate limit argument. But in Py3 floor division of floats returns an integer, and there is no integer -0. Nor, God willing, will there ever be ;-)

Looks to me like what (Py3's, at least) floatobject.c's floor_divmod() returns (the source of float floor division's result) when the 2nd argument is infinite is largely an accident, depending on what the platform C fmod() and floor() happen to return. So it would require special-casing an infinite denominator in that function to force any specific cross-platform result.

[eryksun]

decimal.Decimal 'floor division' is integer division that truncates toward 0 (see 9.4.2).

    >>> Decimal('-0.5').__floor__()
    -1
    >>> Decimal('-0.5').__floordiv__(1)
   Decimal('-0')

Numpy 1.8.1:

    >>> np.float32(-0.5) // 1
    -1.0
    >>> np.float32(-0.5) // float('inf')
    -0.0

    >>> np.array([-0.5]) // 1
    array([-1.])
    >>> np.array([-0.5]) // float('inf')
    array([-0.])

[mdickinson]

But in Py3 floor division of floats returns an integer.

Not in my version!

Python 3.4.1 (default, May 21 2014, 01:39:38) 
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> -3.0 // 5.0
-1.0

Maybe I'm using the wrong time machine.

[tim-one]

Sorry, Mark - I took a true thing and careleslly turned it into a false thing ;-)

It's math.floor(a_float) that returns an int in Py3, not floor division of floats. So, yup, no real problem with returning -0.0 after all; it's just that it can't be _explained_ via

x // y means math.floor(x / y)

is Py3 for float x and y, since the latter returns an int bur the former a float.

But looks like it can be "explained" via

x // y means divmod(x, y)[0]

[encukou]

I tried my hand at writing a patch. I hope it is helpful.

The message of the 2001 commit that introduces this says that "there's no platform-independent way to write a test case for this". I assume with @support.requires_IEEE_754 that is no longer true (at least for non-exotic platforms), or was there another issue?

I noticed there is no test suite for float floordiv, so I attempted writing a fuller one, but when I saw that
>>> float('inf') // 1.0
nan
I decided to keep my first CPython patch small and focused, so I can learn the ropes. I'll file more issues later.