le 06-01-2016 03:12 AM
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.
le 06-01-2016 03:21 AM
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 🙂
le 06-01-2016 03:31 AM
" 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
le 06-03-2016 11:49 AM
dans le principe, il manque le point rouge...pour que cela me paraisse logique
06-03-2016 01:43 PM - modifié 06-03-2016 02:02 PM
Bonjour thib_fr,
avec ou sans "point rouge", ce résultat n'est pas normal.
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 Bob_Schor 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)
le 06-06-2016 02:40 AM
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 ^^
06-06-2016 03:54 AM - modifié 06-06-2016 04:17 AM
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.