I have suffered almost 4 times out of the last 10 contests. Similar logic getting AC in C++ and TLE in Python, especially for Div 2 D and Div 2 E problems. This is hugely unfair for python coders. I earnestly request the setters and the testers to adjust the constraints and the time limits in such a way that it is almost fair for coders of all languages. Not only did it cost us 1 penalty marking but also sometimes, we don't have enough time to convert the python code to C++.
If you are using a cycle in a race where everyone else is using a sports bike. Then it's your problem.
As a C++ user, I disagree. Trying to cheese can be very annoying and a downright demotivator. CP should be about coming up & implementing clever solution, not constant factors.
I wonder if hypothetically some new language is made which beats cpp by a good factor and is supported by codeforces, then if the problems are graded solely according to that language, will your opinion be the same.
click
a Huge pain indeed. But this problem is not new. Maybe switch to C++ since you're gonna encounter such cases every now and then ? I have myself suffered this for more than 4 times and started using C++ for such kind of situations. For example, using python, DP section of CSES problemset fails on most of the problems. After all, language becomes just a tool if you have enough experience. .
This is just a problem in all competitive programming contests. I personally think that if contests held themselves to the highest standard, they would implement judge solutions in every programming language supported in the contest. This might mean time limits would be adjusted per programming language depending on the runtime of the corresponding judge solution.
However it seems nobody is interested in this, so I question why we support multiple programming languages in these competitions anyway. It's mostly pretend and say we do, but if you plan to be competitive, it's not the case at all.
Obviously Codeforces supports submissions in dozens of languages, so it would highly multiply the amount of work they have to do to prepare a contest, but it doesn't change the fact that the 'supported languages' are only 'supported' by a very loose definition.
I think it is very unfair to C++ coders that python coders do not need to waste their time specifying the type of their variables. For example
vs
I demand that python coders write some comments to their code so that the number of characters that they have to type is comparable to the ones of C++ coders
using vi = vector<int>
vi arr(n);
You didn't need to recode your solution in c++ for D this contest. You just needed to submit it in PyPy 64 bit instead of PyPy.
Here's your solution getting AC in a comfortable 1200 ms (actually, I changed a break statement to a continue statement since it got WA): 150538796
The reason you need to use 64 bit is because the numbers are on the order of $$$10^{18}$$$.
I think it's up to the programmer to pick the right language to solve the problem. For example, I used PyPy 64 bit for D and switched to c++ for E this contest.
This is not the only instance. I have been facing this quite often. I can cite the problems also.