空列表中的any（）和all（）？

本文介绍了空列表中的any（）和all（）？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

因此，Python 2.5将具有新的any（）和all（）函数。 www.python/dev/peps/pep-0356/ 如果seq中的任何值计算，则 any（seq）返回True true，否则为False。 all（seq）如果seq中的所有值都为true，则返回True，否则返回False。 我有一个问题：当seq是空的 列表时，这些函数应该返回什么？ 这是Guido的原始文章，他建议任何（）和所有（ ）： http：//www.artima。 com / weblogs / viewpost.jsp？thread = 98196 他为any（）和all（）的语义提供了这个示例代码： def任何（S）： $ S $ b for x in S： 如果x： 返回True 返回False def all（S）： for x in S： 如果不是x： 返回False 返回True 他指出将生成器函数与 这两个新功能： any（x> 42中的x表示S）＃如果S的任何元素是>则为真。 42 all（x！= 0表示S中的x）＃如果S的所有元素都非零，则为真 我完全在船上任何（）的语义。但是所有（）都困扰着我b $ b。如果all（）收到一个空列表，它将返回True，并且我不会像这样。对我来说，all（）应该是一个比任何（）， 更具限制性的功能，这让我很难看到any（）返回False但是所有（） $ b $的情况b返回True。 在all（）示例中，如果*中没有*，则没有值，那么 值都不能！= 0，恕我直言all（）应该返回False。 因此，我建议all（）应该像是用这样写的方式工作： def all（S）： ret_val = False $ S $ b for S： ret_val = True 如果不是x： 返回False 返回ret_val 评论？ PS我搜索过谷歌和Google网上论坛，试图找到 ，这可能是之前讨论过的。如果这已经讨论了，那么我已经讨论了道歉，我错过了它。 - Steve R. HastingsVita est st***@hastings www.blarg/~steveha

解决方案

Steve R. Hastings < ST *** @ hastings>写道：

在all（）示例中，如果*中没有*，那么值都不能！= 0，而且IMHO all（）应该返回False 。

这违背了全部的通常含义。比方说，数学逻辑。 通常，对于S中的所有X，PRED（x）为真。意思是： S中不存在X，所以PRED（x）是假的。 所以，所有（空序列）都应该是真的。 br />

" Paul Rubin" < HTTP：//ph****@NOSPAM.invalid>在消息中写道 news：7x ************ @ ruckus.brouhaha ...

" Steve R. Hastings" < ST *** @ hastings>写道：

在all（）示例中，如果*中没有*，那么值都不能！= 0，而且IMHO all（）应该返回False 。这违背了所有的通常含义。比方说，数学逻辑。 通常，对于S中的所有X，PRED（x）为真。意思是： S中没有X，所以PRED（x）是假的。

你怎么得到这个通常？东西？我同意这通常是作为列表中的短路循环实现的，它在第一个False值中突破了。但我不会很快将 实施的共同性等同于带有含义。 所以，所有（空序列）都应该为真。

应该是？或者通常证明是？ 在我看来，all（）的*含义*是列表中的每个元素断言 真正。但这是初步假设all（）为False，除非我测试每个值并发现它们为True。由于我假设False开始与一起使用，我在列表中没有得到与假设相矛盾的值，所以 all（[]）返回False。 似乎分辨率依赖于我们选择的初始条件，Balse或False。也许我们应该为此咨询更正式的数学 资源。 - Paul 如果是这样，有可能;如果是这样，那就是;但是，因为它不是， 它不是。那是'逻辑。'

[Steve R. Hastings]

所以，Python 2.5会有新的any（）和all（ ）函数。 http：//www.python。 org / dev / peps / pep-0356 / any（seq）如果seq中的任何值计算为true，则返回True，否则返回False all（ seq）如果seq中的所有值都为true，则返回True，否则返回False。 我有一个问题：当seq是空的列表时，这些函数应该返回什么？ 这里，从当前的开发主干来看，它们是_do_返回： Python 2.5a0（主干：43410M，2006年3月28日， 16:42:49）... 输入help，copyright，credit等等。或许可证或更多信息。

any（[]） False all（[]）

