0

According to pep238 the semantics of floor division is

a // b == floor(a / b)

However this fails with floats:

>>> 1.99965 // 0.0199965
99.0
>>> math.floor(1.99965 / 0.0199965)
100

Why is this so? Is this behavior documented? Note that

1.99965 / 0.0199965 is 100.0
Mihai Andrei
  • 1,024
  • 8
  • 11
  • 1
    `1.99965` and `0.0199965` are not precisely `1.99965` and `0.0199965`, because the denominator of each one of them is not a power of 2. – goodvibration Jul 09 '20 at 13:04
  • @goodvibration I agree that the numbers are not represent-able as floats. However their close representations do indeed divide to precisely 100.0 More verbose : 1.99964999999999992752464095246978104114532470703125000000000000 / 0.01999650000000000038546943414985435083508491516113281250000000 == 100.000000000000000000000000 – Mihai Andrei Jul 09 '20 at 13:15
  • So what? Each one of the is represented using a different value, and the result of the division is not equal to 100. – goodvibration Jul 09 '20 at 13:19
  • I'm trying to understand your point. But I am still confused by the fact that this division when performed as iee floats results in precisely 100.0 . Thus i expected // to floor this like math.floor does – Mihai Andrei Jul 09 '20 at 13:22
  • 2
    It's not precisely 100, otherwise floor'ing it wouldn't have given you 99! – goodvibration Jul 09 '20 at 13:23
  • Please try this in a python console math.floor(1.99965 / 0.0199965). I have chosen this example so that the division is exact in iee floats – Mihai Andrei Jul 09 '20 at 13:28
  • Is it different that what you wrote in your question??? – goodvibration Jul 09 '20 at 13:33
  • Yes, it's documented. See https://docs.python.org/3/reference/expressions.html#id18 – Mark Dickinson Jul 09 '20 at 15:45
  • Does this answer your question? [rounding errors in Python floor division](https://stackoverflow.com/questions/38588815/rounding-errors-in-python-floor-division) – Mark Dickinson Jul 09 '20 at 15:47
  • 1
    @MihaiAndrei: The division is *not* exact in IEEE 754 floating-point - the exact quotient is not 100.0. Here it is on Wolfram alpha, with values copy-pasted directly from your comment: https://www.wolframalpha.com/input/?i=1.99964999999999992752464095246978104114532470703125000000000000+%2F+0.01999650000000000038546943414985435083508491516113281250000000 – Mark Dickinson Jul 09 '20 at 16:11
  • 3
    To spell it out, 1.99964999999999992752464095246978104114532470703125000000000000 divided by 0.01999650000000000038546943414985435083508491516113281250000000 is the number shown in Mark Dickinson’s Wolfram Alpha link, about 99.999999999999994447913261695014032345. That is the **real number** quotient. Therefore, applying `//` to them should return 99. When you divide them in floating-point, that real number quotient is rounded to a **floating-point** result. The nearest value representable in floating-point is 100, so you get that. The floating-point result is **not** the real-number quotient. – Eric Postpischil Jul 09 '20 at 19:35
  • To echo @EricPostpischil good comment: `1.99965 // 0.0199965` is a floored division. `1.99965 / 0.0199965` is rounded division. The whole number portion of their quotients should not be expected to be the same. – chux - Reinstate Monica Jul 09 '20 at 19:51
  • @MarkDickinson EricPostpischil Thanks for clearly exposing my bad assumptions. If you make the comment(s) in an answer I'll gladly accept it. – Mihai Andrei Sep 02 '20 at 13:56

0 Answers0