Hello, Codeforces.
I've sent different submissions with same code with different compilers on problem Burenka Plays with Fractions from last round and got different results.
WA 13 with:
GNU G++20 11.2.0 (64 bit, winlibs) → 168824855
GNU G++17 9.2.0 (64 bit, msys 2) → 168878170
ACC with:
GNU G++17 7.3.0 → 168877257
GNU G++14 6.4.0 → 168878015
I would've gotten a higher rate if this strange thing hadn't happened.
Strange that I get wrong answer with modern compilers and accepted with old compilers !
Can anyone explain that ?!
Likely, your code had an usage of what is known as Undefined behaviour. If this is the case, then we are unable to know, let alone guarantee, if your code works as expected in every compilation environment. You need to be cautious of these situations!
It is never a good idea to directly compare floating-point numbers using the equality comparison operator.
As per why the results were different, the C++ standard isn't very stringent about what the extra digits should be after the minimum precision (about 16 digits for double), i.e., they are implementation-defined. The test-case on which your code gave the wrong answer (expected output : 2), your code's output was 0, because double may not have been precise enough to differentiate between 1000000000/999999999 and 999999999/999999998 in one compiler and was in the other.
You shouldn't compare floating-point values using the
==operator.I resubmit your WA 13 C++17 (64) solution and get AC by turning on excess precision, but I wouldn't recommend relying on this method to get AC though.