Bad Constraints for APRIL19 problems

c-plus-plus
dfs
dynamic-programming
editorial
tree

#1

Two problems in April challenge had constraints such that one could not solve them without adding the following two lines:
ios_base::sync_with_stdio(false);
cin.tie(flase);

Here are the two problems and my solutions without for them one including above two lines and other not:
Problem:https://www.codechef.com/APRIL19B/problems/SUBREM
above lines excluded solution(TLE):https://www.codechef.com/viewsolution/23926538
above lines included solution(AC):https://www.codechef.com/viewsolution/23926729

Another problem with the same issue
Problem:https://www.codechef.com/APRIL19B/problems/SJ1
above lines excluded solution(TLE):https://www.codechef.com/viewsolution/24037398
above lines included solution(AC):https://www.codechef.com/viewsolution/24037354

In both the above problems only those two lines make the difference between AC and TLE. While I do understand their importance but they were not mentioned necessary for solving the problem. Hence many people who could solve them couldn’t just because of this.
I don’t think it should be made mandatory to include those lines in a normal competition(up for debate). If it is used, it should be notified in the question to use fast IO to avoid TLE. I believe it is just bad on codechef’s behalf to do that without informing. Kindly look into it and make sure to prevent it from happening further
Just tagging active users, admin cause I don’t know whom to tag:
@admin @alfarhanzahedi @l_returns @melfice


SJ1 - Editorial
#2

Java users can argue this in almost all problems :slight_smile:
Well Xormin had even worse constraints… Cin cout doesn’t work with it… You have to use printf scanf for solving it…

What can codechef do?
They might keep time limit little lenient next time. But it depends on the question though.
Sometimes they keep it more tight for forcing user to use more optimized algorithm ( O(n*log(n)) vs O(n) ).
Optimization is also a skill…
though I agree it shouldn’t be just fast i/o…
What can you do ?
Save this two lines in your template :slight_smile:
cin cout works for me in almost all problems after adding these lines… ( Not for xor min though)

Subtree removal passes without those lines(0.98 secs though) :
https://www.codechef.com/viewsolution/24038361


#3

Not codechef’s fault

if they would be kept higher time limit then people who hav put those two lines would hav had advantage

you cannot force anyone to not put those lines but can force others to use it

believe it or not optimising your program is a part of becoming a good programmer

EDIT:- SUBREM can be solved without those 2 magical lines in 0.66sec as opposed to time limit of 1sec

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


#4

I had read cin and cout are as fast as printf if we use cin.tie(0) and cout one …am I wrong?


#5

Even I read that but I think it’s not the case when we have huge data for input/output … I am claiming this after seeing below solutions…
TLE: https://www.codechef.com/viewsolution/23989493
AC:
https://www.codechef.com/viewsolution/23969675


#6

Don’t blame cin/cout, it’s just you using std::endl after every query ¯\_(ツ)_/¯
Accepted: 24040848


#7

Oops…
I forgot about endl…
Yes you are right… endl takes more time…
Thanks for correcting me…


#8

I did not read it full but I will simply put my personal opinion-

You are EXPECTED to know stuff like Fast IO and Slow IO which are basic concepts of programming language.

Instead of asking Codechef to not ask it, you are expected to take a step forward and learn it.


#9

I agree to the OP and I think that it is also a worthy point that people should know about these basic concepts of the programming language but hundreds of people have wasted hours and hours just for this thing without learning anything in the process whereas learning this was only a 10 minute job. The point of codechef long challenges is to make people learn, not bang their heads over silly mistakes. So I think they should at least give a warning in the problem statement about large input data.