[issue22198] Odd floor-division corner case

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Mark Dickinson]

Mark Dickinson added the comment:

Thanks for the ping, and sorry for forgetting about this.

I'm -1 on applying this patch.  I agree that floor division has some corner 
case issues (of which this is only one).  But there's no clear agreement on 
what the right answer is, and I don't think making a tiny change to one corner 
case is worth it in terms of code churn.  And making several such tiny changes 
over the course of different Python releases is something we'd definitely want 
to avoid.

Ideally, there'd be a once-and-for-all agreement on exactly what should happen 
with *all* the corner cases; we'd fix the code to implement exactly that, and 
then we could forget about it.  But without a standard to guide us, I don't 
think that's going to happen.

So my vote is to close as wont fix.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Mark Dickinson]

Changes by Mark Dickinson dicki...@gmail.com:


--
assignee: mark.dickinson - 

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Petr Viktorin]

Petr Viktorin added the comment:

ping?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Petr Viktorin]

Petr Viktorin added the comment:

ping, is there anything I can do to help push the patch forward?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Mark Dickinson]

Mark Dickinson added the comment:

The patch is fine; I just need to find time to look at it properly.  That might 
take a week or two.  Sorry for the delay.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Petr Viktorin]

Petr Viktorin added the comment:

ping, could someone please review the patch?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Petr Viktorin]

Petr Viktorin added the comment:

Apologies for the delay; I missed/did not get a notification.

Alexander, I don't disagree, but I'd like my first patch to Python to not be a 
refactoring. As I said, I'd like to keep this patch focused. After that I'd 
like to provide tests the rest of float_divmod; and then perhaps use an 
entirely different implementation.

If that's not a good course of action, and you suggest a different one or just 
tell me to improve everything at once, I will certainly try. But, I think that 
this patch is an improvement, and that it does fix this bug.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Alexander Belopolsky]

Changes by Alexander Belopolsky alexander.belopol...@gmail.com:


--
nosy: +belopolsky

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

I wonder if it would make sense to rewrite float_divmod using the newer 
POSIX/C99 remquo function.  I believe it is designed to compute the exact value 
of round(x/y), but getting floor instead should not be hard.  Its behavior on 
special values is fully specified. 



From the Linux man-page (I believe POSIX/C99 only guarantees 3 bits in quo):

NAME
 remquo -- floating-point remainder and quotient function

SYNOPSIS
 #include math.h

 double
 remquo(double x, double y, int *quo);

 long double
 remquol(long double x, long double y, int *quo);

 float
 remquof(float x, float y, int *quo);

DESCRIPTION
 The remquo() functions compute the value r such that r = x - n*y, where n 
is
 the integer nearest the exact value of x/y.

 If there are two integers closest to x/y, n shall be the even one. If r is
 zero, it is given the same sign as x.  This is the same value that is
 returned by the remainder() function.  remquo() also calculates the lower
 seven bits of the integral quotient x/y, and gives that value the same sign
 as x/y. It stores this signed value in the object pointed to by quo.

SPECIAL VALUES
 remquo(x, y, quo) returns a NaN and raises the invalid floating-point
 exception if x is infinite or y is 0.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:


--
nosy: +Arfrever

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Case Van Horsen]

Changes by Case Van Horsen cas...@gmail.com:


--
nosy: +casevh

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Petr Viktorin]

Petr Viktorin added the comment:

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.

--
keywords: +patch
nosy: +encukou
Added file: http://bugs.python.org/file36568/issue22198.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Petr Viktorin]

Petr Viktorin added the comment:

Note: I signed the contributor agreement form recently, I should have a * soon.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Mark Dickinson]

Mark Dickinson added the comment:

 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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Tim Peters]

Tim Peters added the comment:

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]

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Stefan Krah]

Stefan Krah added the comment:

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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Tim Peters]

Tim Peters added the comment:

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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[eryksun]

eryksun added the comment:

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.])

--
nosy: +eryksun

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Odd floor-division corner case

[Mark Lawrence]

From http://bugs.python.org/issue22198

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

What should it be?

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Odd floor-division corner case

[Ian Kelly]

On Thu, Aug 14, 2014 at 11:31 AM, Mark Lawrence breamore...@yahoo.co.uk wrote:
 From http://bugs.python.org/issue22198

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

Looks like the result is the same for any negative dividend.

 What should it be?

It's surprising, but I think it's correct. A negative infinitesimal
would be less than 0, so its floor should be -1, not 0.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue22198] Odd floor-division corner case

[Mark Dickinson]

New submission from Mark Dickinson:

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.

--
assignee: mark.dickinson
components: Interpreter Core
messages: 225305
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: Odd floor-division corner case
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Mark Dickinson]

Changes by Mark Dickinson dicki...@gmail.com:


--
nosy: +skrah

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Mark Dickinson]

Changes by Mark Dickinson dicki...@gmail.com:


--
nosy: +tim.peters

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Steven D'Aprano]

Steven D'Aprano added the comment:

On Thu, Aug 14, 2014 at 04:47:41PM +, 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.

--
nosy: +steven.daprano

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Tim Peters]

Tim Peters added the comment:

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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Mark Dickinson]

Mark Dickinson added the comment:

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 signe
 d 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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Mark Dickinson]

Mark Dickinson added the comment:

[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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22198] Odd floor-division corner case

[Raymond Hettinger]

Raymond Hettinger added the comment:

 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')

--
nosy: +rhettinger

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com