ASCII Art Output Rules

Question

I know there's a desire on PPCG for challenges to be flexible in terms of what they allow for input and output. However, I think there is an argument to be made that ascii-art is a special case, and should be stricter about the permitted output formats.

As a case in point, there was a recent ascii-art challenge that involved outputting dominoes. In the challenge description, the sample output looked something like this:

    o|o   o
     |  o  
o    |o   o

The top answer, at the time of writing, was returning output like this:

[[[False, False, True], [False, 0, False], [True, False, False]], [[True, False, True], [False, 1, False], [True, False, True]]]

I find it hard to believe that anyone looking at that could honestly describe it as ASCII art! The second most upvoted answer is a little better, but not by much.

Now I don't mean to criticise these answers, because the challenge made it quite clear that that sort of output was considered acceptable. But what I'm proposing, is that maybe in the future we should be discouraging challenge authors from being so lenient in what they accept, assuming the question is tagged as ascii-art.

As for what exactly should be permitted, at the very least I'd expect the output to include the actual characters of the artwork that was specified in the challenge. Outputting to stdout, displayed on screen, or returning a string (typically newline-separated) all seem OK to me. Returning an array of strings, or an array of characters, feels perhaps like it's getting too lenient again.

But that's the point of this question: what is the consensus on output formats that should be allowed for ascii-art?

Answer 1

Allow strings, arrays of strings and 2D arrays of chars.

If the question is going to allow much more (e.g. outputting boolean values), pretty much every answer is just gonna use that and the question would be better off not being ascii-art at all. If it is reasonable to allow that type of output on a challenge, it being ascii-art is pointless.

ASCII-art is (usually) about creating 2-dimensional text art. Strings with newlines and arrays of lines clearly encode a 2-dimensional output. As in many languages strings equal character arrays, I think 2D character arrays should be allowed too.

The characters in the 2D array can be integers too, as long as they are the ordinal of the character represented in some encoding.

Answer 2

Return types should be trivially viewable as ASCII art

If you're writing a function that returns the content rather than outputting it directly, then it's expected that your language has a function, procedure, or operation that could trivially display that content (whether writing to stdout, displaying directly onscreen, or some other visual representation) without any additional processing.

For example, if your language's "print" function can only print strings, then your function should return a string. But if your language doesn't differentiate between strings, list of chars, or even lists of integer ASCII codes, then those would be acceptable return types too.

I don't want to arbitrarily limit the return types in languages where the distinction between a string and a char array is meaningless. However, I don't think it's acceptable to return something like a list of numbers if the given language requires several lines of additional code to convert those numbers into the actual output that was requested.

Answer 3

Allowed, not required

ascii-art and kolmogorov-complexity are two major categories where the specific format of the result is important to the validity of an answer. In Kolmogorov Complexity especially, "saving" bytes by outputting the result in a different order than requested is really far outside the spirit of the tag. ASCII art also often has a motivation that the output be formatted a certain way. In both these cases a clear motivation for why the output format is important to the challenge can usually be stated.

On the other hand, I don't see any reason that using the ASCII art tag should FORBID a challenge from being flexible with output formats. I wouldn't necessarily expect it when solving such a challenge, but if the challenge poster says answer is valid I don't see why not. Common ways ASCII art challenges afford some flexibility includes allowing a list of strings instead of a single string with newline delimiters, allowing choice for certain characters (e.g. in the domino example allowing free choice of character to represent the pips rather than only o) or allowing additional whitespace that doesn't alter the shape (such as at the end of lines, before the first line, or after the last line).

Flexible I/O is a default guideline, not a rule

As long as the poster of a challenge can formulate a reasonable argument for why their rules about I/O are important to the nature of the challenge, it's not common practice to force undesired I/O restrictions or lack-thereof onto a challenge. For example in the domino challenge, I think it's perfectly valid for the challenge author to accept flexible output. I also think it would be valid for the author to require all pips to be represented by the same value, or that the first row pips of both sides to be "in the same line", or that pips must be a single character, or that the dividing line is important... All those are restrictions that could easily be argued as important to defining the spirit of the challenge.

I would also have been fine with a similar challenge posted that didn't explicitly state any of those requirements, which then rejected the answer mentioned on the basis of "it doesn't look like a domino".

TL;DR

I don't think a challenge shouldn't be allowed flexible output just because it is ascii-art, nor do I think ascii-art challenges should be expected to use the same standards of flexible output as other challenges.

Answer 4

A 2D array can be treated as an ASCII output, if each contain one character, and joining the inner layer then join the outer layer with delimeter '\n'

For the

[[[False, False, True], [False, 0, False], [True, False, False]], [[True, False, True], [False, 1, False], [True, False, True]]]

guy it's too far: containment are boolean, and it's a 3D array rather than a 2D one

Returning

[[0, 0, 1, 9, 1, 0, 1],
 [0, 0, 0, 9, 0, 1, 0],
 [1, 0, 0, 9, 1, 0, 1]]

is acceptable if challenge allow any symbol