# What outputs should I allow for decision problems?

I'm looking for opinions on what outputs to allow as the Yes and No outputs on challenges. The goal isn't to make a policy, but to help with a decision I often have to make when writing challenges.

One standard is Truthy/Falsey, which checks if the output satisfies the language's if construct. I see some big benefits:

• Flexible output is good in general
• Using the language's own definition is the natural choice
• Avoids one-size-fits-all decisions like "[0] is Falsey" that bias towards some languages
• Allows creative golfing approaches like testing for existence by counting (if 0 is Falsey) or enumerating (if the empty list is Falsey).

But, I find awkward issues coming up:

• Some languages don't have an if-like construct
• Truthiness is arguably a non-observable requirement
• It's ambiguous whether a program outputs an object or its string representation
• I find it a step short of "decision" to output, say, [1, 4] which could then be converted to True but isn't
• Having more than two valid outputs diminishes the purity and simplicity that motivated the tag
• Some languages are limited to just True/False because their if construct doesn't implicitly convert to bool, which I find arbitrary
• It's weird if an exact port is invalid because the new language does if differently even though the code never touches on this difference.

An alternative to truthiness is for the answerer to specify a consistent values to stand for Yes and a different consistent value to stand for No.

• The solver is allowed a choice convenient for the challenge, allowing challenge-specific creative approaches
• The two-consistent-outputs rule is easy to state in the challenge, making the rules self-contained and unambiguous
• Anyone can test and confirm a submission without needing to know how its language works

And some cons:

• Choosing favorable outputs feels like golfing the spec
• It's dumb that a solution can use False for True and True for False
• Solutions in a language can't be copy-pasted into an automated tester without adjustment

There's other possibilities like requiring both Truthy/Falsey and consistency, limiting to specific values like 0 or 1, or trying to make a new community consensus definition.

• Come on, someone post truthy/falsey so I can downvote it :P – feersum May 8 '17 at 7:17
• For Boolean values, I think it depends from the language; if for example in C one has to use 0 for false, 1 (or any other not 0 value) for true; in some other language Boolean are {true , false} and one has to use them. In assembly one can use what he/she want... – RosLuP May 8 '17 at 10:14
• "Some languages don't have an if-like construct" And some (probably esoteric) languages have two if constructs which operate differently on the same values. – Martin Ender May 8 '17 at 13:10
• Another problem with truthy/falsy is that some challenges also have boolean input and then it's not clear whether answers can choose two specific truthy/falsy values, whether all need to be supported or whether booleans in the output need to match the same pattern as the input (e.g. Adam's recent "keep only the first true" challenge, which I suspect was what actually inspired this question). – Martin Ender May 8 '17 at 13:12
• "It's dumb that a solution can use False for True and True for False" I'm not so sure about that, since mathematically the assignment of true and false for a property is arbitrary to begin with in most cases. – Martin Ender May 8 '17 at 13:29
• Out of curiosity, what languages don't have an if-like construct? I personally can't think of any – musicman523 Jul 14 '17 at 0:58
• @musicman523 I'm mostly thinking low-level Turing-tarpit languages like BF or Fractran or Malbolge. – xnor Jul 19 '17 at 5:29
• @xnor I don't know the others but I personally would count BF's [] as if-like, though not everyone would agree with me – musicman523 Jul 19 '17 at 7:24

# One consistent, and one non-consistent

The thing I like about Truthy and Falsy is that often you may do things like output 0 for falsy and everything else for truthy. For example this brain-flak answer outputs nothing for even numbers and the input for odd numbers. It could be argued that this is an exploit, I think this gives the opportunity for some really cool golfs.

The thing I don't like about Truthy v. Falsy is it is, as mentioned, not really an observable requirement.

I would suggest, as a happy medium, that the user specify a single consistent value for one state with every other possible output going to the other state.

In the example above it would specify no output for even with all other possible outputs indicating odd.

This method is by no means the best method for every question, so here is a list of pros and cons as I see them. Feel free to comment any more I might have overlooked.

### Pros

• It is very similar to the two consistent outputs suggestion, but it gives golfers more freedom to create some really cool golfs, similar to the truthy v. falsy suggestion.

• It is also completely observable unlike the Truthy v. Falsy suggestion.

• Simpler to explain than the distinction between Truthy and Falsy

### Cons

• A little more complex than the two consistent values

Taken with modification from the question

• This allows you to choose even more favorable outputs increasing the feeling of "golfing the spec"

