Discussion :

[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]

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]

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]

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]

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]

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 !

[cchatelain]

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.

[Maximil ian]

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.