How to check if any arbitrary thing is falsy?

[herdrick]

This question regards the expression language.

How does one check if any arbitrary thing is falsy without possibly throwing an error?

Executing these:

true ? "true is true" : "true is false"
1.7 ? "floats are true" : "floats are false"
"one seven" ? "strings are true" : "strings are false"
undefined ? "undefined is true" : "undefined is false"
null ? "null is true" : "null is false"

... give you what you'd expect:

"true is true"
"floats are true"
"strings are true"
"undefined is false"
"null is false"

But this:

[[1,2], [3,4]] ? "matrices are true" : "matrices are false"

... throws a TypeError: Unsupported type of condition "DenseMatrix". This one:

equal([[1,2], [3,4]], undefined)

... throws TypeError: Unexpected type of argument in function equalScalar (expected: number or bigint or string or boolean or BigNumber or Complex or Fraction, actual: identifier | undefined, index: 1). That is also surprising to me. This https://mathjs.org/docs/reference/functions/equal.html says, "Values null and undefined are compared strictly, thus null is only equal to null and nothing else, and undefined is only equal to undefined". That appears to imply that those calls to equal() return a false value, not throw an error.

It looks like this does good equality checks without throwing errors no matter the type of the arguments:

compareNatural([[1,2], [3,4]], undefined) == 0 ? "compareNatural matrix to undefined is 0" : "compareNatural matrix to undefined is not 0" 
compareNatural(undefined, undefined) == 0 ? "compareNatural undefined to undefined is 0" : "compareNatural undefined to undefined is not 0" 

You get:

"compareNatural matrix to undefined is not 0"
"compareNatural undefined to undefined is 0"

... but those are pretty cumbersome. Is this the right way to do it?

The specific problem where this came up for me was in allowing expression writers to check an object to see if a key has any value, and also ensure that the value attached to the key isn't null or undefined.

related:
#1051
#3129

[dvd101x]

You could try making your own function with the definition of truthy that you need, for example:

# if a Matrix has a size that is not empty, then 
isTruthy = typed({
    Matrix: f(x) = sum(x.size()) > 0,
    any: f(x) = x ? true : false
})

isTruthy([])  # false
isTruthy([1]) # true

If it fits your needs better, you could make it outside the parser and import

math.import({
    isTruthy: math.typed({
        Matrix: x => math.sum(x.size()) > 0,
        any: x => math.equalScalar(x, true)
    })})

isTruthy([])  # false
isTruthy([1]) # true

Currently the compare node operator doesn't support matrices, I guess there is no consensus of what a truthy matrix is.

mathjs/src/expression/node/ConditionalNode.js

Lines 16 to 42 in 50bd26c

	function testCondition (condition) {
	if (typeof condition === 'number' ||
	typeof condition === 'boolean' ||
	typeof condition === 'string') {
	return !!condition
	}
	if (condition) {
	if (isBigNumber(condition)) {
	return !condition.isZero()
	}
	if (isComplex(condition)) {
	return !!((condition.re || condition.im))
	}
	if (isUnit(condition)) {
	return !!condition.value
	}
	}
	if (condition === null || condition === undefined) {
	return false
	}
	throw new TypeError('Unsupported type of condition "' + typeOf(condition) + '"')
	}

[josdejong]

Thanks for bringing this up. It's indeed odd that equal([1,2,3], undefined) is not supported. For matrices, the equal function is evaluated elementwise, try equal([1,2,3], 2), which returns [false, true, false]. I would expect equal([1,2,3], undefined) to return [false, false, false] for consistency but it throws an error instead. And the same happens with null. We should fix that. Anyone able to help debug this issue?

To do what you are looking for though is different: see if a matrix is defined or not. I like David's example of creating an isTruthy function. It makes sense to me to add such a function to mathjs itself, what do you think @dvd101x?

[dvd101x]

The definition seems to differ, in python lists and np.arrays are treated differently. Where a list is truthy is not empty but a numpy array is truthy if it has only one element and it's truthy.

"yes" if [] else "no"    # no
"yes" if [0] else "no"   # yes
"yes" if [1] else "no"   # yes

import numpy as np
"yes" if np.array([]) else "no" 
# ValueError: The truth value of an empty array is ambiguous. Use `array.size > 0` to check that an array is not empty.

"yes" if np.array([0]) else "no"    # no
"yes" if np.array([1]) else "no"    # yes
"yes" if np.array([1, 1]) else "no"
# ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()

In julia all just throw the following

