Un centime, c'est un centime. Je veux pas qu'il prenne son indépendance même si "il y a une bonne raison mathématique" derrière. Je veux que le langage (le compilateur ou l'interpréteur) me force à me poser la question dès que je risque de créer un problème d'arrondi ou de dépassement.
Si tu veux un langage qui répond à tes besoins, il va falloir les spécifier précisément ces besoins. Commençons donc par quelques questions basiques:
Quand tu augmentes un employé qui gagne 2101.35€ de 10%, tu veux que ton langage te donne quoi comme résultat ? 2311.49€ ou 2311.48€ ?
Quand tu dois répartir 100€ d'augmentation de façon égale sur 3 employés, tu veux que ton langage te donne quoi comme résultat ?
Quand tu as effectué une remise de 10% à un client sur toute une série de produits puis que que le mois d'après il faut annuler cette remise, tu attends quoi de ton langage si tu ne lui autorises que des décimaux ?
(exemple: je pars de 13.55, j'applique la remise et j'obtiens 12.195, je la stocke comment déjà ? avec deux décimales ? Si oui je garde quoi 12.20 ou 12.19 ? Et quand bien même on aurait gardé 3 décimales (en coupant des centimes en deux), comment le langage va faire pour annuler la remise initiale puisque qu'il faudrait multiplier par 10/9 mais que ce nombre n'est pas un décimal et que de toute façon il n'a pas de représentation exacte en machine ? Dans quoi le langage va t-il stocker ce 10/9 ? Si on fait des approximations au décimal le plus proche, sur 10 unités ça se verra pas trop, mais sur 100 000 unités, ça va faire un sacré écart...
Comment répondait le COBOL à tous ces problèmes ? Aucun langage ne peut deviner comment arrondir ce qui ne tombe pas juste. Ce n'est pas au langage de décider des règles d'arrondi mais à l'utilisateur.
De toute façon, il y a une solution à toutes questions si tu veux rester le plus juste possible: tu calcules tout en float (donc tu ne perds qu'à 1e-17 près en erreur relative) et tu arrondis en sortie au décimal le plus proche. Tu auras ainsi exactement ce que tu voulais. C'est d'ailleurs ce que fait une calculatrice.
[^] # 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é à 5.
Si tu veux un langage qui répond à tes besoins, il va falloir les spécifier précisément ces besoins. Commençons donc par quelques questions basiques:
(exemple: je pars de 13.55, j'applique la remise et j'obtiens 12.195, je la stocke comment déjà ? avec deux décimales ? Si oui je garde quoi 12.20 ou 12.19 ? Et quand bien même on aurait gardé 3 décimales (en coupant des centimes en deux), comment le langage va faire pour annuler la remise initiale puisque qu'il faudrait multiplier par 10/9 mais que ce nombre n'est pas un décimal et que de toute façon il n'a pas de représentation exacte en machine ? Dans quoi le langage va t-il stocker ce 10/9 ? Si on fait des approximations au décimal le plus proche, sur 10 unités ça se verra pas trop, mais sur 100 000 unités, ça va faire un sacré écart...
Comment répondait le COBOL à tous ces problèmes ? Aucun langage ne peut deviner comment arrondir ce qui ne tombe pas juste. Ce n'est pas au langage de décider des règles d'arrondi mais à l'utilisateur.
De toute façon, il y a une solution à toutes questions si tu veux rester le plus juste possible: tu calcules tout en float (donc tu ne perds qu'à 1e-17 près en erreur relative) et tu arrondis en sortie au décimal le plus proche. Tu auras ainsi exactement ce que tu voulais. C'est d'ailleurs ce que fait une calculatrice.