mysql bug?

Hallo zusammen,

5.0.27-community-nt unter Windows XP zeigt folgendes Verhalten:

CREATE TABLE `test` (
`test_col` DECIMAL( 10, 2 ) NOT NULL
) ENGINE = MYISAM ;


INSERT INTO `test`.`test` (
`test_col`
) VALUES (
'4.56'
);


SELECT * FROM test WHERE test_col='4.56'
-> no result

Das MERKWÜRDIGE: mit '4.57' funktionierts!

Kann das jemand mit seiner Version reproduzieren und/oder mir/sich erklären?

Gruß aus Aachen
Keith

Re: mysql bug?

On 13 Nov., 16:37, Keith Sauvant
wrote:
>
> Das MERKWÜRDIGE: mit '4.57' funktionierts!

Stimmt nicht.

Für '4.57' ebenfalls No-Result unter Win 5.0.18

Peter

Re: mysql bug?

Hallo,

>Hallo zusammen,
>
>5.0.27-community-nt unter Windows XP zeigt folgendes Verhalten:
>
>CREATE TABLE `test` (
>`test_col` DECIMAL( 10, 2 ) NOT NULL
>) ENGINE = MYISAM ;
>
>
>INSERT INTO `test`.`test` (
>`test_col`
>) VALUES (
>'4.56'
>);
verstehe nich warum du dass als String übergibst!
INSERT INTO `test`.`test` (`test_col`) VALUES (4.56);

geht doch auch!
>
>
>SELECT * FROM test WHERE test_col='4.56'
und somit auch

SELECT * FROM test WHERE test_col=4.56;

>-> no result
>
>Das MERKWÜRDIGE: mit '4.57' funktionierts!
>
>Kann das jemand mit seiner Version reproduzieren und/oder mir/sich erklären?
>
>Gruß aus Aachen
>Keith


cu Stephan

Re: mysql bug?

ich habe im übrigen Version 5.0.37


cu Stephan

Re: mysql bug?

Keith Sauvant schrieb:
> Hallo zusammen,
>
> 5.0.27-community-nt unter Windows XP zeigt folgendes Verhalten:

Hab ich auch hier auf einem Testrechner.

>
> CREATE TABLE `test` (
> `test_col` DECIMAL( 10, 2 ) NOT NULL
> ) ENGINE = MYISAM ;
>
>
> INSERT INTO `test`.`test` (
> `test_col`
> ) VALUES (
> '4.56'
> );
>
>
> SELECT * FROM test WHERE test_col='4.56'
> -> no result

Die Abfrage ist auch falsch, richtig ist:

SELECT * FROM test WHERE test_col=4.56;

>
> Das MERKWÜRDIGE: mit '4.57' funktionierts!

Tut es nicht:-)

mysql> select * from test where test_col = 4.56;
+----------+
| test_col |
+----------+
| 4.56 |
+----------+
1 row in set (0.00 sec)

mysql> select * from test where test_col = '4.56';
Empty set (0.00 sec)

mysql> select * from test where test_col = '4.57';
Empty set (0.00 sec)

>
> Kann das jemand mit seiner Version reproduzieren und/oder mir/sich
> erklären?
>
> Gruß aus Aachen
> Keith

Re: mysql bug?

Keith Sauvant schrieb:

> INSERT INTO `test`.`test` (
> `test_col`
> ) VALUES (
> '4.56'
> );
>
>
> SELECT * FROM test WHERE test_col='4.56'
> -> no result

Es ist IMMER ein Problem, Fließkommazahlen zu vergleichen, egal, ob in
C, Java oder MySQL.

Denn Nachkommastellen, die in der Binärdarstellung periodisch sind,
lassen sich nicht präzise darstellen. Von daher kann so ein Vergleich
schon mal schief gehen.


Insbesondere, wenn Du - wie Stephan auch schon angemerkt hat - mit
Strings arbeitest. Denn wenn Du die '4.56' in die Tabelle legst, wird da
intern eine leicht andere Zahl abgespeichert, und diese wiederum als
String mit '4.56' verglichen, könnte was Unterschiedliches ergeben.
Könnte, muß nicht.

Auf 5.0.26-Max (Linux) läßt sich das beschriebene Verhalten übrigens
nicht reprodzieren...


