From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
Discussions au sujet de NI LabVIEW
comportement (U64) (use default limits / maximum + coerce)
a) prenez un Contrôle et placez le en U64
b) Display Format / Data Entry ... décocher "use default limits" ... et placez le "maximum" à 1e19 + "coerce"
c) revenez sur votre Contrôle et entrez y le nombre 10000000000000000100 (faites un "copier/coller" c'est plus facile)
Le "coerce" fonctionne-t-il .... chez moi, non ! ... Je dois rentrer au minimum 10000000000000001025 pour que le "coerce" fonctionne. (10000000000000001024 ne "coerce" pas)
ma conclusion
probablement encore cette histoire qu'un Contrôle, en arrière plan, est un float ... avec la précision et les inconvénients liés aux float, non ?
Le soucis, c'est qu'ici je ne fais aucune manip "idiote" ... comme placer un U32 avec 18 "digits of précision"
Ma manip dans ce cas ci est tout ce qu'il y a de plus correct ... mais le résultat est que le "coerce" de LV ne fonctionne pas.
Franchement, je persiste et signe ... je trouve que cette gestion des Contrôles génère de vrais problèmes de comportement.
Ici, pour le moins, on se trouve devant un "vrai mauvais comportement".
Avez-vous le même comportement ? (confirmation?) ... et qu'en pensez-vous ?
Je ne reproche PAS à une conversion (quelle qu'elle soit) de ne "pas tomber juste".
C'est le principe du Float ... avec ses avnatages et ses inconvénients.
Ce que je pointe du doigt ... est que le fait de gérer les Contrôles en tant que Float ... crée (ici) un bug de comportement.
Dans le cas de figure d'un U64, il existe une fourchette de valeurs où "data entry / maximum / coerce" ... ne fonctionne pas !
pratiquement, ça veut dire quoi ?
ça veut dire qu'un opérateur devant l'IHM d'un banc de tests pourrait parfaitement "entrer" une valeur que le programme "en principe" lui interdit d'entrer.
Ma remarque n'est pas une critique négative. Mon seul but est d'apporter ma (toute petite) contribution pour tenter de rapprocher le produit de la perfection.
Je suis le premier à décrire LabVIEW comme étant une petite merveille. Mais ... quand il y a un soucis ... il y a un soucis. (rien de plus)
Réaction nettement plus explosive sur le forum anglophone.
(dommage que je ne possède pas suffisamment l'anglais pour "rentrer" dans le débat ... et je l'aurais fait façon "rugbyman")
Ceci dit, ce comportement (du côté anglophone) est confirmé et accepté comme "anormal". (c'est déjà pas mal)
LabVIEW est un outil et un langage absolument fabuleux ... je suis le premier à le crier ... et fort !
Cependant je trouve dommage de laisser subsister des comportements comme celui-ci.
Cette gestion des Contrôles qui se fait d'office au travers d'un format "float" ... génère des situations et des comportements problématiques.
Un U64 est également géré au travers d'un format float ... et un float n'a pas suffisamment de précision pour faire la différence entre (1E+19) et (1E+19)+1024 !
Mais le résultat final est là ... dans certains cas, cette fonctionnalité "coerce" ne "coerce pas" ... et je trouve que cela fait tâche.
Serait-il impossible de solutionner ce type de comportement ?
Bien sur que cela serait possible ... puisque la fonction native " In Range And Coerce" ne présente pas cette anomalie.
La fonction native " In Range And Coerce " fait parfaitement la différence entre (1E+19) et (1E+19)+1.
Dernièrement nous avons ouvert un débat sur ce Controle U32 auquel on attribuait 18 "digits of precision" ... et qui affichait "79,9999...".
Mais là, le problème était différent et certainement moindre ... il s'agissait "uniquement" d'un soucis d'affichage, de visuel ... sur le fil en lui-même, il y avait bien "80".
Et puis, attribuer 18 digits of precision à un U32 relevait de l'idiotie, tout simplement.
Ici, il n'y a aucune manipulation aberrante ou illogique.
De plus, c'est un comportement qui ne touche pas uniquement le développeur ... mais également l'utilisateur.
Quand la fonctionnalité coerce laisse passer un nombre supérieur au maximum, ce nombre se retrouve réellement sur le fil ...en dur.
Ce qui veut dire qu'un opérateur peut parfaitement introduire sur son IHM une valeur qui normalement est interdite.
et là, désolé, mais personnellement j'estime que cela ne devrait pas être ... pas dans un langage aussi performant que LabVIEW.
Au minimum ce comportement devrait être documenté ... (et à l'avenir, corrigé).
J'en reste là, sujet clos en ce qui me concerne.
@Michael : " je me savais beaucoup de défaut, mais je pensais être exempt d'idiotie"
ton "cas" d'utilisation était particulier Michael. cette "généralisation" ne te concernait en rien.
Michael ... tu n'as aucun défaut ... reste bien comme tu es, ,ne touche à rien !!! 
ouadji a écrit :@Michael : " je me savais beaucoup de défaut, mais je pensais être exempt d'idiotie"
ton "cas" d'utilisation était particulier Michael. cette "généralisation" ne te concernait en rien.
Michael ... tu n'as aucun défaut ... reste bien comme tu es, ,ne touche à rien !!!
Je sais mais ca me faisait sourire de le relever 😄
Et sinon si j'ai des défauts, mais pour l'instant j'arrive à compenser par les performances 😉 le jour où ca change j'irais élever des chèvres dans le larzac.
