Nagadon's blog

By Nagadon, history, 3 years ago, In English

On the third sample input, I'm getting output 1 in my IDE. However, when I submit my solution, I get 2. https://codeforces.com/problemset/problem/1036/A

Why does this happen?

Code: https://codeforces.com/contest/1036/submission/108317612

  • Vote: I like it
  • -6
  • Vote: I do not like it

»
3 years ago, # |
  Vote: I like it +19 Vote: I do not like it

Huge floating-point numbers are very imprecise (and hardware-dependent?), don't use them. The correct way to take $$$\left\lceil {k \over n} \right\rceil$$$ is (k + n - 1) / n, where the division is in integers.

  • »
    »
    3 years ago, # ^ |
      Vote: I like it +23 Vote: I do not like it

    This is true as far as it goes, but even knowing what I do about floating-point and numerical analysis, this particular wrong answer comes as a surprise to me. (Though of course I would expect other test cases on this problem to cause precision-related wrong answers from this code.)

    The two numbers in the failing input "should" round to the same nearest double, which is exactly $$$10^{18}$$$. Even if excess precision is used, the division should not yield a result greater than $$$1$$$. The only explanation I can think of is that g++ may be rounding k to the nearest double at an intermediate step, but rounding n directly to the nearest long double and performing (excess-precision) long double division, which seems shockingly inconsistent if true. (It continues to do this even for k / double(n), so the intermediate *1.0 is not causing the problem.) Either way, this is another good reminder that 32-bit g++ really demands its users fear the floating-point boogeyman.