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

**davcha** · 15/05/2006, 11h17

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** · 15/05/2006, 11h43

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** · 15/05/2006, 12h13

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 :

**Maximil ian** · 15/05/2006, 12h16

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 :

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

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

**davcha** · 15/05/2006, 12h30

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 :

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

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.

**Maximil ian** · 15/05/2006, 14h23

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** · 15/05/2006, 15h04

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** · 15/05/2006, 15h16

Même résultat en 5.0.18-nt

**Alexandre T** · 15/05/2006, 15h32

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** · 15/05/2006, 15h35

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 :

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

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** · 15/05/2006, 19h34

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** · 15/05/2006, 20h25

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

Code :

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

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 :

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

1
2
3
 
SELECT *
FROM test

donne

Code :

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

1
2
3
 
1	0.333333333333333
2	0.666666666666667

et

Code :

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

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

donne un résultat de 1 avec mysql 4.0.15

**Alexandre T** · 15/05/2006, 21h04

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** · 18/05/2006, 02h21

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** · 18/05/2006, 02h35

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.

**Maximil ian** · 18/05/2006, 11h16

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** · 18/05/2006, 11h39

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** · 18/05/2006, 11h59

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.

**Maximil ian** · 18/05/2006, 12h41

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** · 18/05/2006, 12h53

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.

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

Administration MySQL

Discussions similaires

Partager

Partager