THIS IS VERY UNFAIR!!!
Разница между en1 и en2, 189 символ(ов) изменены
Today I participated in [contest:669], I managed to solve the first three problems in a very good time.↵

I started with problem D. didn't take long to figure out the idea (I like it very much BTW :). I submitted and got TLE on pretest 11. I knew it was because of huge input so I added ↵

~~~~~↵
ios_base::sync_with_stdio(0);↵
cin.tie(0);↵
cout.tie(0);↵
~~~~~↵

I know that with these three lines cin/cout becomes almost as fast as scanf/printf. so I resubmitted the problem and got **pretests passed**. I have about 40 minutes left so I move to the last problem.↵

So the system test finishes, and I am shocked that my solution for D got **TLE** on test 29!!! Although it runs in O(n) complexity!!!↵

After five long hours of waiting till I can submit again -_- ... I just changed cin/cout to printf/scanf and get **ACCEPTED**!↵

problem link: [problem:669D]↵

TL submission: [submission:17493329]↵

AC submission: [submission:17500406]↵

I don't think there is another _unwanted_ solution with a close running time to this one!! (I believe O(n log n) solution would be fairly slower than O(n) )...↵

So I wonder why did they use this huge input and this very tight Time Limit?? ↵

just can't imagine I just lost 50 rating for this $#^&!↵

**I DON'T LIKE SCANF/PRINTF AND YOU SHOULDN'T MAKE ME USE THEM!!!**↵

**AT LEAST YOU CAN INDICATE THAT YOU ARE A PIECE OF $#^& IN THE PROBLEM STATEMENT SO I REMEMBER TO USE THEM NEXT TIME.**
DON'T LIKE SCANF/PRINTF AND YOU SHOULDN'T MAKE ME USE THEM!!!

This is not the first time I see this issue, and I am not saying this for the ~200 places I lost for it. but I think problem setters should take **extra care** when setting the TL to deliver a fair and happy competition to all the users :)↵

I am wondering if anyone else ever had the same problem? this time or in another round??↵

I know I did but not in an official round so it didn't matter much!↵

My suggestions:↵

- either stretch the TL so both solutions pass↵

- or make the input a bit smaller so it won't have this **HUGE** impact on running time↵

- or write a note at the end of the problem to use scanf/printf↵

- or send an announcement that cin/cout will not be accepted↵


История

 
 
 
 
Правки
 
 
  Rev. Язык Кто Когда Δ Комментарий
en2 Английский samiemad 2016-04-25 03:59:01 189 Calming down!! :D
en1 Английский samiemad 2016-04-25 03:39:33 2172 Initial revision (published)