[] ? "yes" : "no" 
# TypeError: non-boolean (Vector{Any}) used in boolean context
1 ? "yes" : "no" 
# TypeError: non-boolean (Int64) used in boolean context

So it seems the more mathematical the language is, the more restrictive a boolean conversion becomes.

Maybe it makes sense to include isTruthy that in other languages is just handled by boolean but a lot of care needs to be chosen for what is a trruthy for each data type and what should be the error. Or reconsider what boolean actually does.

[herdrick]

Adding a function, ex. isTruthy(), which returns true or false and doesn't throw TypeErrors would help, but much cleaner would be to allow all values to be used everywhere a true or false is expected. Most dynamic languages support this, and encourage its use.

Yes, then it would need to be decided if lots of things like 0, [[0,0],[0,0]], and the empty string are truthy, but the experiences of other language designers can be guides to this. I think there's a lot of disagreement about this across languages.

One of the consequences of that is needing to add an idiomatic way to check for membership in objects and perhaps elsewhere. Maybe an in operator?

'some_value' in obj ? obj['some_value'] : 'foo'

That way the user could cleanly express that they want to know if obj['some_value'] is set, including to something falsy. I think this could be very handy in any case.

[josdejong]

Adding a function, ex. isTruthy(), which returns true or false and doesn't throw TypeErrors would help, but much cleaner would be to allow all values to be used everywhere a true or false is expected. Most dynamic languages support this, and encourage its use.

The thing is that mathjs evaluates functions/operators like equal and unequal elementwise when one of the input values is a matrix. So, these functions cannot work similar to most programming languages (where these functions just return a boolean). Therefore I think we'll need an isTruthy() function.

Now, the conditional operator condition ? truePart : falsePart does not yet support matrix input as condition, so we could think trough if what behavior we would like in that case. I cannot come up with a use case where you would like the conditional operator to work elementwise, so maybe it's fine to let the condition evaluate into a boolean. We could implement thise isTruthy() function, and use it in the conditional operator to ensure a consistent behavior.

Good idea to think through a way to check whether a property exists in an object. I think we should not use the in operator for this, since this is already in use to convert units like 2 inch in cm. Maybe via a function like exists(obj, "key").

[gwhitney]

I'd like to argue on @herdrick's side here, that we should prefer to convert to boolean any time appropriate, rather than have an "isTruthy" function.

• We already have a deepEqual function to disambiguate when you want elementwise equal or "holistic" equal, so I don't see that as an impediment.
• There aren't that many contexts in which mathjs requires booleans -- the leftmost operand of the conditional operator, and logical operators, but not much else, so I don't actually think it would be that hard to track them all down and make sure all types can be interpreted there.
• Anyhow, all that "truthy" means in other languages is "treated as true when used in a context that demands a boolean", and we already have the explicit constructor/converter boolean(), so I don't see how we could need another function in addition to that.
• It is possible, however, that mathjs needs some() and all() functions that work like sum() and prod() on matrices but with boolean operations or() and and() rather than + and *.
• Finally, on the behavior of conditional on a matrix left-hand side: I do think the consistent thing would be elementwise operation. All other operators (>, +, !, etc.) work like this. For a specific example with ?:, suppose you want to cap the entries of a matrix at 10 (leave smaller entries alone, but change larger ones to 10). I don't currently see a way to do this, e.g. min(M, 10) does not operate as a binary function elementwise, since min is already designed to operate on collections. But M > 10 ? 10 : M if it operated elementwise would be an elegant solution.

Someone also raises the status of what the truth values of strings are. That's already determined by the boolean() constructor/converter. The current primary philosophy in mathjs is that strings are just other representations for numbers, and those strings that aren't mathjs just pretty much doesn't deal with (well, there are some ways to do some things with them, but mathjs is quite limited on what can be done with general character strings, which is just fine in my book, as it is focused on numerical computation). Correspondingly, boolean() in essence operates by checking if the string represents a number, and if so, performs the boolean conversion on that number. Hence, boolean("3.3") is true, boolean("0") is false, and boolean("") throws a "can't convert to boolean" error.

There is currently an issue with complex numbers and booleans however: complex(4, i) ? "yes" : "no" happily returns "yes" (and complex(0, 0) ? "yes" : "no" returns no, but boolean(complex(4,i)) throws an error. But I think this last point is already on my plate to fix, with the long-delayed #3375 and friends...

[josdejong]

A function isTruthy may not be necessary though it may turn out to implement it to be used behind the scenes by all relevant functions to ensure unified behavior. Similar to how all relational functions use the nearlyEqual function behind under the hood.