Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect TLE submissions should be allowed to give WA #48

Open
ghamerly opened this issue Sep 12, 2016 · 2 comments
Open

Incorrect TLE submissions should be allowed to give WA #48

ghamerly opened this issue Sep 12, 2016 · 2 comments

Comments

@ghamerly
Copy link
Contributor

Currently, if we have a TLE submission, verifyproblem expects that it should always TLE or AC (but TLE on at least one input). It would be natural and nice if verifyproblem allowed a TLE submission to give WA on some inputs, as long as it gives TLE on at least one input.

The intent here is that if we wish to accept an $O(n^2)$ solution but $O(n^3)$ should TLE, then we could make a simple program which just reads the input, ignores the problem, and loops n^3 times. However, this will give the WA error described above.

@austrin points out (via email) that as we move to setting time limits by running submissions through Kattis judge rather than within the problemtools itself, this issue becomes trickier to deal with.

@austrin
Copy link
Contributor

austrin commented Mar 23, 2019

A note: this should cut both ways: a WA solution should be allowed to give TLE on some test cases, as long as it gives WA on at least one test case. (And the same thing goes for RTE submissions.)

@bmerry
Copy link

bmerry commented Mar 30, 2019

Note that there is a small but non-zero risk that allowing this will allow some human errors to slip through the cracks. For example, if the input format changes, it might cause a WA solution to do undefined things, sometimes giving RTE and sometimes giving WA; with the current behaviour that would be detected and fixed. There may be merit in having some opt-in mechanism (like a magic comment in the source) to indicate which outcomes (other than AC and the goal) are acceptable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants