# UEM KOLKATA. Strange case

Problem

WA solution

AC solution

where is this wrong ?

Same here.
I also had the same logic but it gave me WA everytime!!!

it gives WA for all solutions in python inspite of correct here,can anybody explain why?

https://www.codechef.com/viewsolution/10842050

Yeah, it’s very strange! I also gave the same solution in C++. And every time it gave WA. At last my partner tried it in JAVA and it worked! Probably, the contest was a bit language biased.

same problem faced…

Exactly faced the same problem.Its very sad and frustrating,when you submit with full confidence and get WA,and after viewing same kind of AC solutions, frustration increases more.Really, time-wasting. Codechef must take some action to prevent such kind of fuss.@admin @dpraveen

yup… faced the same problem…
Indeed its a contest for high school students…
it’s not meant for computer science students at all…
That too… somany mistakes in framing the problem statements exactly…
fedup with this…
And waste of time for 2 hrs unnecessarily…

(-1,-5) did not even satisfy the radius 5. Terrible competition.

Somebody please explain why this happened.

It is so strange.

What is wrong in this solution?

1 Like

your solution prints available or non available after it encounters each pair of co=ordinates. The problem statement asked to check for availability from a set of co-ordinates.

1 Like

I faced the same problem in java, same logic but only got WA

The reason is overflow happens in int while it does not in long long int. As the value of x and y are in the range of 10^4 x^2=10^8 which does not fit in int but does in long long . I believe the test cases have been given keeping the values of x and y and probably k as int or long hence the solution with int passed while the one with long long did not .
However this is just my assumption and there could be some other reason also.
Upvote and accept my answer if you find it to be correct.

1 Like

yeah… u r ryt… but long int is enough for that which could hold upto 10^9 @sdssudhu

I did it with the data type “long int” which is enough… but still got WA verdict… so, apparently what you said is not the reason behind so many wrong verdicts though the solutions are correct… @sdssudhu

General mistakes in this types of questions are:

1. **Using wrong data type** , for instance here Xi and Yi lies in [ -104 , 104 ]. It is quite obvious that Xi2 and Yi2 will lie in [ 0 , (104)2 ]   i.e. [ 0 , (10)8 ]   now this value can't be hold in an int datatype hence is to be stored in **long int** or **long long int** .
2. **Wrong output format** , since codechef only gives WA or AC for a compiled solution ( neglect runtime error ) , users often mistake wrong output format with WA. for instance, here in this question out was supposed to be print in one line for each test case regardless of the number of cars but of the availability of the cars. but some of users were printing availability for every cars.
Hope it helps !

Thanks

EDIT 1:
Just make Xi and Yi of type int and you will get AC.

Reason:
After observing the pattern of wrong answer I realised that somehow the author of the question had made some mistake while setting testcases. The values of Xi and Yi are given in the range of long long or long but user he has set data accoring to int eg. (100000)2 when taken in int gives a negative value but when taken in long long gives positive value and this whole thing is generating wrong output.

Solutions with different combinations of data types and their verdicts : https://www.codechef.com/status/UEMP01,radeonguy

1 Like

My this solution was judged as incorrect https://www.codechef.com/viewsolution/10840760
Don’t know why. @sdssudhu could you point out the mistake.

make everything int instead of long long int and try resubmitting again

May be it would get accepted then.But there is hardly any mistake in my solution.Our solutions are judged incorrectly.

1 Like

Not hardly … there is no mistake, your solution is totally fine. Test cases are bad. Input was not according to the given constraints.

1 Like
//