Problem types

A problem's type decides what a submission is and how it is graded: a whole program, a single function, answer files, a set of questions, or an answer built inside a page you upload. You choose it when you create the problem: New problem opens a list of types, and the problem is created with the one you pick.

The type also decides which parts of the problem exist in the console, so a row or a tab you expect can be missing simply because the type is different.

The types

Problems created earlier can also carry the SQL or Machine learning type. Both are still judged, but neither is offered for new problems.

What the type controls in the console

• The interactor exists only for Interactive and Communication problems. If you have written an interactor and cannot find where to put it, the problem has a different type.

• The header and footer editors in the code template editor are editable only for Function problems, because only there is the participant's source wrapped into something larger.

• The code templates row on the Solutions tab is hidden for Output only problems, since there is no source code to pre-fill.

• A Quiz problem has a Questions tab and no Solutions or Testing tab: its questions are graded directly, without tests or a checker.

• A Widget problem has a Widget tab, where the page and its checker are set, instead of Solutions and Testing.

• The Studio is available for every type except Quiz and Widget.

Statements, editorials, publishing and discussions work the same way for every type.

Choosing a type

Classic is the default shape of a problem and the right answer unless something below applies.

Choose Function when you want participants to implement one routine rather than a program: you supply the input parsing and the output printing in the template's header and footer, and the participant fills in the middle. Anything a participant could read in the header, footer or additional files is effectively public, so grading logic does not belong there.

Choose Interactive when the input a solution needs depends on what the solution has already done: a guessing game, a query budget, an adaptive adversary. The interactor supplies the other half of the conversation, and the protocol has to be written out in the statement. Interactive problems usually keep instructions for the interactor in the test's input and answer, rather than data a participant would recognise, so their example tests use the statement overrides described in Test cases.

Choose Output only when the participant is meant to produce answers by any means they like (by hand, by a program run on their own machine, by a spreadsheet) and upload them. Attach the input data to the statement so they have something to work on. Each uploaded file is kept with the submission and can be downloaded from the test it answers.

Choose Quiz for multiple-choice and short-answer questions that need no program at all.

Choose Widget for tasks answered by interacting with a picture rather than by writing code, in the style of Bebras.

Communication

A communication problem is an interactive problem in which the interactor runs several copies of the participant's program at the same time and passes messages between them. It is the shape of tasks where parts of a solution must cooperate without sharing memory. Each copy is isolated from the others, and everything they learn about each other goes through the interactor.

Everything else is set up as for an interactive problem: the interactor, the checker and the tests.