What outputs should I allow for decision problems? [duplicate]

Question

I'm looking for opinions on what outputs to allow as the Yes and No outputs on decision-problem 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.

Answer 1

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

Answer 2

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.

Answer 3

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.