Why does all() return True if the iterable is empty?

The sum of no numbers is 0.<p>The product of no numbers is 1.<p>The union of no areas (sets, …) is the empty area.<p>The intersection of no areas (sets, …) is the universal area.<p>The commonality here, is what element z can you add or remove from a list which won’t change the result?<p>We call the element that makes no change to the result, the “identity element”.<p>For y = sum of {x1,x2, … Xn, z},<p>We know z must be 0, if it has no impact on y. So the identity element for sum is 0.<p>So if y = sum of {}, we know we can insert the identity element without changing the result, and we know the sum of {0} is 0. The identity element itself.<p><i>So operations applied across lists return that operation’s identity element for an empty list.</i><p>—-<p>Ergo:<p>the identity element of “all” is “true”.<p>The identity element of “any” is “false”.<p>——<p>More fun:<p>The identity element for the resistance sum across parallel resistors, is the infinite ohm resister.<p>The identity element for the vector distance sum of a child making a sequence of jumps is the in-place jump.<p>—-<p>Getting meta with, oh hell, monads:<p>The identity element for C, the concatenation operator over lists, is the empty list {}.<p>Since all lists are concatenations of lists (down to empty &amp; unitary lists), we can view any operation Q over lists also as an operation over the concatenation of lists.<p>So any Q acts like a monad over list concatenation operations.<p>If Q = sum, then it is the monad that transforms concatenations of lists of numbers into the sum of those numbers.<p>If Q = all, then it is the monad that transforms concatenations of lists of truth values to the conjunction of the truth values in those lists.<p>With that view in place, we can see another reason why the identity of any operation Q is Q on an empty list Q{}<p>Because as a monad, Q applies over C, the concatenation of lists. The identity of C is {}, so the identity of Q must be Q{}.<p>Voila!<p>So we really shouldn’t define sum{} as 0, but define 0 as sum{}.<p>“0” is just a symbol. Sum{} is what it <i>is</i>.<p>0 <i>is</i> the sum of nothing.<p><i>So “True” IS the conjunction of nothing. It’s meaning IS all{}. It is the truth of “no requirements”.</i>

Given:<p><pre><code> all(xs + ys) == (all(xs) and all(ys)) </code></pre> And:<p><pre><code> xs == xs + [] </code></pre> We have:<p><pre><code> all(xs) == all(xs + []) == all(xs) and all([]) </code></pre> Which implies:<p><pre><code> all([]) == True.</code></pre>

If all marbles in a bag are black, and you take one marble out, are all marbles in the bag still black?<p>The only logical answer is yes. It would be rather absurd to make an exception for the case where you start with one marble in the bag. That would make logical reasoning extremely cumbersome, for no benefit whatsoever.

<p><pre><code> def all(L): for i in L: if not L: return False return True </code></pre> Seems quite clear when presented that way. Same with `any`.<p>&gt; In logic, this is called the principle of bivalence: there are only two values that a proposition can have, true or false. But Python has None, many other programming languages have null or nil, and Zen has mu. Maybe adding another value would help?<p>If `all` were in Python v1 it would have thrown an exception when called with an empty list. (Said jokingly, or is it?)

Every one (all) of the set of zero elements is true. It&#x27;s not counterintuitive or inconsistent, this is the only way that makes sense.<p>The complement is also consistent. None of the set of zero elements are true. So there aren&#x27;t <i>any</i> true&#x27;s.<p>They&#x27;re symmetrical cases, and negation turns them into each other. Not-any-true is equivalent to all-false, and not-all-true is equivalent to any-false.

&gt; In logic, this is called the principle of bivalence: there are only two values that a proposition can have, true or false. But Python has None, many other programming languages have null or nil, and Zen has mu. Maybe adding another value would help?<p>Hoare labeled his invention of null a &quot;billion dollar mistake&quot;. SQL NULL can&#x27;t be far behind. Boolean logic has 4 unary and 16 binary operators, ternary logic has 27 and 19683, respectively. That&#x27;s not helpful, that&#x27;s intractable!<p>I cannot recommend C. J. Date&#x27;s books enough.

