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?

• James Holderness: @Dennis I don't think any ascii-art challenge necessarily requires ASCII art output if you choose to be lenient about the supported output - fundamentally you're just returning a list of numbers. My point is that if you're going to tag something as ascii-art then the output requirements should be stricter than that.
• mbomb007: The OP said "If you really wish, you can use 0 for whitespace and 1 for the pips, or False/True (or your language's equivalent) if outputting an array.", but I do agree that this doesn't make sense for ASCII output. ASCII output challenges should require ASCII output. Outputting a 2D array of bits is not ASCII output.
• James Holderness: @mbomb007 I did point that out in my question. I'm not criticising the answers, since they were just making the most of the rules they were given. It's the challenge authors that need to be persuaded not to be so lenient in what they allow - then those kinds of answers would never get written.
• xnor: Yes, please. When I'm golfing in Python, multi-line output has so many golfing possibilities: repeated print, join, %-formatting. But allowing list output means a comprehension in a lambda is often just the clear winner.

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.

• James Holderness: It feels wrong to me to accept something like [32,32,32,47,126,126...] as valid output in an ascii-art challenge, unless the given language can also trivially display that output format as ASCII (e.g. a byte array in C). Otherwise this is not much better than allowing arrays of boolean values.
• dzaima: @JamesHolderness My idea with allowing integer arrays as ordinals was that it allows languages which can't (or have a really hard time) at dealing with strings, to compete. It doesn't give those answers much of an advantage, whereas boolean arrays give a huge advantage to array manipulation languages and drives away from the ascii-art.
• James Holderness: Not every question has to be answerable in every language. And if a language isn't capable of outputting ASCII characters maybe it shouldn't be answering ascii-art challenges. I understand the desire to be accommodating, but in practice I think this kind of rule just ends up being abused by languages that are perfectly capable of outputting ASCII, so we get 90% of the answers being unreadable rubbish. And the rare languages that can't handle strings are likely not even attempting these challenges.
• dzaima: @JamesHolderness While that being abused may be the case often, preventing it from being used then (and on other times too) isn't much of a solution because then languages which provide the conversion to multiline strings implicitly get a free score boost (or even just languages which convert ints to chars); This is why the idea of flexible I/O was made. While personally I don't think that it's a nice representation of ASCII-art, many will rightfully disagree and with good reason.

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.

• James Holderness: The ascii-art tag is described as "creating or parsing pictures using text characters as the paint". I just don't see how you can consider an array of boolean values as being an acceptable format under that definition. I could understand certain allowances for character substitution, where the resulting output still reasonably approximates the target "picture" (e.g. substituting another pip-like character in a domino challenge). But if you really want to allow output that looks nothing like ASCII art, then maybe you should be using a different tag for your challenge.
• Kamil Drakari: @JamesHolderness First of all, I think that the ASCII art tag is fine even if you don't rule out weird edge cases where the output doesn't quite look like the thing it's supposed to. Also, based on the comments now that I found the answer in question, it actually could be easily printed and look correct with only character substitution (1 => o, 0 => ` `).
• James Holderness: In my opinion, you really ought to be able to translate your output format into the specified ASCII with just a single function call or operation. If you require a significant chunk of translation code to get the expected output, then you really haven't completed the challenge. So for me, "easily printed" means a single print call, or equivalent operation.
• Kamil Drakari: @JamesHolderness That is a very vague and abstract requirement, and if taken literally is much more restrictive than almost any challenge I've seen; for example, "List of strings" is a very common output format that many languages wouldn't just print correctly. Anyway, it seems that your main objection is "booleans are not characters" but many languages have such flexible type systems that the distinction is meaningless.

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

• l4m2: The challenge says You may also choose to output a list of lines, a list of the two faces, or a combination of these. If you really wish, you can use 0 for whitespace and 1 for the pips, or False/True (or your language's equivalent) if outputting an array. so a 3D array is nothing wrong
• James Holderness: I'm not saying there was anything wrong with the answers - I think they all complied with the rules they were given (and I don't really care if they didn't). My concern is that the question shouldn't have had rules that were so lenient if it was intended to be an ascii-art challenge. An array of numbers is not ASCII art, and if the rules allow that, then the challenge shouldn't be tagged as ascii-art.
• l4m2: If you are asking what it should be tagged, I guess you have the wrong question expression
• James Holderness: I'm not asking what that one example question should be tagged as. I'm proposing that there should be a set of rules that are mandatory for any challenge that is tagged as ascii-art. And I'm looking for a consensus on what those rules should be.
• Ferrybig: How can you join the inner array, if you choose a space for your joining character, you have to much margin around the pipes, and using an empty string, you get too little space between the x character