On the third sample input, I'm getting output 1 in my IDE. However, when I submit my solution, I get 2. https://codeforces.me/problemset/problem/1036/A
Why does this happen?
Code: https://codeforces.me/contest/1036/submission/108317612
| # | User | Rating |
|---|---|---|
| 1 | Benq | 3676 |
| 2 | Kevin114514 | 3659 |
| 3 | jiangly | 3640 |
| 4 | turmax | 3450 |
| 5 | tourist | 3382 |
| 6 | strapple | 3360 |
| 7 | Um_nik | 3354 |
| 8 | squareOf105 | 3348 |
| 9 | maroonrk | 3312 |
| 10 | idontwannadothis…e | 3191 |
| # | User | Contrib. |
|---|---|---|
| 1 | Qingyu | 155 |
| 2 | nik_exists | 151 |
| 3 | maspy | 149 |
| 4 | AmShZ | 145 |
| 5 | Um_nik | 143 |
| 6 | Errichto | 139 |
| 7 | BledDest | 136 |
| 8 | adamant | 134 |
| 9 | maroonrk | 132 |
| 10 | cry | 130 |
On the third sample input, I'm getting output 1 in my IDE. However, when I submit my solution, I get 2. https://codeforces.me/problemset/problem/1036/A
Why does this happen?
Code: https://codeforces.me/contest/1036/submission/108317612
| Name |
|---|



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.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
kto the nearest double at an intermediate step, but roundingndirectly to the nearest long double and performing (excess-precision) long double division, which seems shockingly inconsistent if true. (It continues to do this even fork / double(n), so the intermediate*1.0is not causing the problem.) Either way, this is another good reminder that 32-bit g++ really demands its users fear the floating-point boogeyman.