Discussions au sujet de NI LabVIEW
Curieux !!! Arrondi Addition
Résolu !
comme disait mon prof de math en 4 éme
ce n'est pas grave de se tromper ce qui est grave c'est de ne pas s'en apercevoir 
c'est pas courant d'avoir besoin de plus de 15 chiffres significatifs 
c'est pourquoi ? si cela n'est pas indiscret...
Salut Michael,
Bienvenue dans le monde des nains de jardin, des trolls et autres farfadets
t'en veux une autre ? (une belle aussi) 
ceci dit ... je ne comprends pas pourquoi ???
en effet, les 3 nombres : 90000000000000000 , 100 , 90000000000000100 sont tous les 3 parfaitement représentables sur 64bits. ( ici )
(signe / exposant / mantisse - norme IEEE754)
90000000000000000 >IEEE754> = 0 00000010011 1111101111101000010111101101110010010000000000000000
100 >IEEE754> = 0 00000000000 0000000000000000000000000000000000000000000001100100
90000000000000100 >IEEE754> = 0 00000010011 1111101111101000010111101101110010010000000001100100
Il n'y a donc aucun problème particulier pour représenter ces 3 nombres sur 64 bits.
Alors pourquoi Labview, qui utilise cette norme IEEE754, et qui utilise bien les 64 bits nécessaires (DBL) ... n'y arrive-t-il pas ??
Je pense avoir déjà lu quelque chose à ce sujet ... mais plus moyen de retrouver l'info.
Un d'entre vous pourrait-il nous (ré)expliquer où se trouve le soucis à ce sujet avec LabVIEW. 
Merci.
Eric ?
Le timeout (absurde) du forum NI m'oblige à reposter juste pour ceci :
document intéressant sur le sujet de la représentaion des nombres en virgules flottantes et de l'arrondi inévitable. ( x )
J'en arrive (un peu) à la conclusion qu'il est illusoire, avec un DBL, d'obtenir une réelle précison au delà de 16 digits (significant et/ou precision digits)
Je note malgré tout certains comportement curieux ... et qui vont à l'encontre de la doc NI.
La fonction "Epsilon" est justement là pour pouvoir établir "l'égalité cachée" entre deux DBL.
La doc NI dit ceci :
Cependant, voici le code ci-dessous :
La fonction "égalité?" indique False !
Je fais donc la soustraction pour pouvoir ensuite comparer la différence à "Epsilon".
Cette soustraction me montre bien une différence "très petite" ... m'indiquant que ces 2 DBL peuvent "probablement" être considérés comme égaux.
Mais ... cette différence n'est pas inférieure ou égale à Epsilon ! ... mais vaut le double de Epsilon ?? (exactement 2x)
Dans d'autres "tests" j'ai même parfois obtenu une différence de 4 x Epsilon.
Dès lors, impossible d'utiliser cette fonction Epsilon pour établir la "proximité suffisante" pour conclure à une égalité.
Doc NI : " Machine Epsilon " : represents the round-off error for a floating-point number with a given precision "
Concernant l'utilisation de cette fonction "Epsilon" ... les résultats obtenus me semblent curieux.
Une soustraction qui donne en résultat ... parfois 2xEpsilon ... parfois 4xEpsilon ... ce comportement est-il normal ?
Et si oui ... comment savoir quel multiple de Epsilon il faut utiliser pour la comparaison d'égalité ??
thib_fr a écrit :comme disait mon prof de math en 4 éme
ce n'est pas grave de se tromper ce qui est grave c'est de ne pas s'en apercevoir
c'est pas courant d'avoir besoin de plus de 15 chiffres significatifs
c'est pourquoi ? si cela n'est pas indiscret...
Dans le cadre de la validation d'une transmission de données via interface radio, j'ai un critère d'erreur pouvant aller jusqu'à 10e-9.
Je voulais mettre le plus de marge possible par rapport à cela, car je venais de découvrir un arrrondi par défaut à 10e-6 qui me générait des erreurs non souhaitable.
C'est comme cela que dans la précipitation, j'ai pris une valeur arbitrairement grande, en me disant que cela n'aurait pas d'incidence sur le reste ......
Toujours quand on a des certitudes que l'on prend le poteau.
Merci Ouadji pour toutes ces précisions ^^ je pensais pas lacher un tel fauve dans l'arène 😛
Bonne journée à vous.
Michael
Bonjour Michael,
" je pensais pas lacher un tel fauve dans l'arène "
(note que le problème de la comparaison entre DBLs est un véritable problème qui soulève de vrais débats ... et qui sont justifiés)
Ceci dit,, avec moi ... même une simple porte AND devient une machine à gaz
(je me soigne, mais sans résultats 
)
...
Je voulais mettre le plus de marge possible par rapport à cela, car je venais de découvrir un arrrondi par défaut à 10e-6 qui me générait des erreurs non souhaitable.
C'est comme cela que dans la précipitation, j'ai pris une valeur arbitrairement grande, en me disant que cela n'aurait pas d'incidence sur le reste ......
comme on dit le mieux est l'ennemi du bien
tu ne compte pas les erreurs au fur et a mesure, par rapport à la quantité de donnée transmise ?
