MS SQL Genauigkeit in der Termauswertung

[TigerLilly]

Das erwischt mich jetzt am falschen Fuß:

Dass das da

Code:

select 12/100*0.5
select 0.5/100*12

nicht dasselbe Ergebnis hat, verstehe ich ja noch.

Aber dass das auch nicht dasselbe Ergebnis hat

Code:

select 0.1*(12/100*0.5)
select 0.1*(0.5/100*12)

hätte ich nicht erwartet.

[peterbelow]

Zitat:

Zitat von TigerLilly (Beitrag 1434446)

Das erwischt mich jetzt am falschen Fuß:

Dass das da

Code:

select 12/100*0.5
select 0.5/100*12

nicht dasselbe Ergebnis hat, verstehe ich ja noch.

Aber dass das auch nicht dasselbe Ergebnis hat

Code:

select 0.1*(12/100*0.5)
select 0.1*(0.5/100*12)

hätte ich nicht erwartet.

Wieso nicht? Wenn der Ausdruck in der Klammer schon nicht gleich ist (siehe oben), wieso soll es dann gleich werden wenn Du beides mit der gleichen Konstanten multiplizierst?

Computer rechnen binär und mit einer limitierten Zahl von Bits pro Variablen. Sowohl die Konvertierung Dezimal nach Binär als auch die Operatione selbst haben deshalb kleine Abweichungen vom mathematisch exakten Ergebnis, weshalb auch das Kommunitativgesetz nicht strikt erfüllt ist: das Ergebnis ist abhängig von der Reihenfolge, in der mathematische Operationen ausgeführt werden.

[hoika]

Hallo,
Firebird macht es richtig ...
Es kommt in beiden Fällen 0.006 raus.

Vielleicht musst du noch ein Cast auf Double Precision machen:
select cast((0.1*(12/100*0.5) as double precision)

[Moombas]

Also generell gilt normalerweise das die Positionen bei Punktrechnung beliebig tauschen kannst.

MS SQL scheint den "Bruch" (12/100 bzw. 0,5/100) nicht zu erkennen und zieht einfach die Punktrechnung vor. Daher bekommst du falsche und verschiedene Ergebnisse:

select 12/100*0.5 => 12/50 = 0.24
select 0.5/100*12 => 0.5/1200 = 0.00041666

Normalerweise wäre 0.06 das richtige Ergebnis.

bzw.

select 0.1*(12/100*0.5) => 0.1*(12/50) = 0.1*0.24 = 0.024
select 0.1*(0.5/100*12) => 0.1*(0.5/1200) = 0.1*0.00041666 = 0.000041666

Normalerweise wäre 0.006 das richtige Ergebnis.


Du müsstest also schreiben (ungetestet):

select (12/100)*0.5 => 0.12*0.5 = 0.06
select (0.5/100)*12 => 0.005*12 = 0.06

bzw.

select 0.1*(12/100)*0.5 = 0.006
select 0.1*(0.5/100)*12 = 0.006

[TigerLilly]

Missverständnis. Erstes und zweites beispiel liefern natürlich unterschiedliche Ergebnisse. Sind ja auch mathematisch was anderes.

Das: select 12/100*0.5 liefert 0, während select 0.5*12/100 das erwartete Ergebnis liefert.

Meine Vermutung war, 12 als Integer die Genauigkeit vorgibt, sprich: keine Kommastellen.
Darum mein Versuch mit select 0.1*12/100*0.5 Kommastellen zu erzwingen, aber nada.

Die Doku sagt, dass Terme - also das 12/100 mit der Genauigkeit ihrer Operanden ausgewertet werden. Also ergibt 12/100 0.

Und nein: Der SQL Server kann schon richtig rechnen: Punkt vor Strich etc.

[TigerLilly]

Zitat:

Zitat von hoika (Beitrag 1434451)

Hallo,
Firebird macht es richtig ...
Es kommt in beiden Fällen 0.006 raus.

Vielleicht musst du noch ein Cast auf Double Precision machen:
select cast((0.1*(12/100*0.5) as double precision)

Das hätte mein versuch mit dem 0.1* erzwingen sollen. Aber auch das CASTen hätte nichts genutzt, da 12/100 eben 0 ergibt.

Ich bin mir jetzt auch keiner Server-Einstellung bewusst, die das beeinflussen könnte.

[Moombas]

Zitat:

Zitat von TigerLilly (Beitrag 1434453)

Die Doku sagt, dass Terme - also das 12/100 mit der Genauigkeit ihrer Operanden ausgewertet werden. Also ergibt 12/100 0.

Müsste dann nicht auch 0.5/100 auch 0 ergeben!? Und da in einer (reinen) Multiplikation einmal eine "0" vor kommt (bei beiden Rechenbeispielen!) wäre das Ergebnis BEIDER Beispiele 0, also sogar gleich. Aber du sagst das Ergebnis sei unterschiedlich, also kann diese Begründung nicht passen.

[Delphi.Narium]

Was kommt denn bei Dir da so raus?

Firebird:

SQL-Code:

select 0.1 * (12 / 100 * 0.5) as a, 0.1 * (0.5 / 100 * 12) as b from dual;

liefert hier 0 und 0

SQL-Code:

select 0.1 * (12 / 100 * 0.500) as a, 0.1 * (0.500 / 100 * 12) as b from dual;

liefert hier 0 und 0,006

SQL-Code:

select 0.100 * (12 / 100.000 * 0.5000) as a, 0.100 * (0.5000 / 100 * 12) as b from dual;

liefert hier 0,006 und 0,006

hä???

Da wird also "innendrinnen" irgendwie implizit gerundet auf die Zahl der da gerade (zufällig) anwesenden oder eben auch nicht anwesenden Nachkommastellen.

Oder anders ausgedrückt:

Wir haben hier Ganzzahl- und Nachkommazahlen.

Da wird eine Typkonvertierung gemacht, entweder auf Ganzzahl oder auf Nachkommazahl. Und dann wird da "irgendwie" entsprechend gerundet ;-)

Achso: Bevor ich es vergesse:

Die Ergebnisse mit einem Delphiprogramm über die ADO-Komponenten (s. o.) sind andere, als die über FlameRobin:

SQL-Code:

select 0.1 * (12 / 100 * 0.5) as a, 0.1 * (0.5 / 100 * 12) as b from dual;

liefert 0,00 und 0,00

SQL-Code:

select 0.1 * (12 / 100 * 0.500) as a, 0.1 * (0.500 / 100 * 12) as b from dual;

liefert 0,0000 und 0,0060

SQL-Code:

select 0.100 * (12 / 100.000 * 0.5000) as a, 0.100 * (0.5000 / 100 * 12) as b from dual;

liefert 0.0060000000 und 0.0060000

Upps :oops:

[Moombas]

@Delphi.Narium: Kannst du mein Beispiel mit der Klammersetzung auch mal ausgeben und Posten (oder rein editieren)? Würde mich einfach mal interessieren.

Zitat:

Zitat von Delphi.Narium (Beitrag 1434459)

Die Ergebnisse mit einem Delphiprogramm über die ADO-Komponenten (s. o.) sind andere, als die über FlameRobin:

SQL-Code:

select 0.1 * (12 / 100 * 0.5) as a, 0.1 * (0.5 / 100 * 12) as b from dual;

liefert 0,00 und 0,00

SQL-Code:

select 0.1 * (12 / 100 * 0.500) as a, 0.1 * (0.500 / 100 * 12) as b from dual;

liefert 0,0000 und 0,0060

SQL-Code:

select 0.100 * (12 / 100.000 * 0.5000) as a, 0.100 * (0.5000 / 100 * 12) as b from dual;

liefert 0.0060000000 und 0.0060000

Upps :oops:

Interessant finde ich, das die Anzahl der Nachkommastellen im Ergebnis jedesmal der Summe der Nachkommastellen in der Rechnung Entspricht. Also sonst auch mal probieren (wo man auch immer die Stellen platziert, wenn man vorher wissen muss wie viele Nachkommastellen man haben muss finde ich das Suboptimal):

SQL-Code:

select 0.1 * (12 / 100 * 0.50) as a, 0.1 * (0.50 / 100 * 12) as b from dual;

[hoika]

Hallo,

12/100.00 vielleicht?

[TigerLilly]

Ja, so erhalte ich das erwartete Ergebnis. Wir haben eine Tabelle mit Formeln, die vom SQL Server ausgewertet werden + ich bin sehr sehr sicher, dass das früher anders funktioniert hat. Der 2008R2 ist schon Jahre im Einsatz + das Problem ist jetzt erst aufgepoppt.

Wir werden wohl in allen Formeln die Skalare mit .0 ergänzen. :-(

[jobo]

keine Ahnung ob diese Beobachtung nun so ist wie sie ist, aber wenn, dann:
Mal bei MS nachschlagen, solche Änderungen werden eigentlich nicht "einfach so" mal ins Feld geworfen. Es müsste dazu Migrationshinweise geben und normalerweise auch Schalter, die das (alte) Verhalten bewahren, forcieren usw.

Kommt natürlich bei der Art der Anpassung auf das zu erwartende Änderungesvolumen an und wie exakt man die Problemstellung überhaupt finden kann.

[hoika]

Hallo,
hm, also hier

https://docs.microsoft.com/en-us/pre...v%3dsql.110%29

steht

The precision and scale of the numeric data types besides decimal are fixed. If an arithmetic operator has two expressions of the same type, the result has the same data type with the precision and scale defined for that type.

Und weiter unten ist noch eine Tabelle.

Das war also schon immer so, zumindestens beim 2012-er

[TigerLilly]

Vielleicht ist das bei uns auch einfach durchgerutscht und die Erinnerung siegt über Tatsachen. Oder - wie es so schön heisst: Die Wahrheit ist eine Tochter der Zeit.

Das Problem gibt es wahrscheinlich auch nur, wenn man das SQL Statement als Text zusammenbaut, sonst hat man eh Paramter und passende Datentypen.

Aber zum Merken: <int> <op> <int> liefert <int>.

[Delphi.Narium]

Delphi und ADO:

SQL-Code:

select 12/100*0.5 from dual; => 0
select 0.5/100*12 from dual; => 0

select 0.1*(12/100*0.5) from dual; => 0
select 0.1*(0.5/100*12) from dual; => 0

select (12/100)*0.5 from dual; => 0
select (0.5/100)*12 from dual; => 0

select 0.1*(12/100)*0.5 from dual; => 0
select 0.1*(0.5/100)*12 from dual; => 0

FlameRobin

SQL-Code:

select 12/100*0.5 from dual; => 0,0
select 0.5/100*12 from dual; => 0,0

select 0.1*(12/100*0.5) from dual; => 0,00
select 0.1*(0.5/100*12) from dual; => 0,00

select (12/100)*0.5 from dual; => 0,0
select (0.5/100)*12 from dual; => 0,0

select 0.1*(12/100)*0.5 from dual; => 0,00
select 0.1*(0.5/100)*12 from dual; => 0,00

Zitat:

Zitat von Moombas (Beitrag 1434460)

Interessant finde ich, das die Anzahl der Nachkommastellen im Ergebnis jedesmal der Summe der Nachkommastellen in der Rechnung Entspricht.

Nein, das ist nicht interessant, haben wir schon in der Schule gelernt: Wenn man zwei Zahlen mit Nachkommastellen multipliziert, so erhält man im Ergebnis soviele Nachkommastellen, wie die multiplizierten Zahlen zusammen enthalten.

Zwei Nachkommastellen * zwei Nachkommastellen = 4 Nachkommastellen.

https://de.bettermarks.com/mathe/mul...dezimalzahlen/

Ok, wenn man sich das Ergebnis über FlameRobin anschaut, so stimmt das, die Regel wird eingehalten.

Über Delphi und ADO werden die Nachkommastellen (bei Beachtung der Regel) jedoch nur ausgegeben, wenn sie <> 0 sind.

Taschenrechner & Co. scheinen da etwas "flexibler" zu sein, sie erweitern die Nachkommastellen implizit, wenn es für eine korrekte Darstellung des Ergebnisses erforderlich scheint.

Fazit: Rechnen über Select nur, wenn man sich der Einhaltung dieser Regel bewusst ist.

[TigerLilly]

Du machst die Sache kompliziert, denn hier geht es um MS-SQL Server. DUAL gibt es für den nicht und wie ich beschrieben habe, sind die Ergebnisse andere:

select 12/100*0.5 --> 0
select 0.5/100*12 --> 0,06

[p80286]

Von einer nicht ganz kleinen DB bin ich es gewohnt,daß ich für jeden numerischen Wert das gewünschte Ausgabeformat definiert habe. Und das hat ganz gut funktioniert.
Mit irgendwelchen Seiteneffekten zu rechnen ohne daß mich jemand für meine Genialität feiert war mir auf Dauer zu anstrengend.

Gruß
K-H

[TigerLilly]

Verstehe ich nicht. Was meinst du damit?

[Moombas]

Zitat:

Zitat von Delphi.Narium (Beitrag 1434469)

Zitat:

Zitat von Moombas (Beitrag 1434460)

Interessant finde ich, das die Anzahl der Nachkommastellen im Ergebnis jedesmal der Summe der Nachkommastellen in der Rechnung Entspricht.

Nein, das ist nicht interessant, haben wir schon in der Schule gelernt: Wenn man zwei Zahlen mit Nachkommastellen multipliziert, so erhält man im Ergebnis soviele Nachkommastellen, wie die multiplizierten Zahlen zusammen enthalten.

Jaein, denn: Nimmst du 0,1*0,1 stimmt die Aussage (=0,01) ABER: nimmst du 0,1*1,0 wäre das korrekte Ergebnis 0,1 (die nachstehenden Nullen sind irrelevant, da 0,1 = 0,10).
Und warum das in DIESEM Fall durchaus interessant ist: Das Ergebnis der Rechnung wäre 0,006 (3 Nachkommastellen), wenn nun aber in der Rechnung (0.1 * (0.5 / 100 * 12)) nur 2 Nachkommastellen vorkommen und daher davon ausgegangen wird, das man nur 2 Nachkommastellen braucht ist das Ergebnis logischerweise Falsch!
Folglich müsste man generell mit der maximal möglichen Anzahl an Kommastellen rechnen um einigermaßen vernünftig rechnen zu können (und keine Angst haben muss, das dadurch Kommastellen schlichtweg gestrichen werden). Daher:
0.1 * (0.5 / 100 * 12) = 0.00
0.1 * (0.50 / 100 * 12) = 0.006 (?)

@Tigerlilly:

Zitat:

Zitat von TigerLilly (Beitrag 1434479)

Du machst die Sache kompliziert, denn hier geht es um MS-SQL Server. DUAL gibt es für den nicht und wie ich beschrieben habe, sind die Ergebnisse andere:

select 12/100*0.5 --> 0
select 0.5/100*12 --> 0,06

Was ist denn das Ergebnis wenn du folgende Rechenoperationen ausführst:
select (12/100)*0.5 --> ?
select 12/100*0.50 --> ?

[Schokohase]

Nur damit wir alle auf dem gleichen Stand sind

SQL-Code:

select 1,12/100*0.5
union
select 2,0.5/100*12
union
select 3,0.1*(12/100*0.5)
union
select 4,0.1*(0.5/100*12)
union
select 5,0.1*12/100*0.5
union
select 6,0.1*0.5/100*12

ergibt auf dem MS SQL 2017 ausgeführt

Code:

1 - 0
2 - 0.06
3 - 0
4 - 0.006
5 - 0.006
6 - 0.006

Beispiel auf SQLfiddle

Warum also jetzt der Unterschied zwischen Zeile 3 und Zeile 5?

Ganz einfach:

Es wird in Zeile 3 erst der Wert in den Klammern berechnet, und der ergibt (wie man in Zeile 1 sehen kann) eben 0 und diese 0 mit 0.1 multipliziert ergibt weiterhin 0.

Das ist das ganze Geheimnis

PS
Der wirkliche Problemauslöser ist die Division von zwei Ganzzahlen 12/100. Es würde reichen eine davon als Fließkommazahl zu deklarieren. Also 12/100.0 oder 12.0/100.

[TigerLilly]

Zitat:

Zitat von Moombas (Beitrag 1434498)

0.1 * (0.5 / 100 * 12) = 0.00
0.1 * (0.50 / 100 * 12) = 0.006 (?)

Also, das ist jetzt ein bissl off-topic, aber zurück zu dem, was der MS-SQL wirklich ausgibt:

0.1 * (0.5 / 100 * 12) = 0.006
0.1 * (12 / 100 * 0.5) = 0.0

(0.5 / 100 * 12) = 0.06
(12 / 100 * 0.5) = 0.0
(12.0 / 100 * 0.5) = 0.06
(12 / 100.0 * 0.5) = 0.06

Wie gesagt: die Genauigkeit einer Operation wird durch die Genauigkeit ihrer Operanden definiert. Daher ergibt 12/100 IMMER(!) 0, egal wo im Term es steht.

Jetzt weiß ich es. :thumb:

[Schokohase]

Zitat:

Zitat von TigerLilly (Beitrag 1434500)

Wie gesagt: die Genauigkeit einer Operation wird durch die Genauigkeit ihrer Operanden definiert. Daher ergibt 12/100 IMMER(!) 0, egal wo im Term es steht.

Jetzt weiß ich es. :thumb:

Nein, du liegst leider falsch, denn

SQL-Code:

select 0.5*12/100

ergibt 0.06.
SQLfiddle

Aber jetzt solltest du wissen sehen, warum

[Moombas]

Zitat:

Zitat von TigerLilly (Beitrag 1434500)

Zitat:

Zitat von Moombas (Beitrag 1434498)

0.1 * (0.5 / 100 * 12) = 0.00
0.1 * (0.50 / 100 * 12) = 0.006 (?)

Also, das ist jetzt ein bissl off-topic, aber zurück zu dem, was der MS-SQL wirklich ausgibt:

0.1 * (0.5 / 100 * 12) = 0.006
0.1 * (12 / 100 * 0.5) = 0.0

(0.5 / 100 * 12) = 0.06
(12 / 100 * 0.5) = 0.0
(12.0 / 100 * 0.5) = 0.06
(12 / 100.0 * 0.5) = 0.06

Wie gesagt: die Genauigkeit einer Operation wird durch die Genauigkeit ihrer Operanden definiert. Daher ergibt 12/100 IMMER(!) 0, egal wo im Term es steht.

Jetzt weiß ich es. :thumb:

Falsch, denn sobald du mit 0 Multiplizierst ist das Ergebnis IMMER 0, aber du beweist ja auch:
(12.0 / 100 * 0.5) = 0.06 //Wäre 12.0 / 100 = 0, wäre das Ergebnis auch 0!
(12 / 100.0 * 0.5) = 0.06 //Wäre 12 / 100.0 = 0, wäre das Ergebnis auch 0!
Somit musst du die erforderliche Anzahl der Kommastellen in der Rechnung angeben, damit nicht abgeschnitten wird!
Ergo fehlt bei der Rechnung (12 / 100 * 0.5) = 0.0 nur eine Kommastelle und hätte drei mögliche Varianten um das richtige Ergebnis zu erhalten:

• (12.0 / 100 * 0.5) müsste = 0.06
• (12 / 100.0 * 0.5) müsste = 0.06
• (12 / 100 * 0.50) müsste = 0.06

Edit wegen Schokohases Post: Wenn die Reihenfolge scheinbar bei MS SQL einen Unterschied in der Rechnung bzw. im Ergebnis macht, sollte man sich ggf. nochmal mit der Rechnungslogik in MS SQL befassen, denn hier scheint es doch noch mehr Besonderheiten zu geben worauf zu achten ist. (Danke für den Link :) )

[TigerLilly]

@schokohase: Ja, stimmt, ich hab´s ungenau formuliert, es kommt ja auf die Reihenfolge der Auswertung an. In deinem Beispiel wird 12/100 ja gar nicht ausgewertet.

[TigerLilly]

Zitat:

Zitat von Moombas (Beitrag 1434502)

• (12.0 / 100 * 0.5) = 0.06
• (12 / 100.0 * 0.5) = 0.06
• (12 / 100 * 0.50) = 0.06

Das 3te ist falsch, da kommt auch 0 raus, weil 12/100 sich zu 0 berechnet.

[Schokohase]

Zitat:

Zitat von TigerLilly (Beitrag 1434503)

Ja, stimmt, ich hab´s ungenau formuliert, es kommt ja auf die Reihenfolge der Auswertung an. In deinem Beispiel wird 12/100 ja gar nicht ausgewertet.

Wieso wird in meinem Beispiel 12/100 nicht ausgewertet?

Du meinst sicherlich, in meinem Beispiel kommt es bei der Berechnung (die von links nach rechts erfolgt) nicht zu der Integer-Division von 12 und 100.

Es wird also erst 0.5 * 12 errechnet (= 6.0)
und dann 6.0/100 (= 0.06)

[Moombas]

Entfernt, da falsch.

[TigerLilly]

Zitat:

Zitat von Moombas (Beitrag 1434507)

Code:

select (12/100)*0.5 = 0.06 //Dank Schokohase konnte ich es testen.

Nein, das ergibt auch 0. Also zumindest beim MSSQL.

Zitat:

Also wie ich bereits am Anfang sagte erkennt MS SQL den Bruch nicht und du musst ihn einklammern!

Nein, das hat mit bruch erkennen nichts zu tun, sondern mit der Genauigkeit der Berechnung. Zwei ganzzahlige Operatoren haben ein ganzzahliges Ergebnis. Der bruch wird schon richtig gerechnet, aber nicht mit der erwarteten Genauigkeit.

[Schokohase]

Zitat:

Zitat von Moombas (Beitrag 1434507)

Code:

select (12/100)*0.5 = 0.06 //Dank Schokohase konnte ich es testen.

Ja, können wir auch SQLfiddle und sehen 0

[Moombas]

Bekloppt, habe die Seite neu geladen und das nun nochmal eingegeben und erhalte nun AUCH 0.... dann habe ich dahingehend nichts gesagt -.- (Anwender Fehler, habe den Code von links nicht nach rechts NEU kopiert^^)

Dennoch scheint man mehr als die "normalen" Rechenregeln in MS SQL bedenken zu müssen.

Zitat:

Zitat von TigerLilly (Beitrag 1434505)

Zitat:

Zitat von Moombas (Beitrag 1434502)

• (12.0 / 100 * 0.5) = 0.06
• (12 / 100.0 * 0.5) = 0.06
• (12 / 100 * 0.50) = 0.06

Das 3te ist falsch, da kommt auch 0 raus, weil 12/100 sich zu 0 berechnet.

Also muss im Bruch auch mindestens eine Zahl eine Kommazahl sein, damit er mit Kommastellen rechnet (!?) und du somit das richtige Ergebnis bekommst. Wobei dann wirklich egal ist wie viele Kommastellen man in der Rechnung angibt:

select 12 / 100 = 0;
select 12 / 100.0 = 0.12;

[Moombas]

blöder Doppelpost -.-

[TigerLilly]

Zitat:

Zitat von Moombas (Beitrag 1434513)

und du somit das richtige Ergebnis bekommst.

Verwechsle "richtig" nicht mit "erwartet". Richtig ist es jetzt auch. Für mich war´s unerwartet.

[Moombas]

Zitat:

Zitat von TigerLilly (Beitrag 1434520)

Zitat:

Zitat von Moombas (Beitrag 1434513)

und du somit das richtige Ergebnis bekommst.

Verwechsle "richtig" nicht mit "erwartet". Richtig ist es jetzt auch. Für mich war´s unerwartet.

Naja, wenn ich eine Rechnung (12 / 100 * 0.5) habe und als Ergebnis 0 erhalte, obwohl die Rechnung nach (normalen) Rechenregeln 0.06 ergibt, ist 0 ein falsches Ergebnis (aus rein mathematischer Sicht).

[Schokohase]

Zitat:

Zitat von Moombas (Beitrag 1434522)

Zitat:

Zitat von TigerLilly (Beitrag 1434520)

Zitat:

Zitat von Moombas (Beitrag 1434513)

und du somit das richtige Ergebnis bekommst.

Verwechsle "richtig" nicht mit "erwartet". Richtig ist es jetzt auch. Für mich war´s unerwartet.

Naja, wenn ich eine Rechnung (12 / 100 * 0.5) habe und als Ergebnis 0 erhalte, obwohl die Rechnung nach (normalen) Rechenregeln 0.06 ergibt, ist 0 ein falsches Ergebnis (aus rein mathematischer Sicht).

Man muss aber immer den Kontext sehen und richtig ist im Prinzip beides.

Denn auch in der Mathematik gibt es Ganzzahl-Divisionen. Man muss sich allerdings wissen ob diese Ganzahl-Division explizit oder implizit ist.

In Delphi ist diese explizit (mit

Delphi-Quellcode:

DIV

) und im Microsoft-Umfeld (SQL-Server, C#, ...) ist diese implizit.