Describe how samples are shown in statement

[niemela]

We say that the sample data should be appended to the problem statement, but we don't explain what that means.

The standard case is pretty obvious:

• Show testcase.in and testcase.ans

But there are so many special cases:

• If there is an testcase.interaction it should be shown, and testcase.in and testcase.ans should not.
• If there is an testcase.out it should be shown instead of testcase.ans (if testcase.ans should be shown).
• If there is an testcase.args, these should be shown as well.
• If there is an testcase.files, these should be shown as well.
  • Except if these files are not printable... then... I don't know?!? Hexdump I guess? Download link on the web?

[evouga]

Another complex aspect of this that came up at breakfast: what files are included in the downloadable sample data? For instance, for interactive problems with an .interaction file, only the .interaction should be shown in the problem statement, but the .in and .ans files need to be shipped with any executable testing tool.

[Tagl]

Another way of showing interaction is dumping a text file that is both the input and output.
In an educational setting for beginners, prompts are often written in code such as

Enter your name: John
Enter your age: 30

which looks weird when you separate input and output streams for display, because the newline does not appear in the output stream, resulting in:

John
30

as input and

Enter your name: Enter your age: 

as output.

[pehrsoderman]

@Tagl Would this not work with indicators of direction for an interaction:

> Enter your name:
< John
> Enter your age:
< 30

[Tagl]

It kind of works, but it is not what the person will see running it on their own terminal.
The idea here is to be more beginner-to-programming (and even terminals) friendly.
These people do not yet have knowledge of input/output streams.
These problems are also often not validated in an interactive manner for simplicity.

[eldering]

I think that we should specify only the most common cases, and leave anything else to the author to explicity write in the problem statement themselves.

So the common cases I think we should handle:

• If there's only an .in, and .ans and/or .out file: if the .out does not exist, consider it to be a copy of the .ans file. Then render the .in and .out file side by side.
• If there's a .interaction file, render it in some sensible way.

Maybe add a command to insert the contents of .args in the text?