Pourquoi ne Stream.allMatch() renvoie true pour un vide stream?

Mon collègue et j'ai eu un bug qui était dû à notre hypothèse selon laquelle un vide de flux d'appel allMatch() serait de retour false. 

if (myItems.allMatch(i -> i.isValid()) { 
    //do something
}

Bien sûr, il est une sorte de notre faute de prise en charge et de ne pas lire de la documentation. Mais ce que je ne comprends pas, c'est pourquoi la valeur par défaut allMatch() comportement pour un vide de flux retours true. Quel a été le raisonnement pour cela? Comme le anyMatch() (qui contrairement renvoie false), cette opération est utilisée de manière impérative qui s'écarte de la monade et probablement utilisé dans un if déclaration. Compte tenu de ces faits, est-il une raison pourquoi avoir allMatch() par défaut pour true sur un vide stream être souhaitable pour la majorité des usages?

  • C'est un peu bizarre. Nous nous attendons à ce que si allMatch retourne true alors devrait anyMatch. En outre, pour la vides cas, allMatch(...) == noneMatch(...) qui est aussi bizarre.
  • Wikipédia dit que c'est la convention: en.wikipedia.org/wiki/Universal_quantification#The_empty_set
  • Juste un petit aparté sur la syntaxe: au lieu d'écrire votre prédicat i -> i.isValid(), vous pouvez écrire Foo::isValid (où Foo est quelle classe vous êtes en streaming, bien sûr)
  • "Cette opération est utilisée de manière impérative qui s'écarte de la monade" - je doute que ces facteurs dans toute décision.
InformationsquelleAutor tmn | 2015-05-13
  1. 92

    Ceci est connu comme vides de sens, de vérité. Tous les membres d'un regroupement vide satisfaire votre condition; après tout, pouvez-vous point à un autre qui ne l'est pas? De même, anyMatch renvoie la valeur false, parce que vous ne pouvez pas trouver un élément de votre collection qui ne correspond pas à l'état. Ceci est source de confusion pour beaucoup de gens, mais il s'avère être le plus utile et de manière cohérente pour définir "tout" et "tous" pour vide ensembles.

    • Eh ben, je déteste la logique booléenne. Je pense que j'ai eu l'idée de ce que vous dites. L'absence de négatifs est positif, mais l'absence de résultats positifs n'est pas négatif.
    • De la même façon la valeur du produit d'un ensemble vide de nombres est 1 tandis que la somme d'un ensemble vide de nombres est 0. Ils sont les éléments neutres pour la multiplication ou l'addition. Dans le cas de booléens-vous que True and x = x et False or x = x donc si vous généralisez and et or de séquences (c'est ce que all et any sont), vous vous retrouvez avec True et False pour le caisson vide, c'est à dire qu'ils respectifs éléments neutres.
    • tests pour l'absence de résultats positifs, allMatch tests pour l'absence de négatifs.
    • Notez que de cette façon vous pouvez faire de belles choses comme De Morgan, de la loi: stream.allMatch(prédicat) est le même que !flux de données.anyMatch(prédicat.annuler()). De même, !flux de données.allMatch(prédicat.annuler()) est le même que le flux de données.anyMatch(prédicat).
    • "pouvez-vous point à un autre qui ne l'est pas?"... Je peux dire la même chose pour l'autre, "pouvez-vous point à celui qui n'en a?" J'accepte le concept de vides de sens, la vérité peut parfois être utile, mais cet argument est basé sur une erreur (l'Affirmation du conséquent)
    • Vous pouvez dire "pouvez-vous point à celui qui n'en a", et c'est tout à fait valable,, mais ce que cela signifie, c'est que tous les membres de la collection ne parviennent pas à satisfaire à la condition. Tous les membres de la collecte de satisfaire à la condition, et tous les membres de la collection ne parviennent pas à satisfaire à la condition. Ce sont les différents états de "il est faux que tous les membres de la collecte de satisfaire à la condition". Comme je l'ai dit, c'est déroutant.
    • Comme pour l'affirmation du conséquent, si vous avez une définition précise de "tout" dans l'esprit, pour qui "tous les satisfaire état -> la non-existence de l'élément qui ne parvient pas à satisfaire la condition" est une façon implicitement, le post peut sembler comme l'affirmation du conséquent. Du point de vue logique, c'est une bidirectionnel implication en raison des définitions de "tous" et "toutes" et les lois De De Morgan, pour les quantificateurs.
    • Ah, l'énoncé "Tous les éléphants dans la chambre rose" est presque toujours vrai.

    InformationsquelleAutor user2357112
  2. 6

    Quand je l'appelle list.allMatch (ou de ses analogues dans d'autres langues), je veux détecter si tous les éléments de list ne correspond pas aux prédicat. Si il n'y aucun élément, aucun pourrait ne pas correspondre. Mon suivant la logique de choisir des articles et s'attendent à avoir égalé le prédicat. Si la liste est vide, je vais prendre aucun des éléments et de la logique sera toujours le son.

    Que si allMatch retourné false pour une liste vide?

    Mon simple logique serait un échec:

     if (!myList.allMatch(predicate)) {
   throw new InvalidDataException("Some of the items failed to match!");
 }
 for (Item item : myList) { ... }

    Je vais avoir besoin de vous rappeler de remplacer le chèque avec !myList.empty() && !myList.allMatch().

    En bref, allMatch retour true pour une liste vide n'est pas seulement logiquement son, il se trouve aussi sur la bonne chemin d'exécution, nécessitant moins de contrôles.

    • vous signifiait probablement if (!allMatch)
    InformationsquelleAutor 9000
  3. 6

    Voici une autre façon de penser à ce sujet:

    allMatch() est à && ce sum() est à +

    Envisager la suite logique des énoncés:

    IntStream.of(1, 2).sum() + 3 == IntStream.of(1, 2, 3).sum()
IntStream.of(1).sum() + 2 == IntStream.of(1, 2).sum()

    Ce sens, car sum() est juste une généralisation de +. Cependant, qu'advient-il lorsque vous supprimez un élément de plus?

    IntStream.of().sum() + 1 == IntStream.of(1).sum()

    Nous pouvons voir qu'il est logique de définir IntStream.of().sum(), ou la somme d'une séquence vide de nombres, d'une manière particulière. Cela nous donne l'identité "élément" de la sommation, ou la valeur qui s'ajoute à quelque chose, n'a pas d'effet (0).

    Nous pouvons appliquer la même logique à Boolean algèbre.

    Stream.of(true, true).allMatch(it -> it) == Stream.of(true).allMatch(it -> it) && true

    De manière plus générale:

    stream.concat(Stream.of(thing)).allMatch(it -> it) == stream.allMatch(it -> it) && thing

    Si stream = Stream.of() ensuite, cette règle doit s'appliquer. On peut utiliser l'identité "élément" de && de résoudre ce problème. true && thing == thing, donc Stream.of().allMatch(it -> it) == true.

    InformationsquelleAutor Hans
  4. 3

    Il ressemble à la base, c'est l'induction mathématique. Pour l'informatique, une application de ce qui pourrait être une base de cas d'un algorithme récursif.

    Si le flux est vide, la quantification est dit être vacuously satisfait et est toujours vrai. Oracle Docs: le Flux des opérations et de pipelines

    La clé ici est qu'il est "vacuously satisfaits" qui, par nature, est quelque peu trompeur. Wikipedia a une bonne discussion à ce sujet.

    Dans les mathématiques pures, vacuously vrai déclarations ne sont généralement pas d'intérêt par eux-mêmes, mais souvent, elles se posent comme le cas de base de preuves par induction mathématique. Wikipédia: Vides De Sens, De Vérité

    InformationsquelleAutor Nathan