Un joli petit bug : 1 = 0....

[davcha]

Vous êtes tous d'accord que la valeur entière arrondie à l'inférieur de 1 c'est 1, n'est-ce pas ?

Essayez ceci : SELECT FLOOR(1/3+2/3)

J'ai rapporté le bug sur la page de bugs de MySQL, et le rapport était introuvable le lendemain. Pas très sérieux.

[Alexandre T]

Envoyé par davcha

Vous êtes tous d'accord que la valeur entière arrondie à l'inférieur de 1 c'est 1, n'est-ce pas ?

Essayez ceci : SELECT FLOOR(1/3+2/3)

J'ai rapporté le bug sur la page de bugs de MySQL, et le rapport était introuvable le lendemain. Pas très sérieux.

Gardez son calme, gardez son calme, gardez son calme

Normal , SELECT FLOOR(1/3+2/3) doit bien retourner 1
Je te renvoie à tes cours de mathématiques sur la distributivité. La base de ces axiomes (ou théorème, je ne sais plus) déclarent qu'on commence par calculer ce qui est entre parenthèse.

En effet, FLOOR(1/3+2/3)=SELECT FLOOR(1) = 1
Tu confonds avec : SELECT FLOOR(1/3)+FLOOR(2/3) = SELECT 0 + 0 = 0

Avant de critiquer le sérieux de développeurs qui analysent les bugs soumis, il faut être sûr de ce qu'on écrit.

Allez l'erreur est humaine sans rancune aucune

PS : j'ai vérifié c'est un théorème et non un axiome.

[davcha]

Envoyé par Alexandre T

Allez l'erreur est humaine sans rancune aucune

En effet.

Vérifies : SELECT FLOOR(1/3+2/3).
Je n'ai pas fait d'erreur :

[Maximilian]

Ca vient sûrement de la représentation interne des flottants qui n'est pas exacte (0.99999 au lieu de 1). En revanche ceci fonctionne :

Code :

SELECT FLOOR(cast(1/3+2/3 AS decimal))

[davcha]

Oui, ça vient de ça. Mais c'est en fait un peu plus pénible que ça encore.

Le problème n'existe pas QUE dans ce cas précis. Il existe également dans ce cas là :

Code :

1
2
3
4
5
6
7
8
9
10
11
CREATE  TABLE  `test` ( `id` BIGINT NOT  NULL  AUTO_INCREMENT  PRIMARY  KEY ,
 `value` DOUBLE NOT  NULL 
) ENGINE  = innodb;
 
INSERT INTO test (value)
VALUES (1/3),(2/3)
 
SELECT FLOOR(SUM(value))
FROM test
 
retour : zéro.

Ce qui est déjà beaucoup plus embêtant.
On est forcé de caster lors de l'insertion en fait, comme le dit Maximilian.
Ce qui peut être bien embêtant pour certaines version de mysql4.

[Maximilian]

Envoyé par davcha

On est forcé de caster lors de l'insertion en fait, comme le dit Maximilian.

Pas forcément mais lors de la sélection si on veut des valeurs exactes, oui.

Edit : ce comportement disparait peut-être avec la 5.0, à tester...

[Alexandre T]

Ok je sors... J'ai compris que ça retournais un et que tu voulais zéro ...

Bon bah le zéro là dessus c'est moi !

[Alexandre T]

Même résultat en 5.0.18-nt

[Alexandre T]

Par contre, je comprends "une" erreur dans un sens.

Les valeurs ont mal été arrondies à leur insertion dans mysql.

Normalement un SELECT * from test devrait retourné :
id - Valeur
1 - 0.333333
2 - 0.666667

Mais cela retourne
id - Valeur
1 - 0.333333
2 - 0.666666

Par conséquent la somme des deux retourne 0.999999 et non 1. L'erreur n'est pas dans la fonction FLOOR. On peut penser que si il y a une erreur, elle est dans la façon dont mysql arrondie le dernier chiffre après la virgule.

[Alexandre T]

J'ai refait le test depuis la console pour éviter toute "verrolation" du processus par une éventuelle erreur de phpmyadmin.
Le résultat est similaire :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
SELECT * FROM test
+----+-------------+
| id | value       |
+----+-------------+
|  1 | 0.333333333 |
|  2 | 0.666666666 |
+----+-------------+
2 rows IN SET (0.00 sec)
 
mysql> SELECT sum(value) FROM test
+-------------+
| sum(value)  |
+-------------+
| 0.999999999 |
+-------------+
1 row IN SET (0.00 sec)

[davcha]

Envoyé par Alexandre T

L'erreur n'est pas dans la fonction FLOOR. On peut penser que si il y a une erreur, elle est dans la façon dont mysql arrondie le dernier chiffre après la virgule.

Oui, c'est tout à fait ça.

A noter qu'il ne s'agit pas d'un bug de taille de donnée, dans la mesure où : INSERT INTO test (id,value) VALUES
(1, 2/3 ),
(2, 0.666666666666666666666666666666666666666666) donnera un résultat incorrect à l'id 1 et un bon resultat à l'id 2.
A savoir :
1 => 0.666666666
2 => 0.666666666666667

Il s'agit donc bien de la façon dont mysql interprête certaines données.
Je veux dire :mysql est capable de sauvegarder des données de type DOUBLE avec 15 chiffres après la virgule, mais il ne fera aucun arrondi, tant qu'il n'aura pas au moins 16 chiffres après la virgule.

