Hafiz_'s blog

Why this solution is wrong while codeblocks gives correct ans?
By Hafiz_, 2 months ago, In English

Problem: link

My submission: link

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

 
 
 
 
  • Vote: I like it
  • -12
  • Vote: I do not like it

Comments Comments (6)
»
2 months ago, # |
  Vote: I like it 0 Vote: I do not like it

try submitting in GNU G++17 9.2.0 (64 bit, msys 2)

→ Reply
»
2 months ago, # |
  Vote: I like it 0 Vote: I do not like it

108420664

ll -> 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.

→ Reply
»
2 months ago, # |
← Rev. 2   Vote: I like it 0 Vote: I do not like it

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/108425917

What 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$$$).

→ Reply
  • »
    »
    2 months ago, # ^ |
    ← Rev. 4   Vote: I like it +3 Vote: I do not like it

    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.

    → Reply