True 这是Guido'的原始文章，他建议任何（）和所有（）： www.artima/weblogs/viewpost.jsp?thread=98196 他为any（）和all（）的语义提供了这个示例代码： def any（S）： for x in S：如果x：返回True 返回False def all（S）：对于S中的x：如果不是x：返回False 返回True | 我完全熟悉any（）的语义。但所有（）都困扰着我。如果all（）收到一个空列表，它将返回True， 是。 我不喜欢这样。 艰难;-) 对我来说，all（）应该是一个比任何（）更具限制性的功能，它让我烦恼看一下any（）返回False但all（）返回True的情况。 有更深层次的原则在起作用：所以尽可能顺利地完成b&b ，减少应用于空的 集合的函数总是安排返回 减少操作的标识元素。这就是sum（[]）返回0的原因，对于 示例：0是添加的标识元素，意味着所有x的x + 0 = x 。 其他有用的身份来自于此，以及大多数减少操作的关联性 。例如，对于任何i> = 0，sum（seq）= sum（seq [：i]）+ sum（seq [i：]），即使i是这样的一个（或两个！） 右边的切片是空的。如果 sum（[]）不为0并且安排使其成为真，那​​就不是真的可以节省程序员 来处理一些特殊情况。 any（）的简化操作是逻辑 - 或者，False是逻辑 - 或者：x逻辑 - 或False = 标识元素x for all 布尔值x。 同样，all（）的缩减操作是逻辑 - 而且，True是 它的标识元素：x logical-和True = x for all Boolean x。 选择 空案例中的标识元素，即使`seq`为 为空也是如此： any（seq）=并非全部（对于seq中的x不是x） all（seq）= not any（seq中x不是x） 在all（）示例中，如果有*是* S中没有值，那么值都不能！= 0，而且IMHO all（）应该返回False。 这会破坏上面提到的一切。想想另一种方式： 如果所有（seq）都是假的，那么你是不是可以指出 a seq中的特定元素是假的？毕竟（双关语打算 ;-)），如果不是seq中的所有x都是真的情况，那么必须是某些x的 情况在seq是假的。但是如果seq为空，那么seq中没有x ，无论是真还是假，特别是没有x在 seq中'是假的。因为我们不能在seq中展示x，这样x是 false，说所有（seq）都是假的对你来说非常令人惊讶 在其他一些那天;-) 因此，我建议all（）应该像这样写一样工作： def all（S）： ret_val =错误 对于x中的x： ret_val = True 如果不是x：返回False 返回ret_val 评论？

这不会发生，原因有三：上面给出了几个;这个 也是用于通用和存在量词的惯例 应用于数学逻辑中的空集（并且大致相同 因为那里）;它与ABC语言中的现有技术相匹配（这是Python的前辈之一，它具有直接的句法支持 ，用于布尔表达式中的通用和存在量词）。

So, Python 2.5 will have new any() and all() functions. www.python/dev/peps/pep-0356/ any(seq) returns True if any value in seq evaluates true, False otherwise. all(seq) returns True if all values in seq evaluate true, False otherwise. I have a question: what should these functions return when seq is an empty list? Here is Guido''s original article where he suggested any() and all(): www.artima/weblogs/viewpost.jsp?thread=98196 He offered this sample code for the semantics of any() and all(): def any(S): for x in S: if x: return True return False def all(S): for x in S: if not x: return False return True And he pointed out how nifty it is to combine generator functions with these two new functions: any(x > 42 for x in S) # True if any elements of S are > 42 all(x != 0 for x in S) # True if all elements if S are nonzero I''m completely on board with the semantics for any(). But all() bothers me. If all() receives an empty list, it will return True, and I don''t like that. To me, all() should be a more restrictive function than any(), and it bothers me to see a case where any() returns False but all() returns True. In the all() example, if there *are* no values in S, then none of the values can be != 0, and IMHO all() should return False. Therefore, I propose that all() should work as if it were written this way: def all(S): ret_val = False for x in S: ret_val = True if not x: return False return ret_val Comments? P.S. I searched with Google, and with Google Groups, trying to find anyplace this might have been discussed before. Apologies if this has already been discussed and I missed it somehow. -- Steve R. Hastings "Vita est" st***@hastings www.blarg/~steveha

解决方案

"Steve R. Hastings" <st***@hastings> writes:

In the all() example, if there *are* no values in S, then none of the values can be != 0, and IMHO all() should return False.

That goes against the usual meaning of "all" in, say, mathematical logic. Usually, "for all X in S, PRED(x) is true" means: there does not exist X in S so that PRED(x) is false. So, all(empty sequence) should be true.

