Discussions au sujet de NI LabVIEW

annuler
Affichage des résultats de 
Rechercher plutôt 
Vouliez-vous dire : 

U32 ... avec virgule et décimales (??)

Bonjour Michael,

 

Pour les numériques "simples", si tu ne touches pas à "digits of précision" (placé par défaut à "0" par LabVIEW") ... tu n'auras jamais de soucis.

0 Compliments
Message 11 sur 17
1 749 Visites

Dans mon cas, je te rappelle que l'origine du problème est plus complexe, il me faut convertir un nombre (dbl/u32/i32/....) sous un format chaîne en gardant la plus grande précision possible.


Je pensais à tort, que "labview" aurait le même raisonnement que nous, et que dans le cadre d'un Uxx, il tronquerait tous les zéros de manière automatique, ce qui n'a pas été le cas 🙂

“En science, la phrase la plus excitante que l'on peut entendre, celle qui annonce des nouvelles découvertes, ce n'est pas "Eureka" mais c'est "drôle"
Isaac ASIMOV
0 Compliments
Message 12 sur 17
1 745 Visites

" l'origine du problème est plus complexe, il me faut convertir un nombre (dbl/u32/i32/....) sous un format chaîne en gardant la plus grande précision possible "

 

effectivement j'avais zappé  ... je suis toujours en préchauffage, je tourne sur 2 cylindres    Smiley clignant de l'œil

0 Compliments
Message 13 sur 17
1 743 Visites

Capture.JPG

dans le principe, il manque le point rouge...pour que cela me paraisse logique

0 Compliments
Message 14 sur 17
1 709 Visites

Bonjour thib_fr,

 

avec ou sans "point rouge", ce résultat n'est pas normal.

 

yyyyyy.png

 

Du côté du forum francophone, NI n'a pas répondu,

et du côté du forum anglophone, ne possédant pas l'anglais de façon suffisante, j'ai préféré baisser pavillon.

 

"On" prétexte à ce comportement qu'un indicateur à d'office un format float et donc, que pour un indicateur U32, si on "force" le "digits of precision" à une valeur supérieure à 15 ... on tombe sur le problème de tous les floats, à savoir, un soucis d'arrondi. L'histoire "amusante" , c'est que pour "80" il n'y aucun soucis d'arrondi et qu'un float sur 64bits (norme IEEE754) peut parfaitement et de façon absolument exacte représenter la valeur 80. Avec un float sur 64bits, 1 bits de signe, 11 bits d'exposant et 52 bits de mantisse ... 80 = 1,25 x 2^6 ... de façon parfaitement exacte. Tous les nombres réels ne peuvent pas être représentés de façon exacte avec 64bits et la norme IEEE54 ... mais 80, oui ! Alors, avoir un arrondi quand il y en a un, je veux bien ... mais quand il n'y en a pas, là je dis "bizarre!". Sur le forum anglophone,seul  a émis l'idée qu'il existerait peut-être un bug dans la routine de conversion ... et quand il a montré par "a+b" que pour 80 il n'y avait pas d'arrondi ... curieusement, personne ne lui a répondu ... silence radio. C'est très curieux ... premièrement LV se comporte comme s'il se trouvait devant un arrondi ... alors qu'il n'y en a pas ... et cet arrondi est exactement de 1e-16, donc inférieur à la valeur de "machine epsilon", c'est à dire inférieur au plus petit arrondi possible (soit 1/(2^52), en gros 2,22E-16). Donc avoir un arrondi de 1e-16 avec un float (norme IEEE754) sur 64bits est tout simplement impossible. Je suis totalement d'accord que d'afficher un U32 avec 16 digits of precision n'a absolument aucun sens ... mais si on le fait quand même, et que l'on "justifie" ce "79,99...99" par un soucis d'arrondi, je ne suis pas d'accord. Et tout ce qui précède est aussi bien valable pour notre U32 que pour un DBL. Avec une constante DBL de 80, si on affiche le résultat sur un indicateur DBL qui a 16 digits of precision, on affiche aussi "79,99...99" ... c'est impossible, l'arrondi vers le bas est inférieur à "machine epsilon". Même avec un indicateur DBL, pour une valeur de 80, on ne devrait jamais afficher "79,99...99", mais bien "80,00...00". Il existe dans LV du code dédié à l'affichage des numériques, et pour ma part je pense que ce code n'est tout simplement plus fiable au delà (au maximum) du 15eme digits. (et je pourrais parfaitement le comprendre, il faut une "limite" quant à la conversion et à l'affiche d'un numérique, c'est normal!)  (mais dire : "non, non, tout est normal, c'est à cause de l'arrondi" ... ça, négatif)

 

 

Message 15 sur 17
1 705 Visites

Sans compter que pour ma part, pour minimiser le phénomène "d'arrondi", j'avais revu ma prétention du nombre de digit à 14, mais cela n'a pas résolu le problème. Donc je penche aussi pour un vice caché dans LV ^^

“En science, la phrase la plus excitante que l'on peut entendre, celle qui annonce des nouvelles découvertes, ce n'est pas "Eureka" mais c'est "drôle"
Isaac ASIMOV
0 Compliments
Message 16 sur 17
1 668 Visites

en vert : ok  -  en rouge : une série de "9"

 

10, 20, 30, 40, 50, 60, 70, 80, 90, 100

8e1, 8e2, 8e3, 8e4, 8e5, 8e6, 8e7, 8e8

 

Tous se représentent de façon exacte avec un float 64bits. S'il est possible d'afficher 70 sans soucis, pourquoi ne pas pouvoir le faire avec 80 ?

Un U32 avec virgule et décimales ... la question n'est pas de savoir si cela a du sens, ou pas ... c'est juste une question de cohérence de comportement.

 

A partir du moment où LV donne accès à ce paramètre (digits of precision) ... LV se doit de gérer cette possibilité.

Et si LV ne désire pas gérer cette possibilité, il doit en interdir l'accès ... et mettre ce paramètre en "grisé".

 

PS : Serait-il de "bonne pratique" de créer une IHM où il est possible de modifier la densité du thermomètre ...

en précisant dans la doc qu'il ne faut pas le faire car cela n'a pas de sens ?

 

Je m'en voudrais de créer un troll , le sujet est clos en ce qui me concerne.

 

 

 

 

0 Compliments
Message 17 sur 17
1 665 Visites