Si on reste sur PC x86, il y a les instructions x87, le SEE et les nombres sur 32, 64 et 80 bits, tout sachant que Intel calcule en interne sur 80 et non 64 bits pour les double au contraire de AMD.
les 80 bits du fpu ont du plomb dans l'aile puisque sur x86_64, tous les calculs se font en SSE2, cad en 64 bits maxi. Je ne sais pas historiquement quelle était la raison pour intel d'avoir 80 bits dans ses copro, mais en pratique ça a causé beaucoup plus d'emmerdes que ça n'a résolu de problèmes ( c'est bien pour ça qu'il y a une option -ffloat-store dans gcc pour les gens qui veulent des calculs conformes ieee)
J'imagine que c'est la démarche des codes scientifiques pour éviter d'utiliser des nombres étendus plus lent.
En général c'est double précision pour tout le monde, si cette précision ne suffit pas alors la bonne approche est de modifier l'algo plutot qu'utiliser des nombres avec une plus grande precision.
D'ailleurs comment choisi-t-on d'utiliser un type d'arrondi plutôt qu'un autre ?
Franchement je crois que tout le monde s'en fout mis à part deux trois psychopathes obsedés par ieee :)
Quel est l'intérêt de gérer les NaN ou les infinis qui ralentissent tellement un code c ?
Clairement detecter les erreurs de programmation, les divisions par 0, les sqrt(-1e-16) etc. Un autre truc qui ralentit monstrueusement le code c'est les nombres denormalisés, tous ceux qui font du traitement du signal avec des filtres récursifs en font l'experience un jour ou l'autre.
# plop again
Posté par Troy McClure (site web personnel) . En réponse au journal Comment les programmeurs écrivent du code flottant ?. Évalué à 9.
les 80 bits du fpu ont du plomb dans l'aile puisque sur x86_64, tous les calculs se font en SSE2, cad en 64 bits maxi. Je ne sais pas historiquement quelle était la raison pour intel d'avoir 80 bits dans ses copro, mais en pratique ça a causé beaucoup plus d'emmerdes que ça n'a résolu de problèmes ( c'est bien pour ça qu'il y a une option -ffloat-store dans gcc pour les gens qui veulent des calculs conformes ieee)
J'imagine que c'est la démarche des codes scientifiques pour éviter d'utiliser des nombres étendus plus lent.
En général c'est double précision pour tout le monde, si cette précision ne suffit pas alors la bonne approche est de modifier l'algo plutot qu'utiliser des nombres avec une plus grande precision.
D'ailleurs comment choisi-t-on d'utiliser un type d'arrondi plutôt qu'un autre ?
Franchement je crois que tout le monde s'en fout mis à part deux trois psychopathes obsedés par ieee :)
Quel est l'intérêt de gérer les NaN ou les infinis qui ralentissent tellement un code c ?
Clairement detecter les erreurs de programmation, les divisions par 0, les sqrt(-1e-16) etc. Un autre truc qui ralentit monstrueusement le code c'est les nombres denormalisés, tous ceux qui font du traitement du signal avec des filtres récursifs en font l'experience un jour ou l'autre.