"Paul Rubin" <ph****@NOSPAM.invalid> wrote in message news:7x************@ruckus.brouhaha...

"Steve R. Hastings" <st***@hastings> writes:

In the all() example, if there *are* no values in S, then none of the values can be != 0, and IMHO all() should return False. That goes against the usual meaning of "all" in, say, mathematical logic. Usually, "for all X in S, PRED(x) is true" means: there does not exist X in S so that PRED(x) is false.

How do you get this "usually" stuff? I would agree that this is usually implemented as a short-circuited loop through the list, that breaks out at the first False value. But I would not be quick to equate "commonality of implementation" with "meaning". So, all(empty sequence) should be true.

"should be"? Or "usually turns out to be"? To my mind, the *meaning* of all() is that every element in the list asserts True. But this is with an initial assumption that all() is False, unless I test every value and find them to be True. Since I assume False to begin with, I get no values in the list to contradict the assumption, and so all([]) returns False. It would seem that the resolution rests on which initial condition we choose, False or True. Perhaps we should consult a more formal mathematical resource for this. -- Paul "If it was so, it might be; and if it were so, it would be; but as it isn''t, it ain''t. That''s logic."

[Steve R. Hastings]

So, Python 2.5 will have new any() and all() functions. www.python/dev/peps/pep-0356/ any(seq) returns True if any value in seq evaluates true, False otherwise.. all(seq) returns True if all values in seq evaluate true, False otherwise.. I have a question: what should these functions return when seq is an empty list? Here, from the current development trunk, is what they _do_ return: Python 2.5a0 (trunk:43410M, Mar 28 2006, 16:42:49) ... Type "help", "copyright", "credits" or "license" for more information.

any([]) False all([])

True Here is Guido''s original article where he suggested any() and all(): www.artima/weblogs/viewpost.jsp?thread=98196 He offered this sample code for the semantics of any() and all(): def any(S): for x in S: if x: return True return False def all(S): for x in S: if not x: return False return True ...| I''m completely on board with the semantics for any(). But all() bothers me. If all() receives an empty list, it will return True, Yes. and I don''t like that. Tough ;-) To me, all() should be a more restrictive function than any(), and it bothers me to see a case where any() returns False but all() returns True. There are deeper principles at work: so that endcases work out as smoothly as possible, a "reduction" function applied to an empty collection always arranges to return the identity element for the reduction operation. This is the reason that sum([]) returns 0, for example: 0 is the identity element for addition, meaning that x+0=x for all x. Other useful identities follow from this, and from the associativity of most reduction operations. For example, sum(seq) = sum(seq[:i]) + sum(seq[i:]) for any i >= 0, even if i is such that one (or both!) of the slices on the right-hand side is empty. That wouldn''t be true if sum([]) were not 0, and arranging to make it true saves programmers from having to deal with some otherwise special cases. The reduction operation for any() is logical-or, and False is the identity element for logical-or: x logical-or False = x for all Boolean x. Likewise the reduction operation for all() is logical-and, and True is the identity element for that: x logical-and True = x for all Boolean x. Examples of other useful identities that follow from picking the identity elements in the empty case, which hold even if `seq` is empty: any(seq) = not all(not x for x in seq) all(seq) = not any(not x for x in seq) In the all() example, if there *are* no values in S, then none of the values can be != 0, and IMHO all() should return False. That would break everything mentioned above. Think of it another way: if all(seq) is false, shouldn''t it be the case that you can point to a specific element in seq that is false? After all (pun intended ;-)), if it''s not the case that all x in seq are true, it must be the case that some x in seq is false. But if seq is empty, there is no x in seq that''s either true or false, and in particular there''s no x in seq that''s false. Since we can''t exhibit an x in seq such that x is false, saying that all(seq) is false would be very surprising to you on some other day ;-) Therefore, I propose that all() should work as if it were written this way: def all(S): ret_val = False for x in S: ret_val = True if not x: return False return ret_val Comments?

That won''t happen, for three reasons: several were given above; this is also the convention used for universal and existential quantifiers applied to empty sets in mathematical logic (and for much the same reasons there); and it matches prior art in the ABC language (which is one of Python''s predecessors, and which had direct syntactic support for universal and existential quantifiers in Boolean expressions).