Someone Please explain the difference between these two solutions for Compression Algorithm

acm-icpc

#9

@admin pls look into the matter…hoping for a resolution or an explanation of what went wrong!!!


#10

@admin please do something for this


#11

Even I used round off function in python and got wrong answer even for precision upto 7 places because it was rounding off. This must be looked into @admin


#12

@d_skyhawk In your case your formula to calculate it is wrong review it


#13

Can anyone tell the motivation behind this formula?


#14

I understand the pain in this, but given ~600 teams solved the Q, I don’t think any action will be taken at all.

It comes down to prior experience with double type answers and precision. I remember in one CF contest when a solution by Sumeet.Varma failed with 0.00001 error, which was totally because of him using Java. (same code in C++ passed)

Having said that, I don’t think it was nice of them to give a Q with such brutal “absolute error” rather than “relative error”. In many ways, I liked last years problem set better :confused: But whats done is done!


#15

they can at least give some partial credits to other solutions with the relative error of 0.0000001


#16

@d_skyhawk
It might be because you are using “ios_base::sync_with_stdio(false)”. It disables the synchronization between the C and C++ standard streams. By default all the standard streams are syncronized, and after that you have used cin as well as printf, that might be the error in this case.
Bdw Im not sure about this. This might be the case!!


#17

This years questions were not testing the skills but the knowledge of the language a person use, getting a WA just because of precision difference is unjust. Ranklist would have been a total stranger to the current Ranklist.


#18

@ak_1andonly I do agree, just spent hours debugging code rather than solving problems.


#19

Ya this icpc tested our skills in programming language and math and not algorithms how does make sure the right teams are selected to regionals ,this needs to improve in forthcoming years and getting wa for not typing cout<<fixed;was annoying and losing a place in regionals because of that is even more annoying to say the truth this contest might have discouraged many debues in icpc even icpcsc @admin


#20

Can someone please explain me how you derived that formula? Even after spending so much of time I couldn’t figure it out? @d_skyhawk @vijju123 @swetankmodi @rishi_07


#21

Our code gives the correct output for the above mentioned test case and even with all other test cases. Our submission with id, 16113398, gives WA during the contest. @admin, Please look into this issue. PS: While calculating the absolute error of our answer, consider the full answer with more than six places after the decimal as the expected answer and not the truncated one.


#22

@swetankmodi please provide solution for compression algorithm.


#23

I am not completely sure when we go this deep into decimals dear, I am sorry for that :(. But the reason you got WA is realted to absoute value being used, being rutheless ({10}^{-6} doesnt make sense to me since correct algo gives very near answers). I also feel that relative error should ahd been considered.


#24

No, there’s either an issue with the judge (a bug) or it’s a feature (they’re checking absolute error and not relative error)


#25

They intentionally checked absolute error, and trust me things get dicey when you aim for this high precision. Usually people tolerate an absolute error of 0.01, or relative error of {10}^{-6}, which make sense to me. Absolute error of {10}^{-6} was really, well, rutheless.


#26

Yeah i said it might be a bug or even a feature. I’ve experienced this 5-6 times so I knew they wanted me to use python xD or play with c++ mechanics to get the correct result (exact)


#27

@swetankmodi but we used setprecision(10) still WA.


#28

@rishi_07 I used setprecision 18 Still WA.