Version imprimable
Bonsoir :
Le calcul du factoriel d’un nombre (real*8) s’arrête à 171 après c’est le résultat =’infinity’
Par contre sur une calculatrice windows on peut aller très lois.
Questions :
Cette limite est une propriété du langage de la programmation ou de la méthode utilisé pour
exploiter les ressources de la machine. ?
Vos conseils pour avoir la meilleure précision du calcul avec Fortran.
Note : Compilateur Gfortan avec l’IDE Force 2.0
Merci pour votre aide.
Salut!
Voir la norme IEEE754.
Jean-Marc Blanc
bonjour
cela depend des compilateurs qui peuvent donner des tailles de mantisse plus ou moins grande.
il existe :
-real standard 4 octets(equivalent int32 pour vb.net et c# car 4*8bit=32)
-real double 8 octets(equivalent int64 pour vb.net et c# car 8*8bit=64)
-real 10 octets(sur mon compil fnt95-10*8=80 bits)
evidement mais j'ai oublie la representation binaire interne mais c'est je crois:
-3 octets reserve pour mantisse
-1 octet pour l'exposant
d'ou la notation exponentielle 1223.0 E-2.
pour avoir le nombre de chiffre de la mantisse qui est toujours ce qui interesse dans les calculs tu as la fonction fortran qui te donne pour une variable le nombre de chiffre disponible pour les calculs (pas l'affichage mais le resultat interne stocke dans la memoire par le compilateur)
l'overvflow (debordement par le haut): peut arriver pour les grands nombre(infinity) soit dans la mantisse par exemple dans un reel*4 le nbre de chiffre du resultat depasse la capacite des 3 octets disponible,ou bien dans l'exposant (le nbre de chiffre depasse la capacite de l'octet reserve)Code:
2
Uunderflow(le fond c'est l'inverse du precedent) :a lieu pour la mantisse quand le resultat tres petit comporte autant de zero que les 3 octets et plus , le compilateur le signale avec nan(not a number).idem pour l'exposant s'il est negatif.
le nan et infinity sont un avertissement severe c.a.d qu'il faut borner tes resultats avec des valeurs sup. ou inf. dans le code .
De plus les algorithmes peuvent trouver des resultats absurdes ou boucler vu que les nombres sont tronques à cause de la capacite de la mantisse.
aussi ne jamais oublier que l'on fait de l'arithmetique decimale et que malgre l'abondance de la craie,le tableau(je veux dire le registre machine ) ne permet d'ecrire n'importe quel nombre et puis on ne trouverait pas d'esprit ni d'yeux pour le lire,aussi evitons l'absurdite à l'esprit humain.
En general,et dans la pratique on n'as pas besoin de resultats trop precis,car les donnees pratiques memes qu'ont introduit ne sont pas aussi precises.
bon code....
Salut!
Non, ça dépend avant tout du processeur.Citation:
cela depend des compilateurs
Jean-Marc Blanc
Merci a tous pour votre reponse et merci Mr Mabrouki pour votre explication;
C'est vrais que dans la pratique les donnés introduites ou initiales ont une incertitude,mais pour un algorithme amplificateur de ces erreurs ,les resultats seront loins de la precision.
-Est ce que vous avez dega roncontrer ces pieges dans la pratique ?
- Y a-t'il des methodes (par ex instructions fortran a eviter.......),pour maitriser ces erreurs ?
Essaye le code très simple suivant :
Les deux résultats devraient, mais ne sont pas égaux.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Il faut éviter autant que possible les opérations entre de nombres ayant des ordres de grandeurs très différents. Sinon l'erreur machine remonte et devient significative par rapport à la précision que tu cherches.
Bonsoir à tous
Il me semblait que
était obsolète en Fortran 9x . gfortran n'en veut pasCode:
2
et qu'il faut écrirereCode:
2
bobbyboy, que vaut dx dans ton exemple ?Code:
2
Oui pardon, dx = 1.0d-6 à initialiser avant la boucle.
Pour la notation real*8, ca passe en f90 sous gcc, ifort et xlf. Par contre effectivement gfortran n'en veut pas.
Es-ce gfortran qui est obsolète ou la notation ?
La notation.
Bonsoir
Merci Mr bobbyboy pour l’exemple c’est bien clair merci pour le conseil.
J’ai une question si vous permettez :
Si on a laissé ou oublié une variable sans affectation est ce que fortran lui affecte par défaut une valeur (plus grande ou petite valeur représenté en mémoire de ce type) ?
Cela est normal ou le compilateur doit retourner une erreur ?
Regardez l’example suivant :
Sortie :Code:
2
3
4
5
6
7
8
9
10
6.35257745 E+36
1.10302999 E-36
0
0
N:J'utilise un IDE Force 209 avec un compilateur gfortran.
Merci pour vos réponce et votre aide et bonsoir a tous.
Bonjour
Non, la norme ne prévoit pas d'affectation par défaut.Citation:
Si on a laissé ou oublié une variable sans affectation est ce que fortran lui affecte par défaut une valeur (plus grande ou petite valeur représenté en mémoire de ce type) ?
La valeur prise sera ce qui est trouvé en mémoire au moement de l'exécution.
Pour preuve, votre code compilé et exécuté avec 2 compilateurs différents
(gfortran et g95 sous linux) sur la même machine affiche des résultats différents :
Résultats d'ailleurs différents des votres.Code:
2
3
4
5
6
7
8
9
10
11
12
13
D'où il ressort qu'il faut bien faire attention à bien initialiser ses variables.
Bonjour,
le comportement pour une variable non affecté est différent en fonction des compilateurs.
Certains (comme xlf, ifort) attribuent par défaut la valeur 0 (ou plutôt nettoient l'adresse mémoire à la déclaration d'une variable).
D'autres (comme gfortran et apparement force2009) n'attribuent aucune valeur par défaut et se contentent d'attribuer une adresse mémoire.
Donc en l'abcence d'initialisation, la variable est égale à ce qui se trouve dans l'adresse mémoire de la variable à ce moment, à savoir tout et n'importe quoi.
Dans les deux cas, à mon sens, c'est une écriture à éviter.
Bonsoir
Merci à tous pour votre aide.