Probably precision error somewhere especially in ceil. Why not solve the problem without any floating point calculations?

If you wish to find out where the error lies, you may do the following: Check out some AC code, have both codes work on the same data in parallel, after every calculation — check for any differences in results from the two, and if found, print the data on which the calculation was done, alongside some identifier string to know which operation caused the same. Seeing the output on your result should then let you know of the anomaly.

Or, you could also generate tests on your own using a random test generator (with appropriate changes to input) and compare your output against some AC code output on your own system and print out the test case where there's an anomaly.

Google "How to test your solution in Competitive Programming, on Linux?" and you should find a very useful video by Errichto on stress-testing your program on your system. (Sorry, I'm unsure of the policy regarding posting foreign links therefore I can't share the video link here)

Lastly, floating point comparisons do tend to be somewhat unpredictable at times therefore whenever possible, you should try to avoid them. You can browse for some articles on the imperfect nature of floating point comparisons for more insights on the same.

Happy Learning! :)

Try to use as few floating-point operations as possible — they often result in precision errors.

• For example, if there are no overflow problems (and there aren't here, afaik), you can compare 2 fractions $$$\frac{a}{b}, \frac{c}{d}$$$ as $$$a \cdot d$$$ vs. $$$c \cdot b$$$.

• Also, instead of ceil((double)a / b), just use floor((a + b - 1) / b), which is just (a + b - 1) / b in C++ (if a and/or b aren't a real type, at least).