Thomas

Re: mysql bug?

On Tue, 13 Nov 2007 09:30:57 -0800, Peter Schleif wrote:

> On 13 Nov., 16:37, Keith Sauvant wrote:
>>
>> Das MERKWÜRDIGE: mit '4.57' funktionierts!
>
> Stimmt nicht.
>
> Für '4.57' ebenfalls No-Result unter Win 5.0.18

Solange du nicht exakt vergleichbare Hard-/Software hast, oder zumindest
exakt weisst wie sich Keiths Plattform bei der Fließkommaarithmetik
verhält, wäre ich mit solchen Aussagen bei Gleichheitstests von
Fließkommazahlen ganz vorsichtig. Ein einfaches lokales Testen sagt dir
bei solchen Sachen im Allgemeinen gar nichts darüber, ob sich das bei
jemand anders genau so verhält. AFAIK unterscheiden sich die Ergebnisse
gleicher Fließkommaberechnungen schon bei Intel und AMD CPUs, also
innerhalb einer Architektur, sehr wahrscheinlich auch zwischen
verschiedenen Prozessorfamilien der gleichen Architektur des gleichen
Herstellers (z.B. Pentium vs. Pentium III).

Obwohl der Spaltentyp DECIMAL ist, ist die Konstante ein String (dank der
einfachen Anführungszeichen), was dazu führt, dass daraus eine
Fließkommazahl wird und der komplette Ausdruck mit Fließkommaarithmetik
berechnet wird, was einen Test auf Gleichheit quasi verbietet. Siehe:

http://dev.mysql.com/doc/refman/5.0/en/precision-math-expres sions.html

Ergo: Einfach die Anführungszeichen entfernen und fertig (wie es Stefan
ja schon vorgeschlagen hat).

Björn

Re: mysql bug?

Thomas Rachel schrieb:
> Keith Sauvant schrieb:
>
>> INSERT INTO `test`.`test` (
>> `test_col`
>> ) VALUES (
>> '4.56'
>> );
>>
>>
>> SELECT * FROM test WHERE test_col='4.56'
>> -> no result
>
> Es ist IMMER ein Problem, Fließkommazahlen zu vergleichen, egal, ob in
> C, Java oder MySQL.
>

Sollte aber DECIMAL(10,2) nicht eine *Fest*kommazahl sein?

> Denn Nachkommastellen, die in der Binärdarstellung periodisch sind,
> lassen sich nicht präzise darstellen. Von daher kann so ein Vergleich
> schon mal schief gehen.
>

Stimmt für FLOAT etc. Stimmt aber m.E. nicht für NUMERIC, MONETARY und
DECIMAL - die benutzen nämlich sowas wie BCD oder gar (god forbid)
Strings als interne Repräsentation.

Re: mysql bug?

Björn Steinbrink schrieb:
> On Tue, 13 Nov 2007 09:30:57 -0800, Peter Schleif wrote:
>
>> On 13 Nov., 16:37, Keith Sauvant
>> wrote:
>>> Das MERKWÜRDIGE: mit '4.57' funktionierts!
>> Stimmt nicht.
>>
>> Für '4.57' ebenfalls No-Result unter Win 5.0.18
>
> Solange du nicht exakt vergleichbare Hard-/Software hast, oder
> zumindest exakt weisst wie sich Keiths Plattform bei der
> Fließkommaarithmetik verhält, wäre ich mit solchen Aussagen bei
> Gleichheitstests von

Ja, ja, ja.

Aber:

> MySQL supports all of the standard SQL numeric data types. These
> types include the exact numeric data types (INTEGER, SMALLINT,
> DECIMAL, and NUMERIC), as well as the approximate numeric data types
> (FLOAT, REAL, and DOUBLE PRECISION).

Wie Du unschwer erkennen kannst, ist DECIMAL (und darum ging es hier)
ein *exakter* Datentyp. Nicht umsonst haben sich DB-Hersteller sowas wie
NUMERIC, MONETARY und DECIMAL ausgedacht, denn viele Anwendungen
brauchen eine exakte Repräsentation von Dezimalzahlen.

Deshalb geht Dein Argument am eigentlichen Thema vorbei.


