Feature #12110: Create a method to avoid vacuous truth?

• Status: Open
• Assignee: -
• Target version: -

[rydlaw (Waldyr de Souza)]

I often find myself running into unexpected results when using #all? for example

[].all? { |e| false } # => true

Even though it's logically correct could we have a method that express the following?

foo.any? && foo.all?(&:bar)

[rydlaw (Waldyr de Souza)]

• Description updated (diff)

[rydlaw (Waldyr de Souza)]

• Subject changed from Can create a method to avoid vacuous truth? to Create a method to avoid vacuous truth?

[shevegen (Robert A. Heiler)]

Here is the biggest problem:

• What name would you give it? :)

[phluid61 (Matthew Kerwin)]

Robert A. Heiler wrote:

Here is the biggest problem:

• What name would you give it? :)

​I seem to recall someone suggesting 'any_and_all?' in the past. Can't remember if I just made that up, though.

[avit (Andrew Vit)]

Waldyr de Souza wrote:

I often find myself running into unexpected results when using #all? for example

[].all? { |e| false } # => true

If you expect all false, then why not use none?, is it not sufficient?

Even though it's logically correct could we have a method that express the following?

foo.any? && foo.all?(&:bar)

This also has edge cases, try: foo = [nil]

Matthew Kerwin wrote:

I seem to recall someone suggesting 'any_and_all?' in the past.

This makes sense and it's consistent with foo.any?(&block) && foo.all?(&block)

This is still surprising to me, it looks like a contradiction:

[].any? #=> false
[].all? #=> true

I would expect "all" to be a superset of "any": both should mean "at least one".
Is there a reason for the existing behaviour, or is it just history now?

[duerst (Martin Dürst)]

Andrew Vit wrote:

This is still surprising to me, it looks like a contradiction:

[].any? #=> false
[].all? #=> true

I would expect "all" to be a superset of "any": both should mean "at least one".
Is there a reason for the existing behavior, or is it just history now?

It's the way it works in Mathematics. But I'll try to explain it without using too much Mathematical terminology.

all? doesn't ask "at least one"?, but really "are all of those that are in the array true?". If there's no element in the array, then the condition is indeed true for all elements in the array.

Another way to try to understand this is to look at how these operations can be expressed by using reduce:

def any? (&block)
  reduce(q1) { |memo, e| memo or block.call(e) }
end

def all? (&block)
  reduce(q2) { |memo, e| memo and block.call(e) }
end

So both of these operations are map-reduce operations. The mapping is done with the block, converting array elements to true/false booleans. The reduction is 'or' for any? and 'and' for all?. Now the question for you is to figure out what we should put instead of q1 and q2. Hint: First make sure you get q1 and q2 right for arrays with actual elements. Then see what you get from the above definitions with empty arrays.

[In Mathematical terms, false is the neutral element of logical OR, and true is the neutral element of logical AND, the same way 0 is the neutral element of addition, and 1 is the neutral element of multiplication. Therefore, the sum of zero elements is 0, but the product of zero elements is 1.]

[sawa (Tsuyoshi Sawada)]

Martin Dürst wrote:

Andrew Vit wrote:

This is still surprising to me, it looks like a contradiction:

[].any? #=> false
[].all? #=> true

I would expect "all" to be a superset of "any": both should mean "at least one".
Is there a reason for the existing behavior, or is it just history now?

It's the way it works in Mathematics.

In natural language, universal quantification carries a presupposition that the domain is non empty; the meaning of "for all x in A, p(x)" is undefined when A is empty, just like "the king of the United States" is undefined. And whenever universal quantification is defined, the entailment holds: "for all x in A, p(x) → for some x in A, p(x)" (And the word "any" in a question is the same as "some" here). That is probably what Andrew Vit was mentioning. And that is where natural language and formal systems differ, which makes the latter a bit counter-intuitive.

[avit (Andrew Vit)]

Thanks Martin and Tsuyoshi,

Yes, all of this makes sense when you just look at it the right way.
Otherwise this basic equality wouldn't work either:

[].all? { true } == [].none? { false }

I'm not sure a new core method is justified anyway. It's easy to add ourselves
or even create a special implementation of enumerable:

# naive hack (!)
module Enumerable
  def nonempty
    dup.extend NonemptyIterators
  end
  
  module NonemptyIterators
    def all?
      !empty? && super
    end
    # ...
  end
end

[].all? { true }  # == true
[].nonempty.all? { true } # == false

I'm not sure I would like it to assume the natural language interpretation for me.
It might be enough that ruby core just provides the logic primitives.

[duerst (Martin Dürst)]

Tsuyoshi Sawada wrote:

In natural language, universal quantification carries a presupposition that the domain is non empty; the meaning of "for all x in A, p(x)" is undefined when A is empty, just like "the king of the United States" is undefined. And whenever universal quantification is defined, the entailment holds: "for all x in A, p(x) → for some x in A, p(x)" (And the word "any" in a question is the same as "some" here). That is probably what Andrew Vit was mentioning. And that is where natural language and formal systems differ, which makes the latter a bit counter-intuitive.

I agree that in natural language, expressions that are similar to universal quantification usually assume that the underlying set is not empty. But this isn't so much because that's how natural language works. It is more because natural language is used in context, and it's usually clear from context already that the underlying set is not empty. If it's known that the underlying set is empty, then statements with universal quantifications are simply not made, because they are not needed. This is different from Mathematics and programming, where we as much as possible don't want to treat the empty set as special.

[sawa (Tsuyoshi Sawada)]

Martin Dürst wrote:

But this isn't so much because that's how natural language works.

That is how natural language works. Presupposition (failure) is an essential part of natural language semantics. It is a matter of semantics, not pragmatics. Presupposition and implicature are different.

It is more because natural language is used in context

Natural language exists without context. Sentences can be judged to be syntactically correct or not and can be semantically interpreted irrespective of whether they make sense in context.

If it's known that the underlying set is empty, then statements with universal quantifications are simply not made, because they are not needed.

Lack of spontaneous data is no obstacle for interpreting them semantically. You can construct a sentence in your mind and judge it by introspection.

But what you wrote about formal system is right. I just wanted to clarify Andrew Vit's point.

[nobu (Nobuyoshi Nakada)]

• Description updated (diff)

Anybody proposed an optional parameter for the default value to #all? and #any? ?

[sawa (Tsuyoshi Sawada)]

Nobuyoshi Nakada wrote:

Anybody proposed an optional parameter for the default value to #all? and #any? ?

any? is not the issue. I don't think Waldyr de Souza wants to alter the behaviour:

[].any?{} # => false

I don't particularly like the original proposal, but if it is going to be adopted in any way, perhaps giving a new method would be appropriate. As pointed out by Martin, this is a case where formal systems and natural languages differ, but there is in fact an example where programming languages adopt concepts from both sides: "or" and "exclusive or". In natural language, when people just say "or", they (usually) mean "exclusive or", but in formal systems, "or" means "(inclusive) or". Since "exclusive or" is sometimes useful in programming, many programming languages do have both. The proposal is similar to this situation. The question is whether the use of foo.any? && foo.all?(&:bar) is frequent enough to be justified as another method.