[issue25129] suboptimal floating-point floor division

2015-09-16 Thread Mark Dickinson
Mark Dickinson added the comment: > What is the rounding mode used by true division, by the way? Probably not what you were asking, but with respect to true division of integers (int / int -> float), we always use round-half-to-even. Any deviation from that (non-IEEE 754 platforms excepted) i

[issue25129] suboptimal floating-point floor division

2015-09-16 Thread STINNER Victor
STINNER Victor added the comment: """ The root of the issue is that >>> Fraction(78*6e-8) != Fraction(78*6, 10**8) True >>> Fraction(6e-8) != Fraction(6, 10**8) True """ It's not an issue, it's just a fact: floating point rounding is annoying and very few people understand it :-) --

[issue25129] suboptimal floating-point floor division

2015-09-16 Thread Antoine Pitrou
Antoine Pitrou added the comment: I have no problem with closing. Admittedly, I opened this issue mostly to get a witty and enlightening response :-) -- ___ Python tracker ___ _

[issue25129] suboptimal floating-point floor division

2015-09-16 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: >>> from fractions import Fraction >>> Fraction(78*6e-8) / Fraction(6e-8) Fraction(353610802237278976, 4533471823554859) >>> Fraction(78*6e-8) // Fraction(6e-8) 77 >>> float(Fraction(78*6e-8) / Fraction(6e-8)) 78.0 >>> Fraction(78*6e-8) / Fraction(6e-8) - 78 Fr

[issue25129] suboptimal floating-point floor division

2015-09-16 Thread Mark Dickinson
Mark Dickinson added the comment: I agree with Tim that this is the correct behaviour. Antoine: okay to close? Or should we leave it open for the doc fix that Tim noticed? -- ___ Python tracker _

[issue25129] suboptimal floating-point floor division

2015-09-15 Thread Tim Peters
Tim Peters added the comment: BTW, I find this very hard to understand: "it’s possible for x//y to be one larger than" ... This footnote was written long before "//" was defined for floats. IIRC, the original version must have said something like: "it's possible for floor(x/y) to be one larg

[issue25129] suboptimal floating-point floor division

2015-09-15 Thread Antoine Pitrou
Antoine Pitrou added the comment: Hum, I see. What is the rounding mode used by true division, by the way? -- ___ Python tracker ___ _

[issue25129] suboptimal floating-point floor division

2015-09-15 Thread Tim Peters
Tim Peters added the comment: > What is the rounding mode used by true division, For binary floats? It inherits whatever the platform C's x/y double division uses. Should be nearest/even on "almost all" platforms now, unless the user fiddles with their FPU's rounding flags. --

[issue25129] suboptimal floating-point floor division

2015-09-15 Thread STINNER Victor
STINNER Victor added the comment: IEEE 754 uses the ROUND_HALF_EVEN rounding mode by default: https://en.wikipedia.org/wiki/Rounding#Round_half_to_even That's why round() uses the same rounding mode. I discovered recently while working on the datetime module :-) (issue #23517) -- nosy:

[issue25129] suboptimal floating-point floor division

2015-09-15 Thread Tim Peters
Tim Peters added the comment: Stare at footnote 2 for the Reference Manual's "Binary arithmetic operations" section: """ [2] If x is very close to an exact integer multiple of y, it’s possible for x//y to be one larger than (x-x%y)//y due to rounding. In such cases, Python returns the latter

[issue25129] suboptimal floating-point floor division

2015-09-15 Thread Antoine Pitrou
New submission from Antoine Pitrou: >>> (78*6e-8) / 6e-8 78.0 >>> (78*6e-8) // 6e-8 77.0 Note this doesn't make divmod() wrong: >>> q, r = divmod(78*6e-8, 6e-8) >>> q, r (77.0, 5.965e-08) >>> r < 6e-8 True >>> q * 6e-8 + r == 78*6e-8 True But, still, it is somewhat of an oddity to