> Obwohl der Spaltentyp DECIMAL ist, ist die Konstante ein String (dank
> der einfachen Anführungszeichen), was dazu führt, dass daraus eine
> Fließkommazahl wird und der komplette Ausdruck mit
> Fließkommaarithmetik berechnet wird, was einen Test auf Gleichheit
> quasi verbietet. Siehe:
>
> http://dev.mysql.com/doc/refman/5.0/en/precision-math-expres sions.html
>
>
> Ergo: Einfach die Anführungszeichen entfernen und fertig (wie es
> Stefan ja schon vorgeschlagen hat).

Was nichts damit zu tun hat, dass dann plötzlich ein Vergleich auf
Gleichheit in Fließkommaarithmetik zuverlässig funktionieren würde :-(

Re: mysql bug?

Hallo,
>Thomas Rachel schrieb:
>> Keith Sauvant schrieb:
>>
>>> INSERT INTO `test`.`test` (
>>> `test_col`
>>> ) VALUES (
>>> '4.56'
>>> );
>>>
>>>
>>> SELECT * FROM test WHERE test_col='4.56'
>>> -> no result
>>
>> Es ist IMMER ein Problem, Fließkommazahlen zu vergleichen, egal, ob in
>> C, Java oder MySQL.
>>
>
>Sollte aber DECIMAL(10,2) nicht eine *Fest*kommazahl sein?
>
>> Denn Nachkommastellen, die in der Binärdarstellung periodisch sind,
>> lassen sich nicht präzise darstellen. Von daher kann so ein Vergleich
>> schon mal schief gehen.
>>
>
>Stimmt für FLOAT etc. Stimmt aber m.E. nicht für NUMERIC, MONETARY und
>DECIMAL - die benutzen nämlich sowas wie BCD oder gar (god forbid)
>Strings als interne Repräsentation.

Das mag sein nur die "interne Repräsentation" geht nur die Datenbank
was an und nicht den User, wenn er eine Eingabe macht, der hat die
Daten dann so zu Liefern wie er es festlegte!
Womit wenn ich ein Feld mit DECIMAL(x,Y) definiere auch bei der
Datenübergabe z.b. 4.56 und nicht '4.56' zu übergeben habe,
man wandelt doch auch nicht jedes mal ein BOOL Wert in einen INTEGER
um, nur weil die Datenbank "intern" eh INTEGER weiter verarbeitet!.



cu Stephan

Re: mysql bug

Danke für die schnellen Antworten!

Mir ist auch klar, dass es nicht sauber ist, mit Strings auf
DECIMAL-Spalten loszugehen. Nur: Es funktioniert unter Linux problemlos,
anscheinend nur unter Windows nicht zuverlässig. Dass es bei einem Wert
funktioniert, bei einem anderen aber nicht, konnte ich mir nicht
erklären. Daher hier die Nachfrage.

Mit der Fließkommaerklärung kann ich leben, danke!

Wohl doch kein mysql bug ;-)

Gruß
Keith

Re: mysql bug?

Stephan Menzel schrieb:

>>> Es ist IMMER ein Problem, Fließkommazahlen zu vergleichen, egal, ob in
>>> C, Java oder MySQL.
>>>
>> Sollte aber DECIMAL(10,2) nicht eine *Fest*kommazahl sein?
>>
>>> Denn Nachkommastellen, die in der Binärdarstellung periodisch sind,
>>> lassen sich nicht präzise darstellen. Von daher kann so ein Vergleich
>>> schon mal schief gehen.
>>>
>> Stimmt für FLOAT etc. Stimmt aber m.E. nicht für NUMERIC, MONETARY und
>> DECIMAL - die benutzen nämlich sowas wie BCD oder gar (god forbid)
>> Strings als interne Repräsentation.
>
> Das mag sein nur die "interne Repräsentation" geht nur die Datenbank
> was an und nicht den User, wenn er eine Eingabe macht, der hat die
> Daten dann so zu Liefern wie er es festlegte!
> Womit wenn ich ein Feld mit DECIMAL(x,Y) definiere auch bei der
> Datenübergabe z.b. 4.56 und nicht '4.56' zu übergeben habe,
> man wandelt doch auch nicht jedes mal ein BOOL Wert in einen INTEGER
> um, nur weil die Datenbank "intern" eh INTEGER weiter verarbeitet!.

