Блог пользователя LukaSsS

Автор LukaSsS, история, 4 года назад, перевод, По-английски

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

  • Проголосовать: нравится
  • +43
  • Проголосовать: не нравится

»
4 года назад, # |
  Проголосовать: нравится +55 Проголосовать: не нравится

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.

  • »
    »
    4 года назад, # ^ |
      Проголосовать: нравится +31 Проголосовать: не нравится

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

    • »
      »
      »
      4 года назад, # ^ |
        Проголосовать: нравится +13 Проголосовать: не нравится

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

      • »
        »
        »
        »
        4 года назад, # ^ |
          Проголосовать: нравится +1 Проголосовать: не нравится

        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.

        • »
          »
          »
          »
          »
          4 года назад, # ^ |
            Проголосовать: нравится +28 Проголосовать: не нравится

          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.

»
4 года назад, # |
  Проголосовать: нравится +1 Проголосовать: не нравится

As far as I remember, after some weak pretest incident, problems with multiple test cases became more frequent to make pretests strong. Not sure if it's the only reason though.

»
4 года назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

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.

»
4 года назад, # |
  Проголосовать: нравится +19 Проголосовать: не нравится

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.

»
4 года назад, # |
  Проголосовать: нравится +27 Проголосовать: не нравится

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

»
4 года назад, # |
  Проголосовать: нравится -8 Проголосовать: не нравится

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

»
4 года назад, # |
  Проголосовать: нравится -41 Проголосовать: не нравится

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

»
4 года назад, # |
  Проголосовать: нравится +5 Проголосовать: не нравится

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)

»
4 года назад, # |
  Проголосовать: нравится +17 Проголосовать: не нравится

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.

  • »
    »
    4 года назад, # ^ |
      Проголосовать: нравится +19 Проголосовать: не нравится

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