A propos des arrondis et de la vitesse:
Cela depend. Pour des operations elementaires genre addition, multiplication et al, cela ne devrait pas influencer.
La ou ca devient un peu plus tordu c'est pour les fonctions trigonometriques: Comme certains resultats doivent arrondis car la precision d'un flottant, simple ou double ne suffit pas a stocker la valeur exacte, le resultat est arrondi. Cependant: Le resultat arrondi doit etre le meme que si tu arrondissais la valeur exacte de la meme facon.
Si tu es capable de faire une operation dans un format avec une plus grande precision, et que l'implementation de ta fonction est capable de garantir un resultat interne avec une assez bonne approximation, alors tu sais que quelque soit la regle d'arrondissement utilise pour stocker ta valeur arrondie, tu es coherent avec l'arrondissement du resultat reel.
Si ton implementation arrive a cette precision, alors la regle d'arrondissement n'influe pas la vitesse. Par contre, si tu ne peux pas, alors tu peux avoir a implementer differentes implementations pour chaque cas, pas toujours tous de la meme vitesse.
Dans la pratique, choisit la regle d'arrondissement qui convient a ce que tu cherches a calculer, pas pour des questions de vitesse d'execution.
En général, ces modes sont taxés de mal calculer.
Ils calculent tres bien avec les regles etablies. C'est juste que ces regles ne correspondent pas a IEEE. Donc pour etre plus precis:
En general, ces modes sont taxes de ne pas calculer comme IEEE le definit.
Si j'ai bien compris, il ne détecte pas les NaN dans le pipelines flottant pour éviter de gérer des interruptions en plein milieu.
Il y a deux modes "Fast": Y en a 1 c'est pour le processeur, l'autre c'est le compilateur.
Pour le processeur, c'est le "Flush to zero": Considere un nombre denormalise comme etant 0 et ne vient pas faire une exception logicielle pour deleguer le calcul a une implementation logicielle.
Pour le compilateur, c'est tout une suite d'optimisations qui ne sont pas valables par rapport a la norme mais dont beaucoup de programmes se foutent: Propagation de constantes, simplification d'operations, combination d'operations...
[^] # Re: Ecrire du code avec des flottants
Posté par mdlh . En réponse au journal Comment les programmeurs écrivent du code flottant ?. Évalué à 1.
Cela depend. Pour des operations elementaires genre addition, multiplication et al, cela ne devrait pas influencer.
La ou ca devient un peu plus tordu c'est pour les fonctions trigonometriques: Comme certains resultats doivent arrondis car la precision d'un flottant, simple ou double ne suffit pas a stocker la valeur exacte, le resultat est arrondi. Cependant: Le resultat arrondi doit etre le meme que si tu arrondissais la valeur exacte de la meme facon.
Si tu es capable de faire une operation dans un format avec une plus grande precision, et que l'implementation de ta fonction est capable de garantir un resultat interne avec une assez bonne approximation, alors tu sais que quelque soit la regle d'arrondissement utilise pour stocker ta valeur arrondie, tu es coherent avec l'arrondissement du resultat reel.
Si ton implementation arrive a cette precision, alors la regle d'arrondissement n'influe pas la vitesse. Par contre, si tu ne peux pas, alors tu peux avoir a implementer differentes implementations pour chaque cas, pas toujours tous de la meme vitesse.
Dans la pratique, choisit la regle d'arrondissement qui convient a ce que tu cherches a calculer, pas pour des questions de vitesse d'execution.
En général, ces modes sont taxés de mal calculer.
Ils calculent tres bien avec les regles etablies. C'est juste que ces regles ne correspondent pas a IEEE. Donc pour etre plus precis:
En general, ces modes sont taxes de ne pas calculer comme IEEE le definit.
Si j'ai bien compris, il ne détecte pas les NaN dans le pipelines flottant pour éviter de gérer des interruptions en plein milieu.
Il y a deux modes "Fast": Y en a 1 c'est pour le processeur, l'autre c'est le compilateur.
Pour le processeur, c'est le "Flush to zero": Considere un nombre denormalise comme etant 0 et ne vient pas faire une exception logicielle pour deleguer le calcul a une implementation logicielle.
Pour le compilateur, c'est tout une suite d'optimisations qui ne sont pas valables par rapport a la norme mais dont beaucoup de programmes se foutent: Propagation de constantes, simplification d'operations, combination d'operations...