Ich habe nicht der Feststellung widersprochen, dass man Zahlen als
Zahlen übergeben und auch vergleich soll - sondern dem falschen Bezug zu
Fließkommazahlen. Der OP hat ausdrücklich und zu Recht DECIMAL
verwendet, weil damit exakte Vergleiche möglich sind. Die interne
Repräsentation ist in diesem Fall durchaus wichtig, weil eben BCD oder
auch Strings eine exakte Repräsentation von Dezimalzahlen erlauben, was
mit jeder Art von Umrechnung in das Binärsystem, wie sie bei Floats u.ä.
vorkommen, nicht möglich ist.

Und immer noch stimmt, dass man Werte gefälligst in der Form zu
übergeben hat, wie die DB sie erwartet. (Obwohl Du natürlich auch kein
Boolean übergibst, sondern eine String-Repräsentation dessen -- aber das
ist eben SQL)

Re: mysql bug

Keith Sauvant schrieb:
> Danke für die schnellen Antworten!
>
> Mir ist auch klar, dass es nicht sauber ist, mit Strings auf
> DECIMAL-Spalten loszugehen.

Dann lass es doch.

Re: mysql bug?

Hallo,


>Stephan Menzel schrieb:
>
>> um, nur weil die Datenbank "intern" eh INTEGER weiter verarbeitet!.
>
>Ich habe nicht der Feststellung widersprochen, dass man Zahlen als
>Zahlen übergeben und auch vergleich soll - sondern dem falschen Bezug zu
>Fließkommazahlen. Der OP hat ausdrücklich und zu Recht DECIMAL
>verwendet, weil damit exakte Vergleiche möglich sind. Die interne
>Repräsentation ist in diesem Fall durchaus wichtig, weil eben BCD oder
>auch Strings eine exakte Repräsentation von Dezimalzahlen erlauben, was
>mit jeder Art von Umrechnung in das Binärsystem, wie sie bei Floats u.ä.
>vorkommen, nicht möglich ist.
>
>Und immer noch stimmt, dass man Werte gefälligst in der Form zu
>übergeben hat, wie die DB sie erwartet. (Obwohl Du natürlich auch kein
>Boolean übergibst, sondern eine String-Repräsentation dessen -- aber das
>ist eben SQL)

Entschuldige ich habe mich in meiner Ausführung etwas verrant!
Die Bemerkung bezüglich des Boollean ging an Keith nicht an dich, das
er den entsprechenden Datentyp auch verwendet, den die Tabelle
verlangt!


cu Stephan

Re: mysql bug

Hallo,

>Danke für die schnellen Antworten!
>
>Mir ist auch klar, dass es nicht sauber ist, mit Strings auf
>DECIMAL-Spalten loszugehen. Nur: Es funktioniert unter Linux problemlos,
>anscheinend nur unter Windows nicht zuverlässig. Dass es bei einem Wert
>funktioniert, bei einem anderen aber nicht, konnte ich mir nicht
>erklären. Daher hier die Nachfrage.
>
>Mit der Fließkommaerklärung kann ich leben, danke!

Es hat nicht unbedingt mit Linux oder Windows zu tun!
Vorraussetzung ist das Du deine Dateneingabe so änderst das
Du auch das an den SQL-Server Sendest was Definiert ist!

>
>Wohl doch kein mysql bug ;-)
>
>Gruß
>Keith

cu Stephan

Re: mysql bug?

On Wed, 14 Nov 2007 08:36:38 +0100, Christian Kirsch wrote:

> Björn Steinbrink schrieb:
>> On Tue, 13 Nov 2007 09:30:57 -0800, Peter Schleif wrote:
>>
>>> On 13 Nov., 16:37, Keith Sauvant
>>> wrote:
>>>> Das MERKWÜRDIGE: mit '4.57' funktionierts!
>>> Stimmt nicht.
>>>
>>> Für '4.57' ebenfalls No-Result unter Win 5.0.18
>>
>> Solange du nicht exakt vergleichbare Hard-/Software hast, oder
>> zumindest exakt weisst wie sich Keiths Plattform bei der
>> Fließkommaarithmetik verhält, wäre ich mit solchen Aussagen bei
>> Gleichheitstests von
>
> Ja, ja, ja.
>
> Aber:
>
>> MySQL supports all of the standard SQL numeric data types. These types
>> include the exact numeric data types (INTEGER, SMALLINT, DECIMAL, and
>> NUMERIC), as well as the approximate numeric data types (FLOAT, REAL,
>> and DOUBLE PRECISION).
>
> Wie Du unschwer erkennen kannst, ist DECIMAL (und darum ging es hier)
> ein *exakter* Datentyp. Nicht umsonst haben sich DB-Hersteller sowas wie
> NUMERIC, MONETARY und DECIMAL ausgedacht, denn viele Anwendungen
> brauchen eine exakte Repräsentation von Dezimalzahlen.
>
> Deshalb geht Dein Argument am eigentlichen Thema vorbei.

Der Op hat aber nunmal die Konstante als String angegeben (und Peter in
seiner Antwort auch) und dann hat man eben effektiv _kein_ DECIMAL mehr
sondern nur noch DOUBLE(?), wie ich im folgenden Absatz erwähnt hatte. Es
ging mir nur darum, dass dieses "Stimmt nicht" quais ein Angriff auf den
Op war, während der Fehler an einer völlig anderen Stelle lag und das
"Stimmt nicht" jeglicher Grundlage beraubt hat.

>> Obwohl der Spaltentyp DECIMAL ist, ist die Konstante ein String (dank
>> der einfachen Anführungszeichen), was dazu führt, dass daraus eine
>> Fließkommazahl wird und der komplette Ausdruck mit Fließkommaarithmetik
>> berechnet wird, was einen Test auf Gleichheit quasi verbietet. Siehe:
>>
>> http://dev.mysql.com/doc/refman/5.0/en/precision-math-expres sions.html
>>
>>
>> Ergo: Einfach die Anführungszeichen entfernen und fertig (wie es Stefan
>> ja schon vorgeschlagen hat).
>
> Was nichts damit zu tun hat, dass dann plötzlich ein Vergleich auf
> Gleichheit in Fließkommaarithmetik zuverlässig funktionieren würde :-(

Natürlich nicht, ohne die Anführungszeichen wird ja auch gar keine
Fließkommaarithmetik mehr benutzt, sondern exakte Werte, womit sich das
Problem in Luft auflöst. Sorry, wenn das nicht klar genug rüberkam.

Björn

Re: mysql bug

On Wed, 14 Nov 2007 11:43:05 +0100, Keith Sauvant wrote:

> Danke für die schnellen Antworten!
>
> Mir ist auch klar, dass es nicht sauber ist, mit Strings auf
> DECIMAL-Spalten loszugehen. Nur: Es funktioniert unter Linux problemlos,
> anscheinend nur unter Windows nicht zuverlässig. Dass es bei einem Wert
> funktioniert, bei einem anderen aber nicht, konnte ich mir nicht
> erklären. Daher hier die Nachfrage.

Du wirst auch unter Linux Werte finden bei denen es fehlschlägt. Wird
einfach ne leicht andere Fließkomma-Implementation sein und die bringt
die nötige Abweichung halt bei anderen Werten.

> Mit der Fließkommaerklärung kann ich leben, danke!

Warum nicht einfach die Anführungszeichen weglassen, dadurch exakte
Berechnungen erhalten, keine Fließkommaproblematik mehr haben und
glücklich sein?

Björn

Re: mysql bug?

Björn Steinbrink schrieb:

>>> Obwohl der Spaltentyp DECIMAL ist, ist die Konstante ein String (dank
>>> der einfachen Anführungszeichen), was dazu führt, dass daraus eine
>>> Fließkommazahl wird und der komplette Ausdruck mit Fließkommaarithmetik
>>> berechnet wird, was einen Test auf Gleichheit quasi verbietet. Siehe:
>>>
>>> http://dev.mysql.com/doc/refman/5.0/en/precision-math-expres sions.html

Danke für die Erläuterung. Ich hätte mir vorstellen können, dass MySQL
die Wandlung erst vornimmt, wenn es *weiß*, was für ein Typ sinnvoll ist
(also Spaltentyp angucken, DECIMAL sehen und Das Richtige(tm) tun).
Offenbar nicht ..

Re: mysql bug

Björn Steinbrink wrote:
> Warum nicht einfach die Anführungszeichen weglassen, dadurch exakte
> Berechnungen erhalten, keine Fließkommaproblematik mehr haben und
> glücklich sein?

habe ich jemals gesagt, dass ich diesen Code produktiv einzusetzen
gedenke? ;-) Es ging mir einzig und allein darum, dieses merkwürdige
Verhalten zu verstehen.

Übrigens tritt es ab 5.0.32 nicht mehr auf:
http://bugs.mysql.com/bug.php?id=23260

Gruß
Keith

Re: mysql bug?

Christian Kirsch schrieb:

> Danke für die Erläuterung. Ich hätte mir vorstellen können, dass MySQL
> die Wandlung erst vornimmt, wenn es *weiß*, was für ein Typ sinnvoll ist
> (also Spaltentyp angucken, DECIMAL sehen und Das Richtige(tm) tun).
> Offenbar nicht ..

MySQL tut das Richtige, nämlich genau das, was im Manual beschrieben
ist: "Wenn ein numerischer Ausdruck Strings enthält, so werden diese in
Fließkommawerte mit doppelter Genauigkeit umgewandelt und es entsteht
ein näherungsweiser Ausdruck".

http://dev.mysql.com/doc/refman/5.1/de/precision-math-expres sions.html

Gruß. Claus

Re: mysql bug?

Claus Reibenstein schrieb:
> Christian Kirsch schrieb:
>
>> Danke für die Erläuterung. Ich hätte mir vorstellen können, dass MySQL
>> die Wandlung erst vornimmt, wenn es *weiß*, was für ein Typ sinnvoll ist
>> (also Spaltentyp angucken, DECIMAL sehen und Das Richtige(tm) tun).
>> Offenbar nicht ..
>
> MySQL tut das Richtige, nämlich genau das, was im Manual beschrieben
> ist: "Wenn ein numerischer Ausdruck Strings enthält, so werden diese in
> Fließkommawerte mit doppelter Genauigkeit umgewandelt und es entsteht
> ein näherungsweiser Ausdruck".
>
> http://dev.mysql.com/doc/refman/5.1/de/precision-math-expres sions.html
>

Vielleicht hinkt das Manual (oder gar Du?) ein bisschen hinter der
Realität her?

http://bugs.mysql.com/bug.php?id=23260

Nicht alles, was im MySQL-Handbuch steht, ist deshalb schon sinnvoll ;-)

Ceterum censeo: Natürlich soll man keine Strings übergeben, wenn eine
Zahl erwartet wird ...

Re: mysql bug?

Christian Kirsch schrieb:

> Claus Reibenstein schrieb:
>
>> MySQL tut das Richtige, nämlich genau das, was im Manual beschrieben
>> ist: "Wenn ein numerischer Ausdruck Strings enthält, so werden diese in
>> Fließkommawerte mit doppelter Genauigkeit umgewandelt und es entsteht
>> ein näherungsweiser Ausdruck".
>>
>> http://dev.mysql.com/doc/refman/5.1/de/precision-math-expres sions.html
>
> Vielleicht hinkt das Manual (oder gar Du?) ein bisschen hinter der
> Realität her?

Inwiefern?

> http://bugs.mysql.com/bug.php?id=23260

Hast Du das, worauf Du hier verweist, eigentlich gelesen und auch
verstanden? Ich habe nicht den Eindruck.

> Nicht alles, was im MySQL-Handbuch steht, ist deshalb schon sinnvoll ;-)

Nichtsdestotrotz ist dieses Verhalten dokumentiert und somit kein Bug,
was durch Deinen Link auch bestätigt wird.

Gruß. Claus

Re: mysql bug?

Christian Kirsch schrieb:

>> Es ist IMMER ein Problem, Fließkommazahlen zu vergleichen, egal, ob in
>> C, Java oder MySQL.
>>
>
> Sollte aber DECIMAL(10,2) nicht eine *Fest*kommazahl sein?

Ups, ja, da hast Du recht. Da hab ich eben knapp vorbei argumentiert -
wenn ich auch indirekt wieder richtig lan, da der String intern zu einem
DOUBLE wird...


Thomas