Is it easier to make tests this way or force a certain solution?
Is it easier to make tests this way or force a certain solution?
| № | Пользователь | Рейтинг |
|---|---|---|
| 1 | Benq | 3857 |
| 2 | jiangly | 3810 |
| 3 | maroonrk | 3534 |
| 4 | tourist | 3528 |
| 5 | Kevin114514 | 3510 |
| 6 | turmax | 3411 |
| 7 | Um_nik | 3387 |
| 8 | Radewoosh | 3367 |
| 9 | heuristica | 3322 |
| 10 | strapple | 3317 |
| Страны | Города | Организации | Всё → |
| № | Пользователь | Вклад |
|---|---|---|
| 1 | Qingyu | 157 |
| 2 | maspy | 150 |
| 3 | nik_exists | 146 |
| 4 | Um_nik | 145 |
| 5 | Errichto | 139 |
| 6 | adamant | 136 |
| 7 | maroonrk | 134 |
| 8 | DNR | 132 |
| 9 | AmShZ | 131 |
| 10 | BledDest | 129 |
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.
Well, let's say you have a graph problems with t tests. Would that be as amazing as div2 A/B cases?
Graph problems in Div2A/B are really uncommon. And what is the issue with graph problems with multitest?
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.
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.
Could you please link an example of such solution?
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.
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.
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.
It could prevent participants from getting penalty if their code fails on sample test case, but not the first one.
I guess its all to avoid long queues... and it seems to be a successful way
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
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)
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.
The second paragraph makes so much sense! Especially in the graph/tree problem's test cases.