<p><pre><code> all = foldr and True any = foldr or False</code></pre>

I posted in a political thread once...<p>&quot;Re-joining the EU would give the UK all the benefits of EU membership as well as all the benefits of Brexit too.&quot;

I miss using the Midje testing library for Clojure, as it has the &#x27;truthy&#x27; and &#x27;falsey&#x27; functions. It reduced these variously bivalent and trivalent conditions into binary in a way that would do Stephen Colbert proud (<a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20150121223555&#x2F;http:&#x2F;&#x2F;www.merriam-webster.com&#x2F;info&#x2F;06words.htm" rel="nofollow noreferrer">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20150121223555&#x2F;http:&#x2F;&#x2F;www.merria...</a>) Of course you or I can add such to what ever language we are using that supports actual functions -- or smash some abstraction of truthiness into those that don&#x27;t.

Humans have trouble with this because our brains cannot let go of the context surrounding a question. For example, a logician may find it funny to walk up to a police officer and say &quot;all of the hookers in my trunk are dead.&quot; That is technically true, even though there are no bodies in his trunk. But the brain of the police officer is awash with why someone would be talking about dead hookers <i>at all</i>. Surely something is going on! I would not expect that logician to have a great day.<p>So we read things about bags with no marbles and bearded kings of France and pink goblins and we think someone is taking the piss out of us, because we can&#x27;t let go of the context behind those statements. Why are we talking about goblins <i>at all</i>?<p>All models are wrong. Some models are useful. If you&#x27;re getting hung up on how it just <i>doesn&#x27;t make sense</i> that &quot;A -&gt; B&quot; is always true when A is false (which is really the same issue), you have to realize that it&#x27;s not meant to be intuitive, it&#x27;s meant to be <i>useful</i>. And the theory of predicate logic where ALL([]) == TRUE is <i>much</i> more useful than the one where it&#x27;s FALSE or even NULL. It&#x27;s more useful because TRUE is the identity element of the monoid AND and ALL is the unary set-aggregation of AND. There really cannot be any other choice if you want your theory to fit in with the rest of mathematics and logic, which a useful theory must. It&#x27;s internally consistent, useful, and really does make deep sense if you are able to let go of context-laden real-world examples.<p>You should not rely on English sentences making sense to be a good metric of whether a model is useful or not. Consider:<p><pre><code> Dogs must be carried on escalators. </code></pre> You don&#x27;t have a dog. Are you allowed on the escalator? Of course you are. This is, in fact, a perfect example of why Your_Dogs.All(is_carried) must be TRUE if Your_Dogs is empty.<p><pre><code> Hard hats must be worn in work areas. </code></pre> You don&#x27;t have a hard hat. Are you allowed in the work area? No! How can you tell the difference between these two situations? Only from context. Yet you can see how easy it would be to form the 2nd sentence as an (erroneous) example of &quot;Enforce(HardHats.All(are_worn))&quot;, but it&#x27;s <i>not that</i>. It&#x27;s more like &quot;Enforce(People.Where(in_work_areas).All(have_hard_hat_on))&quot; -- if there is someone in a work area, then they must have a hard hat on. But if there&#x27;s nobody in the work area, no rule is being broken! Again we actually see ANY([]) having to be true here.<p>When you come up with weird-sounding examples where you&#x27;re sure All([]) must be False, you&#x27;re just poisoning your intuition with unhelpful context.

1 is the multiplicative identity<p>0 is the additive identity<p>all([]) is True<p>any([]) is False

