LukaSsS's blog

Why do we see so many "t tests in one" problems lately?
By LukaSsS, history, 4 years ago, translation, In English

Is it easier to make tests this way or force a certain solution?

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

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

It's to reduce server strain and to better check the solutions. For example for a div2 A you can cram $$$10^5$$$ tests into one.

It can also be used block heuristics easier, with fewer tests. This is useful for example for dp and greedy problems.

T tests in one is a good thing, because it makes the tests stronger.

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

    Well, let's say you have a graph problems with t tests. Would that be as amazing as div2 A/B cases?

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

      Graph problems in Div2A/B are really uncommon. And what is the issue with graph problems with multitest?

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

        Tree/graph questions are mildly annoying in multitest because they usually have global state (visited arrays, adjacency lists, etc) that need to be reset between each test case, which is another easy way to get WA if you're not careful about resetting everything.

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

          A cool trick to deal with this is to wrap your solution to the problem into some class with dynamic variables (such as vectors or sets). That way, you can use them in class functions just as if they were global, and the instance of the class you create when solving a test is deleted automatically.

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

            Could you please link an example of such solution?

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

As far as I remember, after some "weak pretest" incident, problems with multiple test cases became more frequent with the intention of making pretests stronger. Not sure if it's the only reason though.

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

It could prevent participants from getting penalty if their code fails on sample test case, but not the first one.

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

I guess its all to avoid long queues... and it seems to be a successful way

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

it makes participantes not to understand in which test case they have problem during a contest... sop that they wont be able to know if their efforts to solve it has been successful or not ... its kinda a hard way to bother participantes

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

Imagine a problem A with a yes/no answer, 10 pretests, and 10000 participants who will moan if they pass pretests but fail systests :)

(yes this is exaggerated, but funny to think hypothetically)

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

This shortens the queue by a lot and also makes for much stronger pretests. Possibly the only downside for this is forgetting to reset global variables and decreasing testcase readability.

Continuing on this topic, I think that problem authors should consider adjusting the format for multiple tests. Rather than having no empty lines in the input, I think there should be 1 new line before each test case. This isn't hard for any (common) language to deal with (for each test first read the empty line), but it dramatically increases test readability.

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

    The second paragraph makes so much sense! Especially in the graph/tree problem's test cases.

    → Reply