...
Hat Double Precicion nicht das gleiche Problem wie die anderen "natürlichen" floats, dass 0 nicht gleich 0 ist ?
Eins der probleme, welche ch immer wieder habe ist das physikalisch meine Inventarmenge 0 ist, aber beim Berechnen in firebird sowas wie 0.00000046784345 rauskommt, und das dann ich Berechnungen zu riesig grossen zahlen führt, die einen überlauf produzieren..
inventarmengen bei Zählbaren Artikel sind sicherlich ganzzahlig, bei anderen Mengeneinheiten kann das aber ganz anders aussehen, Schrauben werden ja trotzdem gerne gewogen statt gezählt, weil zählen Schwachsinn ist, Draht wird in Meter gezählt oder auch gewogen, taucht aber in cm oder mm in Stücklisten auf usw.
Das Problem ist dir sicherlich bekannt.
Aus meiner hat aber der Wert 0 erst mal auch den exakten Wert 0, aber wenn 0 aus einer anderen als einer konstanten Quelle kommt, kann das zwar wie 0 aussehen, aber bei den Nachkommastellen ganz hinten wie du sagst anders aussehen. Trotzdem arbeitet der Double Precision eigentlich ganz sauber (zumindest in Firbeird und bitte niemals mit dem Typ Float arbeiten, der taugt nix).
Für technischen Kram nehm ich ganz gerne Double Precision, für kaufmännischen Kram Numeric, es gibt aber nicht den Typ für alles (und das weiss ich schon seit der Euroumstellung, da hat auch diverse Software eher ungefähre Schätzwerte ermittelt, wenn der Eurofaktor mit größeren Zahlen ermittelt wurde).
Mein Lieblingsbeispiel aus Schulungen, das den Unterschied von Numeric(15,2) im Dialekt 1 (dort gepeichert als Double Precision) und Numeric(15,2) im Dialekt 2 (dort gespeichert als BigInt, also Int64).
Deine Software wird für die Abrechnung einer Konditorei benutzt und die stellt Torten her, die 10 Euro kosten. Aufgteilt ist 3 Stücke ermittelt deine Software nun einen Preis von 3,33 € pro Stück (im Double Precision wird aber eigentlich 10/3 gespeichert, Ergebnis also eigentlich 3,333333333333 usw.) Nun kommt Oma Schmidt in den Laden, kauft 3 Stück Torte zu je 3,33 € und deine Kassensoftware ermittelt auf Basis vom Double Precision als Summe 10 €. Viel Spass bei der Diskussion mit Oma Schmidt.
Wer seinen Tankwart mal ärgern will: einfach mal beim Tanken noch ein paar andere Artikel kaufen, (zB eine Zeitschrift, weil die 7% Steuer hat) und sich danach mal die Nachkommastellen aller Produkte anschauen und auch bei den Teilsummen der unterschiedlichen Steuern anschauen und zusammenrechnen. Es kommt nicht selten vor, das die Zahlen da zusammengerechnet nicht zu dem passen was man am Ende zahlen soll. Das liegt u.a. an der 3. Nachkommastelle bei den Spritpreisen. da ist auch scheinbar manche Kassensoftware überfordert. Dem armen unterbezahlten Menschen an der Kasse ist das aber ziemlich sicher scheissegal.
Hier noch ein Code Beispiel für Firebird, an dem man sehen kann, das Double ganz gut arbeitet:
Code:
execute block
returns
(dval double precision,
txt varchar(80))
as
declare variable v1 double precision;
declare variable v2 double precision;
begin
v1=0;
v2=3.141592653589793;
dval=v1*v2;
txt=dval;
suspend;
v1=1;
v2=3.141592653589793;
dval=v1*v2;
txt=dval;
suspend;
v1=1.0001;
v2=0.0001;
dval=v1*v2;
txt=dval;
suspend;
end
result in IBExpert (im Grid wäre DVAL auf 3 stellen gerundet, beim Export aber nahezu komplett)
DVAL TXT
0 0.0000000000000000
3,14159265358979 3.141592653589793
0,00010001 0.0001000100000000000