notTehlka's blog

A suggestion for the problem setters
By notTehlka, history, 4 years ago, In English

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

  • Vote: I like it
  • +31
  • Vote: I do not like it

»
4 years ago, # |
  Vote: I like it +24 Vote: I do not like it

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.

→ Reply
  • »
    »
    4 years ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

    That can be abused, so please no.

    → Reply
    • »
      »
      »
      4 years ago, # ^ |
        Vote: I like it +36 Vote: I do not like it

      Increasing TL by 25% for Python will help hundreds of people and can be abused only once every few contests by single participants.

      → Reply
  • »
    »
    4 years ago, # ^ |
      Vote: I like it +19 Vote: I do not like it

    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.

    → Reply
»
4 years ago, # |
  Vote: I like it +52 Vote: I do not like it

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...

→ Reply
  • »
    »
    4 years ago, # ^ |
      Vote: I like it +6 Vote: I do not like it

    If a problem can be ruined simply by saying that Python solutions might not pass, then it's not worth using in a contest.

    → Reply
    • »
      »
      »
      4 years ago, # ^ |
        Vote: I like it +20 Vote: I do not like it

      It gives away nlog^2n solutions or sqrt decomp solutions, for no good reason really.

      → Reply
      • »
        »
        »
        »
        4 years ago, # ^ |
          Vote: I like it 0 Vote: I do not like it

        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

        → Reply
        • »
          »
          »
          »
          »
          4 years ago, # ^ |
            Vote: I like it +3 Vote: I do not like it

          It can be abused because you can embed C code in Python.

          → Reply
    • »
      »
      »
      4 years ago, # ^ |
        Vote: I like it +33 Vote: I do not like it

      It doesn't reveal more than going to the submissions tab and seeing running times close to TL.

      → Reply
      • »
        »
        »
        »
        4 years ago, # ^ |
          Vote: I like it 0 Vote: I do not like it

        Hmm, that's somewhat true. Another argument why it's unnecessary :D — one can filter submissions by language during the contest.

        → Reply
»
4 years ago, # |
  Vote: I like it +26 Vote: I do not like it

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.

→ Reply
  • »
    »
    4 years ago, # ^ |
      Vote: I like it +30 Vote: I do not like it

    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.

    → Reply
    • »
      »
      »
      4 years ago, # ^ |
        Vote: I like it +36 Vote: I do not like it

      I think this is a separate point from skittles1412. If I understood his point correctly, I believe he was replying specifically to:

      give a disclaimer that the problem might not have a solution in slow languages

      IMO this is a separate point from being python-friendly. I agree with both points:

      1. It's the participants job to know if some algorithm will pass in some language, it's not the problem setters job to tell participants that, for example, a brute force wouldn't pass. This example is a bit extreme, but I believe it illustrates my point — problem setters shouldn't have to warn the participants about things they should already know if they want to code in python.
      2. Being python-friendly is always a good thing as it expands the community and makes CP more accessible. I definitely think this should be done if possible.
      → Reply