65
\$\begingroup\$

Quite a few questions require output to be "truthy or falsey". This is possibly confusing as these terms can possibly mean different things to different people, and especially in different languages. How should answers interpret the meaning of these terms?


I'll provide a few possible answers to this - upvote or downvote according to which you think makes most sense. Or add your own answers.

\$\endgroup\$
  • \$\begingroup\$ Shouldn't the answer be "How the answer defines truthy or falsey"? \$\endgroup\$ – Matthew Roh Feb 22 '17 at 7:45
  • \$\begingroup\$ Possible duplicate of The Tag Categorization Project \$\endgroup\$ – Matthew Roh Feb 22 '17 at 7:46
  • \$\begingroup\$ I strong agree the way C language define Boolean: It is True one integer different from 0 It is False: 0 integer value. Boolean bool etc not has to exist for C and C++ languages. For the other languages the return type must to be Boolean (if it exist). If it not exist can be all: As [] for true and [1] for false (but it has to be one return value and not one exception or run time end) \$\endgroup\$ – RosLuP Nov 21 '17 at 10:18
110
\$\begingroup\$

Consider the following pseudocode:

if (x) {
    print "x is truthy";
}
else {
    print "x is falsy";
}

If it results in a runtime or a compile-time error then x is neither truthy nor falsy.

\$\endgroup\$
  • 10
    \$\begingroup\$ I think that's a good definition. Almost any language should have some form of conditional, and the truthi-/falsiness of any value should be determined by which branch of the conditional it leads to. \$\endgroup\$ – Martin Ender Sep 16 '14 at 7:07
  • 4
    \$\begingroup\$ The only problem could be with assembly languages which have jump-if-zero and jump-if-not-zero, but those special cases can be handled as and when the need arises. \$\endgroup\$ – Peter Taylor Sep 16 '14 at 8:10
  • 1
    \$\begingroup\$ Well it might get difficult with some esoteric languages like ///, where you basically need to build the conditional yourself. But I agree, the number of cases should be small enough to handle this on a case-by-case basis. \$\endgroup\$ – Martin Ender Sep 16 '14 at 8:40
  • 2
    \$\begingroup\$ Another example is dc which only has call-on-various-condition operations and no well-defined concept of boolean. \$\endgroup\$ – Digital Trauma Sep 16 '14 at 16:45
  • 2
    \$\begingroup\$ Another downside is that I would consider "FALSE" to be falsey wheras this answer would consider it true in several languages. \$\endgroup\$ – Mooing Duck Oct 4 '14 at 0:45
  • 5
    \$\begingroup\$ @MooingDuck, no-one who wants to win a code-golf would use something as long as "FALSE" if they could use 0 or "" instead, so I think that concern is of negligible practical importance. \$\endgroup\$ – Peter Taylor Oct 5 '14 at 21:39
  • 5
    \$\begingroup\$ @PeterTaylor what about "0"? Also, 0 is truthy in Ruby yet I believe it should be allowed as a falsy output in code golf. \$\endgroup\$ – John Dvorak Dec 13 '14 at 7:37
  • 2
    \$\begingroup\$ A more important distinction - one that this answer doesn't touch - are truthy/falsy outputs of the whole program. Is False falsy (as a stringification of False) or truthy (as a stringification of "False")? \$\endgroup\$ – John Dvorak Dec 13 '14 at 7:40
  • 8
    \$\begingroup\$ @JanDvorak I think the point of this definition is that it is language specific, so 0 and "0" are truthy in Ruby, but falsy in PHP. As for printing to STDOUT, that's a good point, but I'd say the for simplicity it depends on what you are actually stringifying. \$\endgroup\$ – Martin Ender Dec 13 '14 at 9:22
  • 1
    \$\begingroup\$ What if it stays unevaluated? Null seems quite falsy in Mathematica, but If[Null, "foo", "bar"] returns If[Null, "foo", "bar"]. \$\endgroup\$ – LegionMammal978 Oct 25 '15 at 14:36
  • 1
    \$\begingroup\$ This makes any string truthy (or a compilation error in case of std::string) in languages such as C/C++; empty strings included. \$\endgroup\$ – Alexander Revo Jan 20 '16 at 7:42
  • \$\begingroup\$ Even shorter option: use double negation to determine truthiness. E.g. !!NaN gives false in JavaScript. \$\endgroup\$ – user2428118 Jul 9 '16 at 9:40
  • \$\begingroup\$ @user2428118: that doesn't work, e.g. in Perl it's possible to construct an object that gives any desired output when double-negated (via use of overloads). if doesn't have that problem. \$\endgroup\$ – user62131 Dec 13 '16 at 1:13
  • \$\begingroup\$ @MartinEnder: One of these cases ("some esoteric languages") actually came up recently; I answered a truthy/falsey question in 7, which doesn't have anything really resembling a normal if statement. The answer can luckily be easily changed to use any value for truthy and any value for falsey, but it's hard to know exactly what counts as valid there. \$\endgroup\$ – user62131 Mar 21 '17 at 12:32
  • 1
    \$\begingroup\$ What about cases like Julia, where 0 == false (and 1 == true), but if (0) is a compile-time TypeError due to strict type requirements? A strict reading of this answer would say 0 and 1 are then neither truthy nor falsey, but does that match your intention here? \$\endgroup\$ – sundar Jul 3 '18 at 20:01
