Discussion :

[bombseb]

Bonjour, j'ai rencontré un petit problème, qui est maintenant résolu mais je m'interroge quand même sur le pourquoi du comment

On saisis 2.8 dans SAI_DUREE_AVANT

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
nToto est un entier
xToto2 est un numérique
 
nToto = PartieDécimale(Val (SAI_DUREE_AVANT))*100
xToto2 = PartieDécimale(Val (SAI_DUREE_AVANT))*100

contenu de la trace :
ntoto : 79
xToto : 80

est-ce que quelqu'un peut me dire pourquoi on a pas la même valeur dans les deux cas ?? je ne comprend pas...

[bombseb]

Un test supplémentaire...

je passe mon champs SAI_DUREE_AVANT en numérique
Je saisis 99,66 dedans

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
xToto est un numérique
xToto = PartieDécimale(SAI_DUREE_AVANT)
Trace ("xtoto : " + xToto)

Ce code me ramène ceci :

xtoto : 0.659999

est-ce normal ???

EDIT : Je suis sur Windev 14 au fait

EDIT2 : bon je crois qu'il faut que passer par un réel j'ai l'impression...

[sphynxounet]

Y a d'autres valeurs qui ne fonctionnent pas X.9, X.88 ...
J'ai essayé de passer par une variable réelle pour stocker Val(saisie), passer le champ saisie en numérique ...

Encore mieux en essayant 999.88 on se retrouve avec 87 et 87.999 !

Après dire de quoi ça vient ...

[bombseb]

voici un autre bout de code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
rToto est un réel
xToto2 est un numérique
rToto = PartieDécimale(99.66)
xToto2 = PartieDécimale(99.66)
Trace (rToto) // affiche 0.66
Trace (xToto2) // affiche 0.659999

apparement il faut mieux passer par un réel....

bizarre bizarre...

[tatayo]

Bonjour,
C'est un grand classique dans la gestion des réel en informatique, on a parfois ce genre de problème en C aussi, donc ce n'est pas spécifique à Windev.
Pour ne pas avoir de problème "d'arrondi", il faut passer par les monétaires de mémoire.

Tatayo.

[vmolines]

Bonsoir,

Le monétaire est un numérique particulier et n'est pas sujet au problème d'inexactitude des réels.

La raison du 0.66 qui se transforme en .659999 ici est que lorsque vous utilisez un décimal littéral, il est converti en réél à la compilation (Cf. aide je ne sais plus où). Pour affecter un décimal littéral en sous forme de numérique, il faut le préfixer par 0n. Vous pouvez refaire le test et vous ne constaterai plus votre problème.

Le fait que la trace du réel affiche la "bonne" valeur (0.66) est du à un pré traitement de la valeur tracée. Là je ne saurais en dire plus sur le comment. Mais en aucun cas votre réel ne stocke 0.66. Il stocke bien une valeur approchant 0.66 donc ne vous fiez pas à la trace.

Votre test initial utilise Val et le numérique reçoit donc un réel, c'est pourquoi vous constatez le même problème que lors de l'affectation littérale.

Enfin, concernant la valeur retournée par un champ de saisie, je n'ai aucune idée des opérations réalisées et formats retournés lorsqu'on demande la valeur.

[bombseb]

heu... merci pour tes éclaircissements !

mais bon j'ai pas tout compris

mais au moins ca marche