Hello,
Vous avez un montant A, un taux de change 1 (précision à 16 chiffres après la virgule) et en les multipliant vous obtenez montant B.
Les 2 montants sont stockés en float dans une DB (mainframe DB2)  (après avoir été arrondis à 2 décimales pour montant B), le taux de change est stocké directement dans un float.
 
Un programme lit les données et refait A * taux de change mais obtient un résultat différent, pourquoi ?
Sachant que la méthode d'arrondis utilisée est la même je suppose un problème d'approximation dû au float mais je vois pas trop à part ça...
 
Quelques chiffres :
Montant A : 637732000
Taux de change : 0.83510000999999989
Montant B dans la DB : 763.659.434,93
Montant B calculé : 763.659.432,84
 
Calcul de l'arrondi :
Me.montantB = (montantA/ tauxDeChange) - CDec(0.005) 'On fait un + Cdec si le montant est positif
 
Je précise que montantA / taux de change donne 763659432.83846935171577547009 en decimal (et donc il est déjà "mauvais" )
 
Si vous avez des pistes pour que j'arrive à avoir le même montant que dans la DB je suis preneur.
 
 
 

mais tu divises ou tu multiplies au final ? parce que ton montant B c'est A/Taux et en haut tu multiplies

Pourquoi dis-tu que ce résultat est mauvais ? Il a l'air au contraire d'être bon (confirmé calculatrice Vista, qui est en précision arbitraire, et Ti92+)
 
C'est çui stocké en DB qu'est pas bon. Ton calcul de l'arrondi m'a l'air louche, c'est quoi le CDec ?

Le résultat le plus approchant que j'ai, c'est ça:

En gros, mon opinion est que le programme en base de données a converti la division en multiplication par l'inverse (et en le stockant en float) avant d'effectuer la conversion et le stockage de B. Cette conversion peut être volontaire ou pas: s'il y a beaucoup de divisions par le même taux, l'optimiseur du compilo peut transformer les divisions en multiplications.
Ou alors il y a l'équivalent du coup du -ffloat-store sous gcc/x86 qui entre peut-être en jeu...

Bah pas de problème avec ça, ça donne aussi du 763659432.84, ce qui est le bon résultat. C'est son 763659432.93 qu'est pas bon.

En fait quand ce sont 2 champs texte qui updatent l'autre quand on les change donc dans un sens c'est une division et dans l'autre une multiplication.

 
A priori le résultat de la DB est correct et c'est à nous de nous adapter... Cdec ça converti un float/integer/string en décimal.

 
Le résultat de la DB est mathématiquement incorrect. Si c'est une question d'argent, c'est à remonter...
 
Il n'est pas non plus le résultat d'arrondi simple sur les données que tu donnes en faisant le simple calculs avec les formats flottants courants (note qu'IBM utilise aussi des formats hexadecimaux, je ne me suis pas amusé à faire le calcul pour voir ce que ça donnerait avec eux).

Je l'ai remonté, la personne qui s'en occupe m'avoue ne pas comprendre comment ils sont arrivés à ce résultat et va chercher d'où ça vient.