It helps to think in terms of `any` first:<p><pre><code> any([], predicate) =&gt; false </code></pre> This is plainly obvious, because it is illogical to say &quot;the predicate is true for at least one member of the empty set&quot;.<p>If we can agree on that, then all([], predicate) must be true, because the complement of all(list, predicate) is any(list, predicate&#x27;)<p>The naive assumption is that the complement of all(list, p) is all(list, p&#x27;), but this is demonstrably false, because in the case of an empty list: all([], e =&gt; e) and all([], e =&gt; !e) would both return the same value.<p><pre><code> &gt; [[], [true], [false]].map(s =&gt; s.every(e =&gt; e) == !s.every(e =&gt; !e)) [ false, true, true ] </code></pre> Instead, its proper complement is any(list, p&#x27;), which means that all(list, p) = !any(list, p&#x27;)<p><pre><code> &gt; [[], [true], [false]].map(s =&gt; s.every(e =&gt; e) == !s.some(e =&gt; !e)) [ true, true, true ] </code></pre> So, for all([], p) to be false, any([], p&#x27;) would have to be true, which makes even less sense than all([], p) =&gt; true.

If you have some set S and predicate P(x) is true for every x in S, ∀x∈S:P(x), then you can partition the set into pieces S₁ ∪ S₂ ∪ ... u Sₙ. such that ∀x∈S₁:P(x) ∧ ∀x∈S₂:P(x) ∧ ... ∧ ∀x∈Sₙ:P(x).<p>If the quantified predicate were to be false for an empty set, then the above breaks if any of the partitions are empty. A property can then be true when quantified over a set such that it&#x27;s not true over subsets, which is inconsistent.<p>A similar problem occurs with products. We can use Lisp:<p><pre><code> (* 2 3 4) -&gt; 24 </code></pre> We would like to be partition that into partial products. Here, we have a partition of length 1:<p><pre><code> (* (* 2 3) (* 4)) -&gt; 24 </code></pre> So we want (* N) -&gt; N. And empty partitions:<p><pre><code> (* (*) (* 2 3) (*) (* 4)) -&gt; 24 </code></pre> For that to work we need:<p><pre><code> (*) -&gt; 1</code></pre>

In any discussion on languages like this, I feel the Wat discussion is always appropriate: <a href="https:&#x2F;&#x2F;www.destroyallsoftware.com&#x2F;talks&#x2F;wat" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.destroyallsoftware.com&#x2F;talks&#x2F;wat</a>

I think a key point is that (correct me if I&#x27;m wrong here) in predicate logic you can rewrite<p><pre><code> ∀x Fx </code></pre> As<p><pre><code> Not ∃x (not Fx) </code></pre> Ie: &quot;for all x, f(x)&quot; implies the opposite of &quot;there exists an x where not F(x)&quot;.<p>People seem to have less of a problem with<p><pre><code> Not ∃x (not Fx) </code></pre> when the universe is x is empty.<p>I usually explain it to junior developers by telling them to imagine it&#x27;s a for loop over a list that returns true&#x2F;false if it finds a value that doesn&#x27;t match what&#x27;s expected, and the opposite of it reaches the end of the list.

FTA:<p>&gt; But it is interesting how even extremely practical twenty-first century programming can get drawn into millennia old philosophical controversies, intentionally or not.<p>This turns out to happen a lot. I can&#x27;t find the source right now, but there was a good essay I read ages ago about how questions that are abstract and hand-waveable in day-to-day life become cornerstones of architecture rapidly in computer science and software engineering. The cow in the field epistemological puzzle [<a href="http:&#x2F;&#x2F;www.philosophical-investigations.org&#x2F;2021&#x2F;09&#x2F;the-cow-in-field-and-riddle-of-what-do.html" rel="nofollow noreferrer">http:&#x2F;&#x2F;www.philosophical-investigations.org&#x2F;2021&#x2F;09&#x2F;the-cow-...</a>] maps directly to the nature of proving code is &quot;correct&quot; by testing (and any practicing coder has a story of false-positive or false-negative tests, as well as times they identified one of those by a &quot;gut check&quot; telling them &quot;That result... doesn&#x27;t feel right; I should investigate further&quot;). Similarly, the philosophical question of &quot;sameness&quot; or &quot;equality&quot; ends up concretized over and over again in language design; there&#x27;s a reason languages end up with so many ways to say &#x27;equals&#x27;, and it&#x27;s because the underlying question of what it means for two things to be the same thing is legitimately philosophically complicated!

I had to deal with this problem in our product, which has a visual programming language. I opted to throw an exception if, for whatever reason, &quot;all()&quot; receives an empty list! I had forgotten I&#x27;d done that. There&#x27;s no explanation for it in the code.<p>As I sit here justifying my own reasoning, though, it sort of makes sense. For ordinary people (for whom this product is supposed to be for), I figure if they put in nothing, that was probably just a mistake.

Clojure does the same thing:<p><pre><code> &gt; clj Clojure 1.11.1 user=&gt; (every? true? []) true user=&gt; (every? false? []) true user=&gt; (every? true? nil) true user=&gt; </code></pre> Also:<p><pre><code> user=&gt; (true? []) false </code></pre> In English, an empty list is `false`, but any predicate on an empty list is `true`.<p>So I believe the logic is the same as Python.<p>Logic article on this in Wikipedia: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Vacuous_truth" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Vacuous_truth</a>

I remember explaining this rather simply, the same question actually. Look at the implementation.<p><pre><code> def all(it): for v in it: if not v: return False return True </code></pre> If there are no items, it returns True.<p><pre><code> def any(it): for v in it: if v: return True return False </code></pre> If there are no items, it returns False.<p>There&#x27;s no need for fancy mathematical or &quot;marbles in a bag&quot; explanations here. Just look at the code.

&gt; <i>in the new logic, you can’t soundly argue that “all dogs are mammals; all mammals have fur; therefore, all dogs have fur” because one person shaving their dog suddenly makes “all mammals have fur” untrue.</i><p>Isn&#x27;t this just a problem with an unclear definition of &quot;having fur&quot;? Is the article saying that the old logic would hand-wave this problem away because it&#x27;s about &quot;universals and essences&quot;?

I&#x27;m a bit confused by this:<p>&gt; “All stonemen are made of stone” is true by definition, but “no men are made of stone” is also true and seems to contradict it.<p>I don&#x27;t see how “no men are made of stone” contradicts “All stonemen are made of stone”.<p>&quot;stonemen&quot; are not the same as &quot;men&quot;.<p>English isn&#x27;t my first language so maybe I don&#x27;t know what a stoneman is (and google failed me), but I assumed it is a statue?

claims on empty sets can be vacuously true.<p>&quot;All elephants in my pocket are made of dark matter&quot;. Sure, all _zero_ of them, so it&#x27;s &#x27;technically correct&#x27;.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Vacuous_truth?useskin=vector" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Vacuous_truth?useskin=vector</a>

I actually used this in my F# code yesterday. The forall function does the same and it was exactly what I needed.<p><a href="https:&#x2F;&#x2F;fsharp.github.io&#x2F;fsharp-core-docs&#x2F;reference&#x2F;fsharp-collections-listmodule.html#forall" rel="nofollow noreferrer">https:&#x2F;&#x2F;fsharp.github.io&#x2F;fsharp-core-docs&#x2F;reference&#x2F;fsharp-c...</a>

I think the analysis is really interesting, but I suspect it’s quite possible that this behaviour is just a result of optimising the implementation than GVR taking sides in a 2,500 year old philosophical debate.<p>Both implementations of all() and any() short-circuit by returning as soon as a fasly element in all or a truthy element in any is iterated over.<p>The origin of these two functions seems to be this post: <a href="https:&#x2F;&#x2F;www.artima.com&#x2F;forums&#x2F;flat.jsp?forum=106&amp;thread=98196" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.artima.com&#x2F;forums&#x2F;flat.jsp?forum=106&amp;thread=9819...</a><p>Guido makes no comment on empty iterables, but does comment on the final implementation needing to be efficient. It’s possible this behaviour is just the engineering trade off made for a slightly more efficient implementation.<p>The initial commit of these two functions - <a href="https:&#x2F;&#x2F;github.com&#x2F;python&#x2F;cpython&#x2F;commit&#x2F;96229b191814556622b575fd320e822f918f355a?diff=unified">https:&#x2F;&#x2F;github.com&#x2F;python&#x2F;cpython&#x2F;commit&#x2F;96229b191814556622b...</a> - is exactly as Guido’s suggestion, but does include a test case for empty iterables for both functions so we know it wasn’t overlooked.

I like `all = foldr and True` as others have pointed out.<p>But I think I have a more convincing example of why it can&#x27;t be the other way around:<p><pre><code> all (&gt;5) [6,7,8] all (&gt;5) ([6,7,8] ++ []) (all (&gt;5) [6,7,8]) &amp;&amp; (all (&gt;5) []) (True &amp;&amp; False) False</code></pre>

Think often when people want&#x2F;expect this to be false, they’re combining two checks: that there’s an item and all items are true. This covers doing an operation on “ready” items. Instead:<p><pre><code> if items and all(items):</code></pre>

It&#x27;s the identity element of the monoid, no?<p>Similarly, the product of an empty list should be 1.

Regardless of whether you thing the return value should be True or False, this behavior violates the Principle of Least Astonishment [0] for a significant number of people.<p>Such violations in software inevitably lead to bugs that could have been avoided. The real question in my mind isn&#x27;t what the return value should be. The question is &quot;How can this problem be wholly avoided?&quot;<p>Some have suggested requiring a default return value when the iterator argument is empty. Others have suggested throwing an error. Perhaps others will suggest the all() function shouldn&#x27;t exist, although that may be throwing the baby out with the bathwater.<p>[0] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Principle_of_least_astonishment" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Principle_of_least_astonishmen...</a>

The problem isn&#x27;t with all([]) -&gt; True, the problem is the if [] -&gt; False.<p>[] exists. It happens to be empty, but it is neither a False nor a None. Therefore it should be a True if applying truthiness to it. IMO, any expression which does not result in an actual False or None should be judged as True.<p>- edit -<p>On second thought, all([]) -&gt; True is also a poor choice, same in Ruby. The idea of judging an empty collection as having all items being any value is flawed, since there are no items to measure. It is on par with 1 &#x2F; 0.<p>This is fun: in both Ruby and Python...<p>[].all? -&gt; true<p>all([]) -&gt; True<p>[].any? -&gt; false<p>any([]) -&gt; False<p>So both languages agree that all elements of any empty collection are true, but if you ask them if any of the elements are true, they deny it. So they are all true while also not having any true elements.

Because of this <a href="http:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Vacuous_truth" rel="nofollow noreferrer">http:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Vacuous_truth</a>

Why try to reduce assertions made against something that doesn&#x27;t exist down to a boolean result? Clearly the answer is undefinable

I feel like I’d just make a poll and pick the least surprising option if there’s a clear winner.<p>But maybe that’s why I’m not a language developer.

In logic class, these were axiomatically equivalent<p><pre><code> for all x. P(x) not (exists x. not P(x))</code></pre>

Case of the “Vacuous truth”

The empty set is vacuously true for any properties with elements.

<p><pre><code> all([x]+x)</code></pre>

(2020)

The present king of France is bald.

A man goes into court not sure how he got there or what he&#x27;s accused of. The judge starts saying the opening formalities. &quot;If and only if every member of the jury is convinced you are guilty then this court will convict you.&quot; The man looks around. &quot;Your honor, there are no members of the jury.&quot; The judge slams the gavel hard. &quot;Guilty&quot;. That&#x27;s the trivial case.

<p><pre><code> &gt; all([]) True &gt; any([]) False </code></pre> Not very consistent philosophy in that case. Surely if &#x27;all&#x27; is True then &#x27;any&#x27; got to be too?

“Are there any items in this list that are true? No? Ok, then False”<p>I don’t care about any fancy philosophy. What’s important is what kind of operation you want for when implementing algorithms, and False is what I always want in cases where I do “all”.