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?? ↵
↵
Ijust 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↵
↵
↵
↵
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?? ↵
↵
I
↵
**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.**
↵
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↵
↵
↵
