Nous l’avons tous appris en petite école : lorsque l’on arrondi un nombre à l’entier le plus proche, on arrondi par défaut (au-dessous) de .0 à .4, et on arrondi par excès (au-dessus) de .5 à .9. Mais aviez-vous remarqué que l’arrondi de .5 par excès est une convention ?
En effet, si l’on prend par exemple 8.5, c’est un nombre qui se trouve à égale distance de 8 (-0.5) et de 9 (+0.5).
C’est ainsi que j’ai découvert que certains langage de programmation ne respectent pas forcément la convention (cf. liens ci-dessous en crédits). Le Python, par exemple, va arrondir .5 par excès si le chiffre qui précède la virgule est impair, et par défaut s’il est pair. En pratique, 8.5 sera arrondi à 8, tandis que 7.5 est également arrondi à 8 ! Troublant.
J’ai moi-même vérifié avec MATLAB (image ci-dessous), mais ce dernier respecte bien la convention.
En conclusion, si vous manipulez du code et procédez à des arrondis, méfiez-vous.
Crédits
- Image par Markus Spiske
- Source : Benjamin Dubreau
- Bibliographie : Documentation Python
Effectivement c’est une convention mais ce n’est pas la seule. L’arrondi au dessus de 0.5 a un défaut de répartition qui a des impacts dans le bancaire par exemple, ou tu peux avoir des écarts de plusieurs milliers d’euros sur un groupe de milliards d’opération. D’où la notion d’arrondi bancaire. Après c’est dommage que les langages ne se soient pas tous mis d’accord.
Je comprend le besoin derrière cette idée d’arrondi variable entre le défaut et l’excès. Mais comme toi, je reste trés surpris que chaque langage de programmation face sa sauce dans son coin, et en dépit des conventions mathématiques.
D’ailleurs, en y réfléchissant… Peut-être vaudrait-il mieux que chaque développeur adapte son code pour éviter ce biais d’arrondi du 0.5 à l’entier supérieur, si son application le nécessite (tu évoquais le secteur bancaire)… plutôt que d’injecter telle ou telle étrangeté dans la fonction native de l’arrondi.