Discussion :

[pas30]

Bonjour,

J'ai un bug très bizarre. Quand je fais un echo (100-99.99), çà devrait me retourner 0.01 et çà me retourne une valeur du type 0.010000526.
Hallucinant non !!!
Au début j'ai cru que çà venait de la bdd mais non juste avec un echo de 100-99.99 çà renvoie n'importe quoi.

Merci de votre aide

[sharrascript]

bonsoir,

Je n'ai pas essayé, mais moi j'aurais fait le calcul dans une variable et je retournerai cette même variable.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$a = 100 - 99,99;
echo $a;

Je ne sais pas si c'est une solution au pb, mais j'aurai essayé de t'aider :p

++

[Manwë06]

Salut à toi
Voici un test que j'ai effectué en local :

Mon code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<?php
 
echo 100-99.99;
 
$a = 100 - 99.99;
echo "<br />a = ".$a;
 
?>

Le résultat :

0.01
a = 0.01

Je vois pas trop où tu as peché ton 526 qui se trouve à la fin de ton truc, mais moi j'aurais tendance à dire que ça à à voir avec l'init de tes vars (leur type, vu que php le gère sans que tu le vois, ca se pourrait que y'ait eu merdouille) ou alors que si les données viennent d'une base, ben ca soit le traitement de ces données qui foire lors de leur récupération.

Sinon à part ça chez moi ca marche très bien (PHP5.1.4 / Apache 2.2.2)

[pas30]

Bizarre effectivement, je viens de faire un test en mettant une variable à la place genre $a=100-99.99 çà retourne pareil une valeur éronnée
Donc çà vient d'autre chose, par contre mon test je le fais en ligne sur mon site et çà merde grave
j'ai créé un fichier calcul.php
<?php
echo 100-99.99;
?>
voilà et çà retourne n'importe quoi.
J'ai vu que mon hébergeur a une vieille version de php la 4.4.4, je prie pour que çà vienne pas de chez eux ou je suis mal.
Par contre, vous me confirmez que çà ne peut pas venir de ma version de php qui est installé chez moi qui doit etre assez ancienne je pense.

merci

[sharrascript]

Honnêtement je trouve ça très bizar,

Chez moi tout fonctionne et les valeurs sont corrects.

Dans tous les cas ça ne peu pas venir de ta version chez toi vu que tu fais les tests en ligne. Ta version ne peu influer sur celle de ton hébergeur.

Est-ce qu'un autre calcul fonctionne??

normalement même une version php3 devrais fonctionner.

Essai avec:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

print (100 - 99.99);

++

[Korko Fain]

Sans vouloir rentrer dans les détails du stockage et des calculs machines, je dirais que c'est tout à fait normal et que ce n'est pas un probleme de php mais un probleme du au codage en binaire des nombres. Et oui, l'ordinateur ne calcul pas en base10 (de 0 à 9) mais en base 2 (0 ou 1). Si nous avons des bonnes valeurs, ce n'est que du à un arrondi.

Petit algo sensé s'arreter mais avec la logique binaire de la machine, c'est une boucle infinie (et pourtant si vous regardez, il affiche $n = 1 MAIS $n != 1 étrange hein :p) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<?php
 
$n = 0;
 
while($n != 1)
{
    echo($n.'<br />');
    $n += 0.1;
}
 
// On n'y arrivera jamais
echo('Fini');
 
?>

[Invité]

Bonjour,

J'ai un bug très bizarre. Quand je fais un echo (100-99.99), çà devrait me retourner 0.01 et çà me retourne une valeur du type 0.010000526.
Hallucinant non !!!
Au début j'ai cru que çà venait de la bdd mais non juste avec un echo de 100-99.99 çà renvoie n'importe quoi.

Merci de votre aide

ce n'est pas un bug, on peut avoir qqchose de similaire en language C/C++
voir la doc en ligne de php: http://ca.php.net/manual/fr/language.types.float.php

Précision des nombres décimaux
Il est fréquent que de simples fractions décimales telles que 0.1 ou 0.7 ne puissent être converties au format interne binaire sans une légère perte de précision. Cela peut conduire à des résultats étonnants : par exemple, floor((0.1+0.7)*10) retournera 7 au lieu de 8 car le résultat de la représentation interne est 7.9999999999....

Tout ceci est lié au fait qu'il est impossible d'exprimer certaines fractions en un nombre fini de chiffres. Par exemple 1/3 s'écrira 0.3333333... en mode décimal.
Ne faites donc jamais confiance aux nombres à virgule jusqu'à leur dernière décimale et ne comparez jamais ces nombres avec l'opérateur d'égalité. Si vous avez besoin d'une précision particulière, reportez-vous au traitement des nombres de grande taille avec les bibliothèques BC ou GMP.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
<?php
printf("%.15f", (19.6*100));
?>
 
sortie: 1960.000000000000227 (et non 1960, comme prévut )

[pas30]

bonjour,

bizarre en effet tout çà. Mon problèm reste entier car quand je fais "update table set valeur=valeur-99.99 çà merde pareil
alors il faudrait arrondir le chiffre dans la base impossible non ???
C'est bizarre tout çà car aucun calcul du coup n'est correct ou exact avec php.

[Invité]

bonjour,

bizarre en effet tout çà. Mon problèm reste entier car quand je fais "update table set valeur=valeur-99.99 çà merde pareil
alors il faudrait arrondir le chiffre dans la base impossible non ???
C'est bizarre tout çà car aucun calcul du coup n'est correct ou exact avec php.

bizarre quand même, car si tu fais un UPDATE, comme tu l'indiques, ce n'est pas php qui gère le calcul mais bien Mysql

ton champ 'valeur' est définit de quelle façon dans mysql?

[pas30]

C'est trop fort ce truc lol
Vous ouvrez phpmyadmin et vous faites une requete
update table set nombre=nombre-99.99
avant il faut mettre dans nombre 100
çà retourne 0.01000051
Sinon mon nombre est définit en type double.
Donc mysql a le meme bug

[Invité]

C'est trop fort ce truc lol
Vous ouvrez phpmyadmin et vous faites une requete
update table set nombre=nombre-99.99
avant il faut mettre dans nombre 100
çà retourne 0.01000051
Sinon mon nombre est définit en type double.
Donc mysql a le meme bug

arrête ce n'est pas un bug!!

tout comme indiqué dans la docu de mysql, les seuls types de champ permettant de stocker la valeur exacte (avec une décimale), sont les types DECIMAL et NUMERIC

The DECIMAL and NUMERIC data types are used to store exact numeric data values. In MySQL, NUMERIC is implemented as DECIMAL. These types are used to store values for which it is important to preserve exact precision, for example with monetary data.

les champs float et double, sont des approximations des valeurs... je te conseil de changer ton type de données et refaire le test.. ensuite tu m'envois un chèque!!