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
№ | Пользователь | Рейтинг |
---|---|---|
1 | ecnerwala | 3648 |
2 | Benq | 3580 |
3 | orzdevinwang | 3570 |
4 | cnnfls_csy | 3569 |
5 | Geothermal | 3568 |
6 | tourist | 3565 |
7 | maroonrk | 3530 |
8 | Radewoosh | 3520 |
9 | Um_nik | 3481 |
10 | jiangly | 3467 |
Страны | Города | Организации | Всё → |
№ | Пользователь | Вклад |
---|---|---|
1 | maomao90 | 174 |
2 | awoo | 164 |
2 | adamant | 164 |
4 | TheScrasse | 159 |
4 | nor | 159 |
6 | maroonrk | 156 |
7 | -is-this-fft- | 150 |
8 | SecondThread | 147 |
9 | orz | 146 |
10 | pajenegod | 145 |
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
Название |
---|
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
k
to the nearest double at an intermediate step, but roundingn
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 fork / 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.