A reference solution is a program kept with the problem that declares what should happen when it is judged: this one must be accepted everywhere, that one must time out, this other one must give a wrong answer. Running them is how you find out whether the problem's tests and limits do what you think they do — whether the intended solution fits inside the time limit, and whether the naive one really doesn't.
Solutions live on the problem's Solutions tab. They are stored per problem and are never visible to participants. You need permission to write problems.
The table lists each solution's Name, Type (the expected outcome), Status and Runtime.
Every solution declares what the author expects of it:
Value | Meaning |
|---|---|
Correct | Must be accepted on every test. |
Incorrect | Must fail, by any means. |
Wrong answer | Must fail with a wrong answer. |
Timeout | Must exceed the time limit. |
Timeout or Accepted | Either outcome is acceptable — a borderline solution. |
Overflow | Must exceed the memory limit. |
Overflow or Accepted | Either outcome is acceptable. |
Failure | Must fail with a runtime error. |
Don't run | Kept with the problem, but excluded from checking. |
Unset | No expectation declared. |
The two "or Accepted" values are for solutions that sit on the boundary on purpose. A solution you keep for reference but do not want run — an alternative approach, a solution in a language you no longer offer — is Don't run.
Status is the result of the last check: Pending, Pass, Fail, Error, or Unknown when the solution has never been run.
Pass means the judged outcome matched the declared expectation — a solution declared Timeout passes by timing out. A wrong answer where you expected acceptance and an acceptance where you expected a wrong answer are both Fail, and both mean something about the problem needs looking at.
Submit all queues every solution for checking, after a confirmation, and the statuses update in the table as results arrive. A single solution is run from its row's Run, which submits it and takes you to the resulting submission.
Running a solution creates a real submission for the problem in this space. It appears in Submissions like any other, and it counts in the problem's Overview statistics.
Adding or opening a solution gives a code editor on the left and a result panel on the right. The editor takes a name, a runtime — deprecated runtimes are not offered — and the source. The panel's top control is Expected, the outcome from the table above.
Run submits the solution and streams the judging into the panel: status, verdict, score against cost, compiler output where there is any, and the breakdown by testset. Save stores the solution without running it. See Statuses and verdicts for what the results mean.
A solution marked secret cannot be shown. The editor offers Override, which discards the stored source in favour of what you write; the original is not recoverable through the console.