Questions like 1512G - Short Task and 1500B - Two chandeliers have very less accepted solutions in slow languages like Python/PyPy. My suggestion is that if the setters/testers feel that majority of the submissions in slow languages would exceed the time limit, they can just give a disclaimer that the problem might not have a solution in slow languages. An example of this can be seen in Kick Start 2020 Round C problem 3. I feel that this will help users who use slow languages and will also not reveal much about the intended solution. isaf27, KAN, antontrygubO_o, MikeMirzayanov, please consider my suggestion. Thanks
→ Обратите внимание
→ Трансляции
→ Лидеры (рейтинг)
| № | Пользователь | Рейтинг |
|---|---|---|
| 1 | ecnerwala | 3648 |
| 2 | Benq | 3580 |
| 3 | orzdevinwang | 3570 |
| 4 | cnnfls_csy | 3569 |
| 5 | Geothermal | 3568 |
| 6 | tourist | 3565 |
| 7 | maroonrk | 3530 |
| 8 | Radewoosh | 3520 |
| 9 | Um_nik | 3481 |
| 10 | jiangly | 3467 |
| Страны | Города | Организации | Всё → |
→ Лидеры (вклад)
| № | Пользователь | Вклад |
|---|---|---|
| 1 | maomao90 | 174 |
| 2 | adamant | 164 |
| 2 | awoo | 164 |
| 4 | TheScrasse | 160 |
| 5 | nor | 159 |
| 6 | maroonrk | 156 |
| 7 | -is-this-fft- | 150 |
| 8 | SecondThread | 148 |
| 9 | pajenegod | 145 |
| 9 | orz | 145 |
→ Найти пользователя
→ Прямой эфир
Codeforces (c) Copyright 2010-2024 Михаил Мирзаянов
Соревнования по программированию 2.0
Время на сервере: 18.04.2024 04:49:23 (k3).
Десктопная версия, переключиться на мобильную.
При поддержке
Or they can just increase time limit for submissions in Python or any other slow language, because it will be hard on specific users otherwise.
That can be abused, so please no.
Increasing TL by 25% for Python will help hundreds of people and can be abused only once every few contests by single participants.
Even though I mostly use python, I am strongly against it.
It's kind of anti-competetive.
If you use python, you tradeoff speed of coding for performance of the program. It is perfectly fine as it is.
Why would they do that? It reveals information about the problem. You know that python is slower than c++ so I don’t see a reason for your whining. Imagine if everyone whined after getting TLE because of using DS/algo with worse constant factor than some alternative...
If a problem can be ruined simply by saying that Python solutions might not pass, then it's not worth using in a contest.
It gives away nlog^2n solutions or sqrt decomp solutions, for no good reason really.
Would two different set of test cases(for TLE test cases) be a good idea. During hacking phase later on constraints for slower languages can be shown. Or would this be too much of a hassle with other unintended consequences as well
It can be abused because you can embed C code in Python.
It doesn't reveal more than going to the submissions tab and seeing running times close to TL.
Hmm, that's somewhat true. Another argument why it's unnecessary :D — one can filter submissions by language during the contest.
IMO languages in CP are just a tool; a key to unlock the door leading to AC. You are free to use whatever language you like. CF provides the same languages to everyone in the same contest, so you're no different than the other ~20000 participants.
A problem is simply asking you to submit a program (using any supported language) that, when run on CF servers, produces the correct output for each test case in a certain amount of time using a certain amount of memory. What language you use to do this is up to you. It is ultimately your responsibility to figure out how to write a program that does such a thing. I see no reason to ask or require coordinators or problem setters to do this for you, although they can if they want to. It is, after all, part of solving the problem. Increasing TL is a different story.
On the other hand, if the goal of CP is to popularize puzzles among programmers (which is a bold statement and I don't think it's 100% true) then we should be python-friendly.
I think this is a separate point from skittles1412. If I understood his point correctly, I believe he was replying specifically to:
IMO this is a separate point from being python-friendly. I agree with both points: