Calcul retourne des nombres avec plein de 0 en décimal

Bonjour,

https://imgur.com/a/Q2Lcx1C

Dans la colonne de droite, j’ai des nombres avec des décimales… Etranges. Je ne sais pas d’où ça sort.

J’ai pu régler certaines d’elles en faisant :

+((solde + amount).toFixed(2));

Mais… Juste certaines d’elles. Ce qui est bizarre, parce que ça règle des additions, mais pas toutes. Alors que dans la colonne où les nombres sont en vert (Addition) ou rouge (Soustractions), aucun nombre n’a autant de décimales.

J’espère que vous saurez m’aider à enlever ces affreuses décimales

Je te remercie pour ta réponse (Et lien intéressant). Maintenant, je sais que je dois refaire mon code, lister toutes ces lignes autrement que par du JS.

T’as carrément des libs en JS pour palier l’inexistence d’un type ’entier’ : https://scurker.github.io/currency.js/

Note bien que si dans ton PHP tu représentes du fric avec des floats au lieu d’integers, tes résultats resteront faux. Des boites ont fait faillites pour avoir pas pensé à ça, et donc pour s’être retrouvé avec des erreurs d’arrondis.

Merci pour Currency.

Par contre, je suis curieux de savoir comment font, par exemple, libreoffice calc, pour faire du calcul de float ?

(J’ai comparé mes calculs PHP et ceux de LO Calc, et j’ai les mêmes résultats, là, j’ai pas de décimales bizarres )

T’as eu de la chance avec ton PHP, je présume. Ou t’as utilisé la partie de PHP spécialisée pour ça. Je connais pas trop PHP et j’ai pas vu ton code donc difficile de savoir. Ce que je sais faire c’est parcourir une page de doc, en revanche. Celle que j’ai donnée tout à l’heure te met en garde : http://php.net/manual/en/language.types.float.php

(L’emphase est mienne.)

Additionally, rational numbers that are exactly representable as floating point numbers in base 10, like 0.1 or 0.7, do not have an exact representation as floating point numbers in base 2, which is used internally, no matter the size of the mantissa. Hence, they cannot be converted into their internal binary counterparts without a small loss of precision. This can lead to confusing results: for example, floor((0.1+0.7)*10) will usually return 7 instead of the expected 8, since the internal representation will be something like 7.9999999999999991118....

Des boites ont fait faillites pour avoir pas pensé à ça, et donc pour s’être retrouvé avec des erreurs d’arrondis.

Tu aurais des exemples voir des sources là dessus ? Je t’avoue que trouve ça intéressant comme histoires.

Oh si tu aimes les bugs bêtes qui ont coûté un bras et parfois des vies, Google est ton ami.

Si mon avertissement ici est pris en compte par les lecteurs, ils s’éviteront sans nul doute une mauvaise surprise plus tard.

Dans ta console fait le calcul suivant 0.2*3 ou 0.3*3

Note que quel que soit le langage, à partir du moment où il gère les flottants avec IEEE 754 tu auras ce genre de surprise. Ici en Kotlin (ou Java) :

1
2

println(Math.floor((0.1+0.7)*10))
7.0

Ou en python :

1
2
3

>>> import math
>>> print(math.floor((0.1+0.7)*10))
7

@Spacefox : Sans math.floor ça donne quoi?

0.1 et 0.7 ne sont pas représentés exactement en virgule flottante, les ajouter donne un nombre égal à 7205759403792793/9007199254740992. À noter que ce nombre est légèrement inférieur à 0.8, et n’est même pas le nombre le plus proche de 0.8 représentable en flottant qui est 3602879701896397/4503599627370496 (et légèrement plus grand que 0.8).

IEEE-754 spécifie aussi ses types flottants décimaux (Decimal64 par exemple), qui ne font pas d’erreurs d’arrondi grossière des représentations décimales finies.

Je sais qu’en Python on a une bibliothèque qui les gère, faudrait voir en Javascript.

Dans ta console fait le calcul suivant 0.23 ou 0.33

Hahaha je pensais plutôt à des exemples d’entreprises.