[Résolu] Fonction NB.SI - Résultat différent sur 2 versions différentes

[Sudo]

Bonjour,

Fidèle lecteur de votre site, je viens aujourd'hui faire appel à vous pour un problème sur lequel je n'ai trouvé aucune information.
J'utilise la version LO 7.2.7.2 sous Windows 10 sur un PC équipé d'un processeur i5 et souhaite passer sur un PC équipé d'un processeur i7 sur lequel tourne LO 24.2.7.7.2 sous Windows 11.
J'utilise la fonction nb.si (C1:C6;"<>") pour trouver le nombre de cellules non vides; C1:C6 contient des formules qui peuvent donner "".
Sur l'exemple joint le premier PC calcule 4 en C8, ce qui est correct, mais le second calcule 6 (je ne peux évidemment pas le joindre).
En B8, sur des cellules non calculées, le second PC trouve bien 4 !

Tous les paramètres de configuration de LO sont les mêmes (j'ai fait une copie du fichier du premier ordinateur vers le second).

Avez-vous une idée de l'origine de cette bizarrerie?

Merci d'avance.

[micmac]

Bonjour,

Le titre de votre question n'est pas assez explicite ou ne reflète pas le problème que vous décrivez :
<Fonction nb.si - Changement de version>
Nous l'avons donc modifié. En effet, lors d'une recherche, ce sujet risquait de passer inaperçu et donc de ne pas aider d'autres personnes ayant le même problème que vous. Des termes implicites comme macro, aide, problème ou OpenOffice n'ont pas besoin d'être mentionnés.

Voici quelques astuces pour avoir un titre optimum : viewtopic.php?p=1002#p1002

La prochaine fois, pensez à bien choisir les termes du titre de votre question. N'oubliez pas qu'un titre clair et précis augmente vos chances d'obtenir des réponses plus rapidement.

Merci de votre collaboration pour nous aider à rendre optimale la qualité de ce forum.

[tintin]

Bonjour,

Sur OpenOffice 4.1.15 ça semble fonctionner :
.

Sudo.gif

.
Sur LibO 24.2.7, rien de satisfaisant chez moi. Il reste à trouver le loup sur LibO.

[Jean-Louis Cadeillan]

Bonsoir,
Sous Win 7, même problème (valeur 6 au lieu de 4 dans l'exemple) avec Libo 24.2.7.2 et 7.3.7.2, mais pas avec 6.3.1.
Pas trouvé de bogue récent sur ce point (mot-clé COUNTIF) ; voir ici.
Contournements possibles (en C8) :

Code : Tout sélectionner

=NB(C1:C6)

Code : Tout sélectionner

=SOMMEPROD(C1:C6<>"")

Code : Tout sélectionner

=NB.SI(C1:C6;">0")

Code : Tout sélectionner

=SOMME(C1:C6<>"")

cette dernière en validation matricielle.
Cordialement,
Jean-Louis

[Jeff]

Bonjour à tous,

Contournements possibles

J'ajouterai également :

Code : Tout sélectionner

=NB.SI(C1:C6;"<>"&"")

(à tester, je n'ai pas LibO d'installé)

A +

[Sudo]

Bonjour

Merci pour ces réponses rapides autant que pertinentes.

Je suis vraiment très surpris par le fonctionnement manifestement instable de cette formule, pourtant bien simple.
J'espère que quelqu'un pourra proposer une solution au problème.

En ce qui concerne les solutions de contournement:
- NB (C1:C6) fonctionne mais (évidemment) uniquement si les cellules non vides contiennent des nombres,
- NB.Si (C1:C6;"<>"&"") ne fonctionne pas.

Je pense que les cellules calculées dont le résultat est "" ne sont pas consdérées comme vides car elles contiennent une formule.

Cordialement.

[Jean-Louis Cadeillan]

Bonjour,

Je suis vraiment très surpris par le fonctionnement manifestement instable de cette formule

C'est une application de la loi de Lubarsky…

J'espère que quelqu'un pourra proposer une solution au problème.

D'autant mieux que tu prendras le temps de décrire le problème en question sur la liste Bugzilla des bogues dédiée à LibO :
https://bugs.documentfoundation.org/

Je pense que les cellules calculées dont le résultat est "" ne sont pas considérées comme vides car elles contiennent une formule.

C'est le comportement de NBVAL(), qui n'est effectivement pas attendu dans NB.SI().
Pour t'aider dans ta démarche de déclaration du dysfonctionnement, voici un récapitulatif du comportement de différentes versions pour différentes formules :

Sudo_20241129_JLC01.jpg

À noter que les formules 3 et 4 dysfonctionnent dans l'exemple, mais donneraient le bon résultat, s'il n'y avait que des valeurs numériques.
La colonne autre recense les formules fonctionnelles, les autres ont été figées par copier/coller des valeurs correspondantes. Cette colonne peut servir à tester d'autres versions…
Cordialement,
Jean-Louis

[cwolan]

Bonjour,

Je pense que les cellules calculées dont le résultat est "" ne sont pas considérées comme vides car elles contiennent une formule.

C'est le comportement de NBVAL(), qui n'est effectivement pas attendu dans NB.SI().

Cf. tdf#148948 (Wrong "Empty Cell" match with "=" and "<>" criterion).

[Sudo]

Bonjour et merci pour ces compléménts fort intéressants.

J'ignorais la loi de Lubarsky, mais j'ai maintes fois constaté son exactitude.

Le tableau de Jean-Louis démontre que le bug existe depuis la 7.3.7 (ou avant) sortie le 15/10/2022.

J'ai suivi le lien donné par cwolan; le texte est pour moi assez esotérique mais je crois avoir compris que le bug a été signalé en 2022 et qu'il est sensé avoir été résolu.

En ce qui me concerne, j'ai remplacé la dernière version par la 7.2.7.2 et tout va bien.

Cordialement.

[Sudo]

Bonjour,

Fidèle lecteur de votre site, je viens aujourd'hui faire appel à vous pour un problème sur lequel je n'ai trouvé aucune information.
J'utilise la version LO 7.2.7.2 sous Windows 10 sur un PC équipé d'un processeur i5 et souhaite passer sur un PC équipé d'un processeur i7 sur lequel tourne LO 24.2.7.7.2 sous Windows 11.
J'utilise la fonction nb.si (C1:C6;"<>") pour trouver le nombre de cellules non vides; C1:C6 contient des formules qui peuvent donner "".
Sur l'exemple joint le premier PC calcule 4 en C8, ce qui est correct, mais le second calcule 6 (je ne peux évidemment pas le joindre).
En B8, sur des cellules non calculées, le second PC trouve bien 4 !

Tous les paramètres de configuration de LO sont les mêmes (j'ai fait une copie du fichier du premier ordinateur vers le second).

Avez-vous une idée de l'origine de cette bizarrerie?

Merci d'avance.

[Jean-Louis Cadeillan]

Bonjour,
Je ne comprends cette citation in extenso de ton premier message.
Pourtant cwolan t'a donné le lien du rapport de bogue lié à ta demande initiale.

J'ai suivi le lien donné par cwolan; le texte est pour moi assez ésotérique mais je crois avoir compris que le bug a été signalé en 2022 et qu'il est sensé avoir été résolu.

Je n'avais pas pris le temps de répondre à cette phrase, mais j'ai l'impression que tu as mal compris les commentaires de cette issue.
LibreOffice s'est mis en conformité avec la norme Oasis ODF 1.3, comme Excel, qui dit en substance :

An empty cell is neither zero nor the empty string, and an empty cell can be distinguished from cells containing values (including zero and the empty string). An empty cell is not the same as an Error, in particular, it is distinguishable from the Error #N/A (not available).

ce qui pourrait se traduire par :

Une cellule vide n'est ni zéro ni une chaîne vide, et une cellule vide peut être distinguée des cellules contenant des valeurs (y compris zéro et la chaîne vide). Une cellule vide n'est pas la même chose qu'une erreur, en particulier, c'est distinct de l'erreur #N/A (non disponible).

Donc ce n'est pas une régression, mais un choix délibéré. Qu'on apprécie ou non, il va falloir en tenir compte dans les formules déjà présentes. Ce n'est pas vraiment un problème (en tout cas pas plus qu'un certain nombre de «mises en conformité» précédentes), vu qu'il existe des contournements donnés plus haut.
Cordialement,
Jean-Louis

[Sudo]

Bonjour,

La citation in extenso de mon premier message est vraisemblablement le résultat malheureux d'une tentative de déclarer le problème [Résolu] (ce qui partait d'une bonne intention).

Peu familier du langage des déclarations de bugs, j'ai effectivement mal interprété celle-ci et vous remercie de la clarification. Je peux entendre qu'il ne s'agit pas d'une régression, mais une telle modification n'est quand même pas sans poser de problèmes, surtout si elle n'est pas clairement documentée.

Encore une fois merci pour vos éclaicissements,

Cordialement.