[issue6387] floor division gives different result for int versus float.

Changes by R. David Murray : -- resolution: -> rejected stage: -> committed/rejected status: open -> closed ___ Python tracker ___ __

[issue6387] floor division gives different result for int versus float.

Tim Peters added the comment: Yup, -1 here too. For dyadic arithmetic operations (+ - * / % //) on mixed numeric types, Python's execution model coerces the operands to a common type before computation begins. Besides just being the way it's worked "forever" in Python, it's consistent and expl

[issue6387] floor division gives different result for int versus float.

Eric Smith added the comment: I agree with Mark: -1. Do you have any specific use cases where this has caused problems, or is this academic? Maybe you can get some support for this on python-ideas, but I suggest we close it in the meantime. -- ___

[issue6387] floor division gives different result for int versus float.

Mark Dickinson added the comment: This is definitely a feature request rather than a bug. As I understand it, you want to special-case floor division so that if the argument types are (int, float) or (float, int) then the result is computed exactly. Is that correct? Note that the result of t

[issue6387] floor division gives different result for int versus float.

Changes by R. David Murray : -- nosy: +eric.smith, marketdickinson priority: -> low ___ Python tracker ___ ___ Python-bugs-list mailin

[issue6387] floor division gives different result for int versus float.

David Jones added the comment: I do realise that. I still think the mathematically correct answer should be computed, since it can be. -- ___ Python tracker ___ ___

[issue6387] floor division gives different result for int versus float.

Tim Peters added the comment: Do you realize that 2**54-1 isn't exactly representable as a float? It requires 54 bits of precision, but the Python float format only has 53 bits available (on all popular boxes). >>> 2**54-1 18014398509481983L >>> float(_) # rounds to closest representable floa

[issue6387] floor division gives different result for int versus float.

New submission from David Jones : Consider: x//y != x//float(y) for some integer values of x and y. For example, x = 2**54-1, and y = 2: >>> x=2**54-1 >>> y=2 >>> x//y 9007199254740991L >>> x//float(y) 9007199254740992.0 >>> _==x//y False I have no idea whether this should actually be a bug or