• It's dumb that a solution can use False for True and True for False

• Solutions in a language can't be copy-pasted into an automated tester without adjustment

• This is an interesting idea but I think the "golfing the spec" part is becoming a big problem here. Nevertheless it might be worth testing this with a challenge. – Martin Ender May 8 '17 at 13:31
• This is an interesting option that I hadn't considered. I'd like to see it used in a challenge so I can see how it works out in practice. – xnor May 8 '17 at 20:19

I think there are many points in favour of two-distinct-consistent-answers:

• Some languages don't have anything resembling typical data structures. But Is It Art? is a good example. Meanwhile, although the language has nothing internally resembling a Boolean or if statement (unless you roll your own), it does have an exit code (success/failure) which works perfectly well in a two-consistent-output challenge even if it isn't something that the language can operate on (and thus isn't truthy or falsey by our usual definition).
• Even in more normal languages, exit codes are often a different sort of thing to Booleans or integers. For example, in C, 1 is truthy and 0 is falsey; but EXIT_SUCCESS is normally 0 and EXIT_FAILURE is normally 1. So if we have an exit code of 1, does that count as truthy or as falsey? I've seen different answers do it different ways on the same question. As such, there's not much point in trying to require "all programs should output truthy when X and falsey when not X", as which answer is which can reasonably differ between answers.
• Two-distinct-consistent-answers allows for more possible approaches than truthy/falsey does. If you have an algorithm that works for a truthy/falsey challenge, adding one or two NOT operators (which in most non-esoteric languages, and many esoteric languages too, is a maximum of four bytes, e.g. !!()) will easily turn it into a two-distinct-consistent answer.

Going the other way is not always possible (e.g. if one of your consistent answers is the error message produced by a division by zero and the language has no way to trap errors), and is often much more verbose even when it is possible; and yet in many cases, it's possible in zero bytes via exploiting corner cases of the rules (e.g. the division-by-zero probably sets the exit code to 1, so say your program "outputs by exit code" and then define 1 in an exit code to be truthy or falsey depending on which output you want). So if you favour keeping the golf in the program, not in the I/O, two-distinct-consistent-answers will get rid of some of the largest abuses.

• Requiring distinct, consistent answers (without specifying what those are) naturally deals with unavoidable output boilerplate, and cases where a language outputs in a format that doesn't appear in the source code (e.g. in Prolog, interpreters normally produce a failure output as false. or no., but the closest equivalent in the source would be fail with no full stop). As such, it's a very objective rule. Truthy/falsey is much more subjective in these kinds of cases.

Note that these arguments are mostly oriented at full programs. With functions, these arguments tend to be less convincing (although only the last point gives an advantage to truthy/falsey in a function setting, as it tends to be more objective whether a function return value is truthy than whether two arbitrary data are equal; the other points are more neutral on functions). However, the number of languages in which functions don't exist or require a lot of boilerplate is probably much larger than the number of languages which can't easily handle full programs and which can neither easily output-to-stdout nor compare Boolean-valued function return values, so I think the arguments for full programs probably swing this.

• "the number of languages in which functions don't exist or... etc" Regardless of the number of languages, I believe the number of submissions that are functions is a very decent percentage of answers on PPCG, so I'm not sure this argument works. That said, I'm not exactly sure what you're trying to say in the last paragraph with two-distinct-consistent outputs being more problematic with functions? – Martin Ender May 8 '17 at 13:18
• @MartinEnder: It's not necessarily entirely clear whether two things are equal or not (i.e. whether an answer is consistent), but from within a language, it's easy to test whether a value is truthy by definition. Also, note that in the last paragraph I'm not comparing functions to full programs; I'm comparing languages which are forced to use full programs, to languages with no standard output and no way to compare Booleans. The last category, while not completely nonexistent, is very small. – user62131 May 8 '17 at 13:29

The best solution, in my opinion, is to allow solutions to choose two distinct sequences of bytes to represent a truthy output and a falsey output. Some possible output pairs could be Yes and No, True and False, 1 and 0, \x01 and \x00, 1 and an empty output, etc. The actual challenge is deciding whether or not a given input has some quality. Restricting the output adds unnecessary complication that distracts from the actual challenge.

• I share this view. For cases where a particular challenge would suffer from being able to use True for False and False for True, the author can override this default. If the author doesn't specify, I don't see a problem with taking advantage of any benefit this may bring. – trichoplax May 7 '17 at 23:13