### Hafiz_'s blog

By Hafiz_, 7 weeks ago,

I ran this code on codeblocks and it gives 8(correct) for input=>612220032 18 and codeforces shows 7 for it. Why?

• -12

 » 7 weeks ago, # |   0 try submitting in GNU G++17 9.2.0 (64 bit, msys 2)
•  » » 7 weeks ago, # ^ |   0 Already tried -_-
•  » » » 7 weeks ago, # ^ | ← Rev. 2 →   0 then you shouldve noticed that its failing on a different testcase which gave WA on my machine too
 » 7 weeks ago, # |   0 108420664ll -> long double. I really don't know how and why it is. Never even tried to learn really deep in floating point math because almost always there is way with absolutely understandable integer math.
 » 7 weeks ago, # | ← Rev. 2 →   0 It is a precision error. If you add "two ifs" to correct the result of the division between the logs, we will be accepted. https://codeforces.com/contest/1485/submission/108425917What is strangest for me are different machines computing the rounding of floating pointers in different ways.Either way, we depend on luck when doing operations that are very sensitive to rounding floating pointers (as in this case, that $\frac{a}{b} = 3.9999999$ is completely different from $\frac{a}{b} = 4$).
•  » » 7 weeks ago, # ^ | ← Rev. 4 →   +3 What is strangest for me are different machines computing the rounding of floating pointers in different ways. The explanation is that floating point numbers work differently in 32 bit vs 64 bit. I have a blog about it . Explanation to weird/strange floating point behaviour in C++In short, back when 32 bit used to be a thing, the processor didn't directly support float and double calculations. All it supported was (80 bit) long doubles. On top of this, someone had the genius idea of getting extra precision by keeping floats and doubles as long doubles up to the point where they are stored in memory.The issue is that you can't control where the conversion happens. This leads to weird behaviour like this.Good thing is that if you use 64 bit g++, then all of these problems are gone. Floats will act like floats and doubles will act like doubles. No more hidden excess precision. I ran this code on codeblocks and it gives 8(correct) for input=>612220032 18 and codeforces shows 7 for it. Why? My guess is that you locally compiled with 64 bit, but submitted on cf with 32 bit.