Non justement, pour l'arrondi "classique", mathématique, oui c'est le fait que transformer x.0 en x soit également un arrondi, avec une perte d'information, qui amène à arrondir .5 à l'excès, comme ça on a autant de cas d'excès (5 / 6 / 7 / 8 / 9) que de défauts (0 / 1 / 2 / 3 / 4), mais dans la perspective "tenir des comptes justes" non, puisqu'en arrondissant .1 à la baisse tu "oublies" 0,1, mais le .9 arrondi à la hausse consomme 0,1 donc ça s'équilibre ; mais le .5 arrondi à la hausse consomme 0,5 tandis que le .0 arrondi n'oublie rien, donc pas de compensation. D'où cette règle qui permet de répartir les .5 en deux camps qui vont se compenser les uns les autres.
[^] # Re: Exemple simple
Posté par Sufflope (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 6.
Non justement, pour l'arrondi "classique", mathématique, oui c'est le fait que transformer
x.0enxsoit également un arrondi, avec une perte d'information, qui amène à arrondir.5à l'excès, comme ça on a autant de cas d'excès (5 / 6 / 7 / 8 / 9) que de défauts (0 / 1 / 2 / 3 / 4), mais dans la perspective "tenir des comptes justes" non, puisqu'en arrondissant.1à la baisse tu "oublies" 0,1, mais le.9arrondi à la hausse consomme 0,1 donc ça s'équilibre ; mais le.5arrondi à la hausse consomme 0,5 tandis que le.0arrondi n'oublie rien, donc pas de compensation. D'où cette règle qui permet de répartir les.5en deux camps qui vont se compenser les uns les autres.