Non, ce n'est pas cela qu'il cherche à illustrer mais l'arrondi d'une opération à la deuxième décimale.
Quand on a décidé de mal arrondir, c'est sûr, on arrondit mal, ça on est d'accord. Si l'on veut arrondir correctement à 0.01 près, on fait le calcul à 0.001 près pour décider si on doit aller au dessus ou en dessous pour l'arrondi au centième. C'est d'ailleurs ce que font les calculatrices (avec leurs chiffres cachés, et c'est aussi ce que font les processeurs avec les bits supplémentaires permettant de faire les arrondis (défaut, excès, au plus près)). Quand on fait cela, il n'y a aucun problème avec les floats binaires.
Sur le site que tu donnes il y a d'autres choses étranges.
#include<iostream>usingnamespacestd;intmain(){doublex=1.05,y=0.7,r1,r2=0.735;r1=x*y;cout<<r1==r2<<endl;// Va afficher True return0;}
Où est le problème ? Quand bien même on arriverait à 0.7349999[...], il n'y aurait pas de problème non plus: l'arrondi traité comme il faut donne ce que veut le banquier. Suivant la convention en vigueur, on peut donc parfaitement décider si l'on doit renvoyer, au centièmes près, 0.73 (par défaut) ou 0.74 (par excès). Le float binaire donnerait tout aussi bien le bon résultat si r1 était le résultat d'un quotient comme le sont la plupart des taux manipulés dans l'économat. Je n'arrive pas du tout à comprendre ce que donne le float décimal dans ce genre de cas.
Non, les taux de taxes et les taux de change sont fournis en décimal
Il n'y a pas que ce genre de taux quand on fait de l'économat. Certains taux peuvent résulter d'un quotient (c'est même souvent le cas non ?).
[...] doivent pouvoir être représentés de manière exacte dans le type.
Et pourquoi donc ? Si tu as une valeur approchée à 10^{-17} de la valeur finale, il n'y a aucun problème à donner un arrondi qui respecte les spécifications imposées en sortie.
Chacun des exemples donnés sur http://speleotrove.com/decimal/decifaq1.html#inexact se traite sans aucun problème sans utiliser le moindre flottant décimal. Si tu spécifies ce que tu veux, tu peux faire une fonction de deux lignes qui renverra exactement ce qu'est censé recevoir l'utilisateur.
Pour ce qui est des besoins des Dring, il a surtout fait mention du langage COBOL qui utilise des flottants[...]
Oui et aussi de la virgule fixe dont les spécifications sont suivies à la lettre par Ada. Comme Dring voulait des alertes compilo en cas de "problème", il fallait en passer par la virgule fixe (le flottant étant silencieux par nature sur la plupart des opérations posant problème).
Voilà comment je comprends le problème concernant la monnaie:
En entrée, on reçoit du décimal x à 10^{-2} près (appelons ce type D).
En sortie on veut du décimal y à 10^{-2} près.
Entre les deux, on a des opérations donnant un résultat f(x), qui en général, ne sera pas nécessairement y. Ce qu'on veut c'est arrondir f(x) pour obtenir le y désiré. Je ne pense pas que l'utilisation du flottant décimal apporte quoi que ce soit de plus dans ce type d'application que le flottant binaire. En tout cas, je n'ai pas encore vu de contre-exemple et je ne vois pas trop (à part utiliser des types n'utilisant pas la même taille mémoire).
[^] # Re: Il faut bien lire ce qu'on lit!
Posté par snowball (site web personnel) . En réponse au journal Le retour de la vengeance de la virgule flottante. Évalué à 1. Dernière modification le 26 janvier 2018 à 20:26.
Quand on a décidé de mal arrondir, c'est sûr, on arrondit mal, ça on est d'accord. Si l'on veut arrondir correctement à 0.01 près, on fait le calcul à 0.001 près pour décider si on doit aller au dessus ou en dessous pour l'arrondi au centième. C'est d'ailleurs ce que font les calculatrices (avec leurs chiffres cachés, et c'est aussi ce que font les processeurs avec les bits supplémentaires permettant de faire les arrondis (défaut, excès, au plus près)). Quand on fait cela, il n'y a aucun problème avec les floats binaires.
Sur le site que tu donnes il y a d'autres choses étranges.
Où est le problème ? Quand bien même on arriverait à 0.7349999[...], il n'y aurait pas de problème non plus: l'arrondi traité comme il faut donne ce que veut le banquier. Suivant la convention en vigueur, on peut donc parfaitement décider si l'on doit renvoyer, au centièmes près, 0.73 (par défaut) ou 0.74 (par excès). Le float binaire donnerait tout aussi bien le bon résultat si r1 était le résultat d'un quotient comme le sont la plupart des taux manipulés dans l'économat. Je n'arrive pas du tout à comprendre ce que donne le float décimal dans ce genre de cas.
Il n'y a pas que ce genre de taux quand on fait de l'économat. Certains taux peuvent résulter d'un quotient (c'est même souvent le cas non ?).
Et pourquoi donc ? Si tu as une valeur approchée à 10^{-17} de la valeur finale, il n'y a aucun problème à donner un arrondi qui respecte les spécifications imposées en sortie.
Chacun des exemples donnés sur http://speleotrove.com/decimal/decifaq1.html#inexact se traite sans aucun problème sans utiliser le moindre flottant décimal. Si tu spécifies ce que tu veux, tu peux faire une fonction de deux lignes qui renverra exactement ce qu'est censé recevoir l'utilisateur.
Oui et aussi de la virgule fixe dont les spécifications sont suivies à la lettre par Ada. Comme Dring voulait des alertes compilo en cas de "problème", il fallait en passer par la virgule fixe (le flottant étant silencieux par nature sur la plupart des opérations posant problème).
Voilà comment je comprends le problème concernant la monnaie:
En entrée, on reçoit du décimal x à 10^{-2} près (appelons ce type D).
En sortie on veut du décimal y à 10^{-2} près.
Entre les deux, on a des opérations donnant un résultat f(x), qui en général, ne sera pas nécessairement y. Ce qu'on veut c'est arrondir f(x) pour obtenir le y désiré. Je ne pense pas que l'utilisation du flottant décimal apporte quoi que ce soit de plus dans ce type d'application que le flottant binaire. En tout cas, je n'ai pas encore vu de contre-exemple et je ne vois pas trop (à part utiliser des types n'utilisant pas la même taille mémoire).