Si on insère : (3, 0.666666666666666) (15 chiffres après la virgule), il ne fait toujours pas d'arrondi.

C'est grave, je trouve, une telle imprécision sur ce genre de calculs.

Et c'est encore plus grave de nier l'existence d'un bug, comme ils semblent le faire.

Edit : Le bug est toujours là avec la 5.0.21, maximilian.

[jeca]

Après exécution du code ci-dessous :

Code :

1
2
3
4
5
6
7
 
CREATE  TABLE  `test` ( `id` BIGINT NOT  NULL  AUTO_INCREMENT  PRIMARY  KEY ,
 `value` DOUBLE NOT  NULL 
) ENGINE  = innodb;
 
INSERT INTO test (value)
VALUES (1/3),(2/3)

Code :

1
2
3
 
SELECT *
FROM test

donne

Code :

1
2
3
 
1	0.333333333333333
2	0.666666666666667

et

Code :

1
2
3
 
SELECT FLOOR(SUM(value))
FROM test

donne un résultat de 1 avec mysql 4.0.15

[Alexandre T]

Ce qui m'étonne est un fonction que nous qualifions de correct se réalisait en 4.0.15. Désormais en version 5+, le résultat est différent de ce que nous attendons. Je m'interroge.

Les développeurs ont-ils engendré une regression ou corrigé une erreur. Je vais faire des tests sur d'autres moteurs. Je possède chez moi des cours très complet de mathématiques dont un chapitre bien précis sur la notion d'arrondi. Je vérifierais par acquis de conscience. Néanmoins pour l'instant j'opte pour une regression. Ce qui m'étonnes est que ton bug a disparu. Généralement quand un internaute signale un bug et que cela n'en est point, ils closent le dossier "sans suite" mais ne le supprime pas...

[cchatelain]

Envoyé par davcha

J'ai rapporté le bug sur la page de bugs de MySQL, et le rapport était introuvable le lendemain. Pas très sérieux.

http://bugs.mysql.com/bug.php?id=19746 le rapport est encore là

[davcha]

Ah tiens... Marrant, il avait disparu pendant un temps

J'aime bien leur "status : not a bug".
Traduction : on sait que ça déconne, mais on a la flemme. C'est pas à nous de produire un vrai truc qui marche convenablement, c'est à l'utilisateur final de se faire chier à implémenter des tests foireux à base d'intervalles merdiques qui leur permetteront d'avoir une maintenance tout à fait atroce.

[Maximilian]

Pour moi le gars avec un nom à coucher dehors a bien expliqué pourquoi ce n'est pas un bug.

Ou est-ce que tu bloques, il suffit de convertir en decimal pour que ça fonctionne ?

PS : je viens de tester la requête SELECT FLOOR(1/3+2/3) sur SQL Server 2000 et elle a exactement le même comportement.

[davcha]

Tu en es sûr ?

Fais ceci : SELECT 1/3+2/3
Puis cela : SELECT FLOOR(1/3+2/3)
(les deux sans casts)

Moi, la première j'obtiens 1, et pas 0.99999
Donc il est logique que la seconde me renvoie 1 et pas 0.

Ou alors c'est que SELECT 1/3+2/3 ne renvoie pas le bon résultat.

Je vois pas comment on ne peut pas voir un bug là dedans, c'est ridicule.

[cchatelain]

Moi, en tous cas, je vois une régression... Maintenant, est-ce génant ou blocant ? Je n'ai pas la compétence pour en juger.

[Maximilian]

Encore une fois ce qui est affiché à l'écran peut différer de la représentation interne des flottants.

Cf http://dev.mysql.com/doc/refman/5.0/...ith-float.html

[davcha]

Je vais prendre un exemple bien concret pour représenter de façon claire ce que je signifie :

Le centre de la terre se situe environ à 149 millions de kilomètres du soleil. La précision de ce nombre s'arrête sur le chiffre des millions.

Ma maison se trouve à environ 6000 kilomètres du centre de la terre. Précision sur les milliers.

Si je fais le calcul de la distance ma maison/soleil, j'ai 149 millions, 149 006 000 ou 148 994 000 kilomètres ?

J'ai toujours 149 millions évidemment. Plus de précision n'a aucun sens, dans la mesure où mes 149 millions de kilomètres séparant la terre du soleil sont une approximation à 1 million près, donc 148 à 150 millions de kilomètres.
C'est donc ridicule de dire que ma maison se situe à 149 006 000 ou 148 994 000 kilomètres, dans la mesure où la position de la terre n'est connue qu'à 1 million de kilomètres près (dans cet exemple).
149 (+/- 1) millions de kilomètres + 30 centimètres, ça fait toujours 149 (+/- 1) millions de kilomètres.

Avec les flottants, c'est pareil. On aura beau de dire un million de fois que 21.40*1.000000000000000 => 21.3999999999999992 ça restera toujours 21.40, pour les simples raisons que : la précision des nombres est limitée, la précision des calculs sur les flottants est limitée.
Alors quand ils nous sortent un exemple de calculs sur des chiffres à 50 chiffres après la virgule, alors que l'opération elle-même n'est significative que sur ~6 ou 7 chiffres après la virgule, pardonnez-moi de ne pas être d'accord, mais pour le coup, je ne pense pas être dans mon tort.

Ceci dit, cette histoire est, au pire, une gêne.