Discussion :

[lebelge]

Bonjour,
Je suis en train d'ecrire un programme pour lequel j'ai besoin d'une bonne precision de calcul. Or j'ai un probleme que je ne sais pas resoudre :
Si je fais la chose suivante :

Code :

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

1
2
3
4
5
6
7
real p, q, r
 
write(*,*) 'entrer la valeur de p'
read(*,*) p
q = 1 - p
r = 1 - p - q
write(*,*) p, q, r

et que je rentre par exemple 0,8, il me ressort 0,800000012, 0,200000003 et -1,4900116E-008
Alors evidemment les erreurs se cumulent et je me retrouve parfois avec des probabilites calculees dont les valeurs sont superieures a 1 !

Comment peut-on faire pour que 0,2 soit egal à 0,2 et que 0,8 soit egal à 0,8 ? J'ai tente de declarer p, q, r en double precision, ca ne change rien.
Est-ce dû au format du read ?

Merci d'avance

[Sylvain Bergeron]

Comment peut-on faire pour que 0,2 soit egal à 0,2 et que 0,8 soit egal à 0,8 ? J'ai tente de declarer p, q, r en double precision, ca ne change rien.
Est-ce dû au format du read ?

Merci d'avance

Le format du read n'a rien à voir.

En double precision, tu as quand même dû réduire l'erreur...

Mais le problème restera là, même en double precision. Ça découle du fait que ta fraction 8/10 n'est pas représentable en série finie de raison 1/2. Elle est égale à environ :

8/10 = 1/2 + 1/4 + 0/8 + 0/16 + 1/32 + 1/64 + ...

Les solutions possibles sont les suivantes :

• Tu arrondis les résultats intermédiaires pour réduire le problème.
• Tu utilises un package supportant une représentation décimale et non binaire. Il existe un module f90 (que je ne trouve plus) permettant de conserver la représentation des nombres rationnels sous forme de fraction.
• Tu convertis tes calculs en entier avec un facteur d'échelle.

[lebelge]

Merci pour cette reponse. Je suis un peu sidere d'apprendre que le compilateur fortran utilise par defaut une representation binaire et pas decimale (mais peut-etre est-ce le cas de tous les compilateurs de tous les autres langages egalement). Comment se fait-il que la moindre calculatrice est en mode decimal alors qu'un objet aussi complexe qu'un compilateur ne l'est pas ?

Bref, je ne peux pas utiliser de facteur d'echelle, ni installer de package vu que j'utilise g77 et je n'ai pas trouve de tel package.
Par contre, je ne sais pas comment on fait pour arrondir ?

Si je veux arrondir à la 4ème décimale disons, je peux par exemple multiplier par 10E4, prendre la partie entiere et rediviser par 10E4. Mais alors, 2 questions :

1- le resultat de cette division devrait logiquement etre l'objet d'approximations dues a cette representation binaire. Je serais donc en train de generer une erreur de type different

2- il doit certainement exister des methodes plus efficaces d'arrondir, non ?

Merci d'avance

[Sylvain Bergeron]

Je suis un peu sidere d'apprendre que le compilateur fortran utilise par defaut une representation binaire et pas decimale (mais peut-etre est-ce le cas de tous les compilateurs de tous les autres langages egalement). Comment se fait-il que la moindre calculatrice est en mode decimal alors qu'un objet aussi complexe qu'un compilateur ne l'est pas ?

Ce ne sont pas les compilateurs qui sont binaires, mais les processeurs. Et ça inclue les calculatrices. Elles sont simplement programmées en double precision, soit avec 15 chiffres significatifs, alors qu'elles n'en affichent que 10 ou 12.

Bref, je ne peux pas utiliser de facteur d'echelle, ni installer de package vu que j'utilise g77 et je n'ai pas trouve de tel package.
Par contre, je ne sais pas comment on fait pour arrondir ?

Si je veux arrondir à la 4ème décimale disons, je peux par exemple multiplier par 10E4, prendre la partie entiere et rediviser par 10E4. Mais alors, 2 questions :

1- le resultat de cette division devrait logiquement etre l'objet d'approximations dues a cette representation binaire. Je serais donc en train de generer une erreur de type different

Tu as raison que la représentation interne d'un nombre arrondi à 4 décimales causera également problème si le problème provient d'un nombre arrondi à une décimale... La solution optimale dépend souvent du problème.
Dans ton cas, tu soustrais des chiffres tellement près l'un de l'autre que la différence entre les nombres est plus petite que l'erreur de représentation. Le résultat est donc totalement aléatoire. L'idée est donc d'arrondir "q" et "r". Ça ne règlera pas le problème de représentation interne, mais ça règlera le problème des résultats aléatoires. Tu devras également limiter les décimales affichées au write si le 0.800000012 t'irrite...

[afrancisco]

salut,

Comment peut-on faire pour que 0,2 soit egal à 0,2 et que 0,8 soit egal à 0,8

"0,2 pile" : 0.2E0 ou 0.2D0
idem, 0,1234 "pile" : 0.1234E0 ou 0.1234D0

E pour simple précision, D pour double.

[FR119492]

Salut !

Les erreurs d'arrondi sont inévitables, du fait que chaque variable est stockée dans un nombre fini de bits. Cela fait l'objet de la norme ANSI/IEEE 754. En général, ça ne porte pas trop à conséquence, sauf si une variante prend une valeur qui devrait être zéro et qui, en fait est seulement très petite, comme ton r=-1,4900116E-008 . Il peut t'arriver deux types d'ennuis:

• Si ton r est utilisé comme argument à une fonction, par exemple Sqrt, qui n'accepte pas d'arguments négatifs, ton programme se plantera.
  
• Si tu testes par un If si ton r est nul, ton programme partira dans n'importe quelle direction. Il faut écrire
  
  

  Code :

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

  If (Abs(r).Le.Epsilon) ...

  et non
  
  

  Code :

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

  If (r.Eq.0.) ...

Jean-Marc Blanc