41
\$\begingroup\$

Truthy/Falsey should be taken as strictly defined in the given language. For example, in javascript, the following are always falsey:

  • undefined
  • null
  • NaN
  • 0
  • ""
  • false

And other values are always truthy.

\$\endgroup\$
  • \$\begingroup\$ I'll have to go with this one. If the question specifically asks for truthy/falsy values, this should be the default. \$\endgroup\$ – Dennis Sep 16 '14 at 0:37
  • 20
    \$\begingroup\$ But some languages don't define truthy/falsey. e.g. x86 assembly (as I know). \$\endgroup\$ – jimmy23013 Sep 16 '14 at 0:45
  • \$\begingroup\$ Does javascript consider "FALSE" to be falsey? \$\endgroup\$ – Mooing Duck Oct 4 '14 at 0:47
  • \$\begingroup\$ @MooingDuck Not "FALSE", but false: console.log((0==1)==false) \$\endgroup\$ – Digital Trauma Oct 4 '14 at 16:26
  • 1
    \$\begingroup\$ and document.all in browser... (but who wanna such a long word in code golf \$\endgroup\$ – tsh Apr 16 '17 at 9:08
35
\$\begingroup\$

Some languages have ambiguity in what is considered truthy/falsey. For example in c, zero vs non-zero is always FALSE vs TRUE from the point of view of conditional operators. But many standard APIs, for example return -1 for FAILURE and >=0 for SUCCESS. So answers may choose (and explicitly state) whatever sets of values they like to represent truthy vs falsey, so long as those sets are mutually exclusive.

\$\endgroup\$
  • 2
    \$\begingroup\$ While I'll like every OP to opt for this approach, I don't think we should make it the default. Just look at the return values of Ilmari's and my answer to “Convenient palindrome” checker. It's hard to draw a line with this approach... \$\endgroup\$ – Dennis Sep 16 '14 at 0:39
  • \$\begingroup\$ @Dennis If the OP didn't ask for true / false values, but truthy / falsey, you could simply call every convenient palindrome truthy. \$\endgroup\$ – jimmy23013 Sep 16 '14 at 1:23
  • 7
    \$\begingroup\$ +1 Truthy (US, colloquial): Only superficially true; that which is asserted or felt instinctively to be true, with no recourse to facts. If you want true or 1, ask for true or 1. If you ask for "truthy", I'll give you something truthy. \$\endgroup\$ – Geobits Sep 16 '14 at 2:14
  • 1
    \$\begingroup\$ I would consider "-1 for FAILURE and >=0 for SUCCESS" to represent an error/result union rather than a boolean, and ergo not a truthy/falsey thing. I could be convinced otherwise though. \$\endgroup\$ – Mooing Duck Oct 4 '14 at 0:47
  • \$\begingroup\$ @MooingDuck Consider also what UNIX shells typically do true; echo $?; false; echo $? TRUE == 0 and FALSE == 1 \$\endgroup\$ – Digital Trauma Oct 4 '14 at 16:23
14
\$\begingroup\$

Don't forget program exit codes!

If my C or C++ or perl or bash or ... program calls exit(0) this action could be considered truthy, and calling exit with a nonzero value could be considered falsey.

\$\endgroup\$
  • \$\begingroup\$ Exit 0 means "EXIT_SUCCESS" or something as that string; exit with not zero is indefinite (possibly there is another string one use for failure example"EXIT_FAIL" ... It is convenient make 0, all ok; number != 0 for error code (because fail can be for many reason and the success case has need only one value). But this has nothing in common with true or false values \$\endgroup\$ – RosLuP Nov 30 '16 at 15:08
  • 1
    \$\begingroup\$ @RosLuP They are used as truthy or falsy in shells like Bash. \$\endgroup\$ – jimmy23013 Dec 1 '16 at 13:33
  • 2
    \$\begingroup\$ @RosLuP: EXIT_SUCCESS is 0 on basically every OS (because 0 has to work as success). EXIT_FAILURE is a specific value on each OS, but the actual value varies by OS (1 is common, though). Each OS also has its own rules for what counts as truthy and what counts as falsey on exit codes (e.g. UNIX considers all nonzero codes falsey; I've heard rumours VMS uses odd versus even). \$\endgroup\$ – user62131 Jan 2 '17 at 5:16
10
\$\begingroup\$

I would partition values into the categories truthy, falsy, and indeterminate according to the following rules:

The following values are considered falsy:

  • the zero value of the type of the result, if any
  • a NULL pointer
  • an array, the product of its dimensions being zero
  • a number whose absolute difference to 0 is not larger than 2-44.
  • a string literal parsed as a number yielding such a number
  • a string literal which when executed as a program of the language the submission is written in yields a falsy value. This rule cannot be applied more than once transitively.
  • an empty string
  • the boolean value false (if any)
  • a string which, when converted to lower case, is equal to one of false, no, f, or n.
  • a function which for any combination of arguments returns a falsy value. This rule cannot be applied more than once transitively.
  • of an enumeration type whose values are not associated with numbers the first enumeration value
  • of an enumeration type whose values are associated with numbers an enumeration value associated with a falsy value, otherwise the first enumeration value
  • a compound type (e.g. a struct) comprising only falsy values
  • a union type the last write to which wrote a falsy value
  • a pointer to a falsy value

The following values are considered indeterminate:

  • a NaN
  • a stray pointer
  • a trap representation
  • an undefined value
  • a function which for some combination of arguments returns a falsy value and for others returns a non-falsy value.
  • the absence of value, i.e. returning nothing
  • the absence of ordinary termination, e.g. termination with an exception or crash or no termination
  • a value, reading from which causes an exception, non-termination, or crash

All other values are considered truthy.

\$\endgroup\$
-1
\$\begingroup\$

Answers should be able to specify what is truthy and what is falsy

Almost all of the answers here are either ambiguous or put some languages at a disadvantage.

For the top rated answer, there are many languages that don't have conditionals: Bitwise Cyclic Tag, any Turing Machine, etcetera.

For the answers that give values beforehand for what is truthy and what is falsy, what about languages with booleans such as fact or lie and win or lose? You can always fix these exceptions, but there will be more as the development of esolangs (or some practical languages too) will arise to new names for boolean/truthy and falsy values.

This is why I say that the answerer should specify what counts as a truthy value and what counts as a falsy value. This is to prevent an answer wasting too many bytes just because their truthy/falsy value wasn't on the list.

\$\endgroup\$
  • 3
    \$\begingroup\$ What keeps me from saying truthy values are exactly the values that let me solve this challenge with the identity function? \$\endgroup\$ – lirtosiast Jun 16 at 8:13
  • \$\begingroup\$ @lirtosiast Good question. A possible solution to it would be making it so that there can only be one truthy value and all other values are falsy. What do you think of this? \$\endgroup\$ – MilkyWay90 Jun 16 at 14:56
  • \$\begingroup\$ That's incompatible with common ideas about truthy/falsy values in most languages i.e. Python, C, JS. I don't see an advantage of this over the modern standard of "any two distinct consistent values". \$\endgroup\$ – lirtosiast Jun 17 at 7:56
-3
\$\begingroup\$

I think Truthy/Falsey instead of being language specific is problem (answer) specific. So in a language we can define different truthy/falsey s based on different conditions. For example one can define truthy as 53 and other things regarded as falsey and in the other problem truthy may be defined as an empty list and anything else may be defined as falsey.

In the other word:
An entity (and all other things that are implicitly convertible to value of that entity) can be regarded as truthy and anything else can be regarded as falsey or vice versa. The entity that is regarded as truthy(or falsey) must has only one exactly defined representation.

For example in Octave language one can regard true as truthy and anything other as falsey. Because all numbers other than 0 are implicitly convertible to true those can be regarded as truthy and 0 can be regarded as falsey. Also arrays that contain 0 such as [7 1 0] are implicitly convertible to false and other arrays are convertible to true.

As an example one can define an empty list {} as falsey and all other things as truthy because an empty list has exactly one representation. Also a list of {1,2,33} can be regarded as truthy/falsey and all other things can be regarded as falsey/truthy since {1,2,33} has an exactly one representation. But consider a function that sometimes returns a list and sometimes returns a scalar, so one can't regard a list as truthy because a list doesn't have exactly one representation so {1,2,3} and {1,2} are both lists but have different representations.

Also one can't define all even numbers as true and all odds as false except in those languages that evens are implicitly convertible to true.

Some examples:

 _________________________________
| Truthy         |  Falsey        |
|----------------|----------------|
| 243            | anything else  |
| NaN            | anything else  |
| anything else  | 127            |
| []             | anything else  |
| anything else  | {7,2}          |
| "foo"          | anything else  |
| True           | False          |
| False          | True           |
|________________|________________|
\$\endgroup\$
  • \$\begingroup\$ I think that is a more general definition. Downvoters please add your comments. \$\endgroup\$ – rahnema1 Feb 26 '17 at 4:26
  • \$\begingroup\$ I didn't downvote, and actually I think this is good answer. Some languages doesn't even have an internal definition of type. But, I still have one objection. \$\endgroup\$ – user72349 Nov 20 '17 at 17:19
  • \$\begingroup\$ @ThePirateBay Good point! answer updated :) \$\endgroup\$ – rahnema1 Nov 20 '17 at 17:28
-5
\$\begingroup\$

For a different view: Output and implementation are something different. A truthy/falsy value is an output that everybody with basic knowledge of common languages recognizes as truthy/falsy, regardless whether that is evaluated to true/false inside a programming language. It will be one of the following:

Truthy:

  1. The string True in any capitalization
  2. The string 1
  3. A floating point string representation of 1.0e0 -/+ eps(1)
  4. In case of functions: a boolean true. integer 1 or float 1.0e0 -/+ eps(1).

Falsy:

  1. The string False in any capitalization
  2. The string 0
  3. A floating point string representation of 0 -/+ eps(0).
  4. In case of functions: a boolean false, integer 0 or float 1.0e0 -/+ eps(1).

Both outputs may have leading or trailing spaces and newlines. Iff your language doesn't support any of the above, you should attempt to find the closest alternative. In all cases, all truthy and falsy outputs should be the exact same for your program, regardless of input.

I believe that in practice, these options will be accepted by all programmers to mean truthy or falsy, and eliminate loopholes. For example, cat could be a prime testing program if you define the set of all prime numbers as 'thruthy'.

Besides, if I ask you 'Are there any German spies around here', I want you to reply 'nein', not nine. In other words, a positive integer is not an answer to a true/false question. Neither is returning a set of all German spies, and claiming it's false if the set is empty.

\$\endgroup\$
  • \$\begingroup\$ The point of this answer is that implementation and output are separate things. Feel free to downvote but do it because you do not agree to that principle, not because something might be different in certain languages - it will only be time before somebody creates an esoteric language where int 1==false \$\endgroup\$ – Sanchises Sep 28 '15 at 19:59
  • \$\begingroup\$ @nimi Incorporated your critique, thanks. \$\endgroup\$ – Sanchises Sep 28 '15 at 21:06
  • \$\begingroup\$ Good edit, now your point is much clearer. However, I'm still not convinced that this is a good idea. The list of possibilities seems rather arbitrary. Languages have an advantage if they can directly print one of those values (print (1==2)) and a disadvantage otherwise. Lisp, for example, would be unlucky as it's native Falsey is printed as nil. -- Furthermore, some challanges allow the result to be returned by a function. In such cases we don't have any output at all. \$\endgroup\$ – nimi Sep 28 '15 at 21:29
  • \$\begingroup\$ @nimi Sorry, I have never programmed in Lisp. For functions, see point 4 combined with Iff your language doesn't support any of the above, you should attempt to find the closest alternative. I prefer to use a simple set of rules with a catch-all clause rather than a extensive list that should be updated with every new esolang around here. \$\endgroup\$ – Sanchises Sep 29 '15 at 9:40
  • 2
    \$\begingroup\$ -1 My main critique is that I don't agree that output is more important than implementation. If you are writing a function that should return a truthy value, you almost always want it to be something that is considered truthy by the language you're working in. Regardless of what an esolang's definition of truthy is, the output should still work within that language. \$\endgroup\$ – Geobits Sep 29 '15 at 15:28
  • \$\begingroup\$ @sanchises: the iff-clause does not apply, because Lisp (to keep the example) is capable of outputting string literals like True. According to your rules alternatives are only allowed if the language cannot produce the specified outputs. -- Function return values: I read the rule as follows: Lisp is allowed to return nil (unprinted), but if it has to print it it must turn it into False/0/etc. That seems odd. \$\endgroup\$ – nimi Sep 29 '15 at 16:45
-31
\$\begingroup\$

This truthy vs falsey concept is way too ambiguous. Questions should be required to state exactly which values represent TRUE and which represent FALSE.

\$\endgroup\$
  • 21
    \$\begingroup\$ This is the only option I truly dislike. If my languages truthy values aren't the same as the OP's it puts me at a disadvantage. \$\endgroup\$ – Dennis Sep 16 '14 at 0:31
  • 9
    \$\begingroup\$ @Dennis Agreed - if I could downvote my own answer, I would ;-) \$\endgroup\$ – Digital Trauma Sep 16 '14 at 0:33
  • \$\begingroup\$ *sees a score of -15* Coincidence? \$\endgroup\$ – dorukayhan Jun 4 '16 at 20:45
  • \$\begingroup\$ You can save bytes if return 1 insted of true \$\endgroup\$ – Евгений Новиков Jul 31 '17 at 14:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .