Should Booleans be allowed where a number is required?

Question

This is a rather common inquiry in contests that require computing elements of a sequence.

For example, consider the following recursive implementation of the factorial function (Python):

f = lambda n:n<1or n*f(n-1)

This works well for all positive n; f(n) returns the required result as an int.

However, f(0) will return the result of the comparison n<1, which is the the bool True.

Fixing this is easy enough, but it costs a few bytes:

f = lambda n:0**n or n*f(n-1)

While it is possible to think of the Booleans True and False as numbers (usually 1 and 0) and use them as such in languages such as Python, languages such as Java or Ruby do not even allow casting a Boolean to a numeric type.

Since this is such a common scenario, I think we would benefit from a default. If a challenge doesn't contemplate returning Booleans instead of numbers, should it be allowed or forbidden?

Answer 1

If it quacks like a number, it's a number

Let's look at some Python examples.

>>> 2 * 1
2

>>> 2 * 0
0

Cool, 2, 1, and 0 are all numbers. That's not being contested here.

>>> 2 * True
2

>>> 2 * False
0

True and False act just like 1 and 0 (respectively). In fact, 1 == True and 0 == False. The only difference is that 1 and 0 are instances of int, and True and False are instances of bool (which is itself a subclass of int). This is by design.

In C, they are exactly the same: true and false are preprocesser macros defined as 1 and 0, respectively.

In short: if you can use a boolean just like a number, then booleans are acceptable substitutes for numbers, since they're functionally identical.

More general: Data types can be substituted so long as the alternate data type is functionally identical to the intended/original data type. For C, this means using uint_8 instead of char is acceptable. For Python, this means that bool and int are interchangeable.

However, this does not apply to challenges where an exact string output is required. For example, in Ninety-Nine Bottles of Beer, the second-to-last verse must be "1 bottle of beer on the wall...", not "True bottle of beer on the wall...".

Answer 2

By default, answers should provide what the question asks for

If the question asks for a number, the answer should provide a number. We have various defaults partly to reduce boilerplate, but also to cover issues which a first-time poster wouldn't think about and where their failure to think about it would seriously affect question quality.

A first-time poster wouldn't think about allowing answers to their integer number sequence question to print True rather than 1, and it would be quite reasonable for their reaction when someone does that and then points at meta to be along the lines of "This is stupid. I'm going to edit my question."

So consider two scenarios:

Scenario 1: new user posts a question, making perfectly reasonable assumptions about what kind of answers would be permitted; someone posts an answer which prompts the new user to want to disqualify that answer. This runs up against our general distaste for question edits which disqualify existing answers.

Scenario 2: new user posts a question; experienced user requests them to edit it to allow Booleans. Either they don't want to, and make that clear; or they agree, and edit. In neither case is any existing answer disqualified.

The second scenario seems to me to be clearly preferable and the comparison seems to be sufficient reason in itself to require that by default this should not be allowed.

Of course, nothing prevents those who want from adding the following line to their questions:

If your language has a Boolean type for which true and false are each equal to exactly one integer value, you may return/output that type instead of an integer when the specified output would otherwise be that integer.

Answer 3

Not in Inputs/Outputs

Allowing booleans to be returned instead of numbers is completely against the whole point of booleans in languages.

Booleans are not necessary, but are implemented to make a distinction between the "simple" numbers 1 and 0 and the boolean values true and false.

The implementation of booleans in the language has no influence on this: the fact that it is implemented means that it is intended to be semantically different from numbers.

Note: If your boolean gets returned as a number, then that's obviously valid. Similarly you can use booleans however you want inside your program.

Note 2: I have the exact same view for chars. Arguing that an output of '*' is valid if the expected output is 42 is completely ridiculous. As before, if your '*' gets printed as 42 then it's fine.