Wrong Judgement Regarding Compression Algorithm (ICPC 2017)

Issue :Wrong Judgement Regarding Compression Algorithm (ICPC 2017)

We have checked our code against an AC code of my friend on many randomly generated test files and checked the absolute error of 10^-6 and our code passes every file generated.

I was continuously getting WA on the solution which was first submitted 1 hour 53 minutes into the contest.Due to this we could not attempt further questions in-spite of having 1.5 hours remaining.

This seems a serious issue regarding ICPC selection procedure and appears to be a problem with many other contestants. So I would request Codechef to look into the matter seriously and get the results updated.

Submission Id (in case @admin wants it):16117665


Also this kind of a problem totally ruins the ranklist. Most of the cases people will fail to qualify for a regional just for this error. Things need to be sorted out.


@admin please look into the matter. The issue is quite serious. The submission of our team is provided above.


i wasted 2 hours getting WA on this question. Now, trusting the problemsetters checker code, I thought my solution was wrong. We would have qualified easily if this bug wasn’t there :frowning:


Should We have another regional qualification round, given these many factors: - Wrong Judgement of Compression Algorithm - Lag of Judgement on 2nd problem.

These are some serious issues which force team to change their strategy and let external factors control a programming contest.


Same issue faced by our team too. We were trying to find errors in our code but could not find any as there were bugs in the checker code.


For this input:


909709045 813851340

Your output:

Friend’s output:

Expected output:

You can verify that your friend’s code gives output within the expected error bound, but not your code. Hope that resolves your issue.


The solutions should be rejudged and ranklist should be updated accordingly…Why wait for the next time??


Our code (submission id: 16125742) gives the Expected output: 1819418087.764434 for the sample input mentioned above by the admin, still we got WA. Please rejudge the submissions. We got 3 penalties because of this issue.


For this question :correct formula ,used double,precision set to 10, still WA . GREATER (>=20)setprecision would have worked.
Similar case for problem #2 we got internal error two times. which forced us to change the strategy, these cases ruins the ranklist and bring teams moral down. At this level these aren’t just some random small glitches.


If we get WA due to the precision issue, we start to find out the error in our code. We run all the test cases we can think of to verify our code, but we won’t find the error because there’s no error. How are we supposed to know that it’s due to the precision issue?

Here is the major error in problem that could have been avoided:-

Problem statement says"Absolute error", this should have been written in bold text. It’s not a silly error.We are accustomed to “relative error”, so normally we could not have seen that. (It makes no sense to use
“Absolute error” in problem statement)


Moreover it was codechef’s compiler problem in idle environment of python it is giving exact output even with precision more than 0.000001 i think the submitted solutions should also be calculated in some other compiler before giving WA

There’s a difference between using cout<< setprecision(x) and cout<< fixed<< setprecision(x) [reference- http://codeforces.com/blog/entry/55604?#comment-393859 ].
SO people who dint use fixed would mostly have got a WA.

Similarly in case of printf since the problem states in the "Output section : Your answer will be considered correct if the absolute error is less than 10-6 " thus .6Lf would also give a WA.

@admin could the above reasons be why people are facing WA issues.


Even i faced the same problem.
If you use just double data type in C and print answer using %lf by default it gives precision upto 10^-6 but i still don’t know why it was showing wrong answer on my first 3 submission and when i changed %lf to %.8lf(i took precision upto 8 digits) it showed me AC so there was some problem with the precision.

for ex.
if the real answer is something like…
your desired answer gives you value like
and my answer is

so if i subtract your answer from my answer

1.6666670000000 - 1.6666666666667
= 0.000000333333

which equals to 3.33 * 10^-7 which is clearly less than 10^-6.
by using only %lf you can never get absolute error of more than 5 * 10^-7.

my user id is : acm17in2673(in case anyone wants to check my submissions)

Because of this problem 2 hours increased in my total time in rankings. It can make me ineligible to qualify for regionals as in that time some of my college mates solved it with higher precision. :frowning:
(I was 1st in my college after solving 2 questions and ended up at 3rd position after contest)


Our code gives same output as the expected output for sample input mentioned by admin above, still we got WA. @admin Please check. Team id: acm17in1024

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.

1 Like

The same problem occured with code of my team. We got three penalties just for precision and we wasted a lot of time trying to find our mistake.

in question number 3 and we got internal error due to which our team get penalty…

Exactly, the time wasted could have been used for the 4th and 5th problem


I checked my AC code against my own WA code and found no differences on all possible inputs (1-1e9,1-1e9) took a while to run but I still don’t know how and why it shows WA