Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Algorithmen, Datenstrukturen und Klassendesign (https://www.delphipraxis.net/78-algorithmen-datenstrukturen-und-klassendesign/)
-   -   Datentypen und Genauigkeitsverluste? (https://www.delphipraxis.net/169452-datentypen-und-genauigkeitsverluste.html)

jfheins 20. Jul 2012 15:38

AW: Datentypen und Genauigkeitsverluste?
 
Zitat:

Zitat von tralala (Beitrag 1175385)
@Jfheinz
warum wird dann an vielen Stellen darauf hingewiesen, das man wenn man mit einem Fließkommawert multiplizieren will man z.b. 2.0 anstatt 2 schreiben soll.
Der Compiler kann doch nicht richen was gemeint ist? Ich bin da unter Java schonmal böse auf die Nase gefallen.

Zeig mal bitte so eine Stelle. Beim Multiplizieren ist es egal, beim Dividieren nicht.
Grund:
Auf der Menge der ganzen Zahlen int kann man Addition, Subtraktion und Multiplikation durchführen, ohne die Menge zu verlassen.
Damit das mit der Division auch klappt, muss man das ganze aber auf den Körper der rationalen Zahlen erweitern.
(Ganze Zahlen = int, rationale Zahlen = Float)
Wenn man also zwei Integer multipliziert, kommt stets eine ganze Zahl raus.
Sobald an einer Rechnung in Java ein Float beteiligt ist, wird das Ergebnis der Rechnung ebenfalls ein Float sein. (Und nicht vorher!)

Bei deinem Beispiel:
Zitat:

Double:= Double * Double; -> zb. X:= 1,15478 * 2 vs. X:= 1,15478 * 2.0
(2 und 2.0 sind in dem Fall konstanten)
Macht das also keinen Unterschied. Da bereits der erste Operand ein Float ist, wird die gesamte Rechnung mit Floats gemacht. Die 2 wird dann einfach konvertiert. Im Rahmen der Maschinengenauigkeit liefern beide Rechnungen das gleiche Ergebnis.

Falls du tatsächlich mal auf die Nase gefallen bist, lag es vielleicht gerade an der Maschinengenauigkeit - das hat dann aber nur bedingt etwas mit der Multiplikation zu tun ;-)

p80286 20. Jul 2012 15:57

AW: Datentypen und Genauigkeitsverluste?
 
@jfheinz
vielleicht ist er ja auch über den Unterschied zwischen Currency und Double gestolpert. Da wird zwar immer wieder darauf hingewiesen, aber oft genug wird Currency als "so 'n neumodisches Zeug" angesehen.

Gruß
K-H

Amateurprofi 20. Jul 2012 19:13

AW: Datentypen und Genauigkeitsverluste?
 
Zitat:

Zitat von tralala (Beitrag 1175369)
Wandelt der Compiler den integer in
1024 oder korrekt in 1024.0 um? Es geht um Nachkommaverluste auf die 8 Stelle
mfg

Zitat:

Zitat von mkinzler (Beitrag 1175371)
Genaugenommen in 0.16E48

Das wären dann 160000000000000000000000000000000000000000000000 ????

Genau genommen ist es so, dass die Double Werte mit FLD xx und der Integerwert mit FILD xx in die FPU geladen werden und dort mit der Genauigkeit der FPU (80 Bit, davon 64 Mantisse, 15 Exponent, 1 Vorzeichen) verarbeitet werden.

himitsu 20. Jul 2012 22:08

AW: Datentypen und Genauigkeitsverluste?
 
Double hat 15–16 signifikante Stellen, demnach kann man, unabhängig vom möglichen Wertebereich (5.0 * 10^-324 bis 1.7 * 10^+308) auf jeden Fall 15 aufeinanderfolgende Dezimalstellen definitiv/sicher verwenden.
Bei 8 Nachkommastellen also noch 7 Vorkommastellen (15-8=7) ... -9999999.99999999 bis +9999999.99999999

Furtbichler 21. Jul 2012 05:31

AW: Datentypen und Genauigkeitsverluste?
 
Wie es bei Java ist, weiß ich nicht, aber bei SQL werden zumindest explizite Datentypen nicht konvertiert.

SQL-Code:
select cast (1 as int)/2
--versus
select myIntField/2 from myTable
-- versus
select 1/2
Bei den ersten beiden Varianten muss eine explizite Typkonvertierung vorgenommen werden, um zum gewünschten Ergebnis zu kommen.

Sicherheitshalber sollten Konstanten stehts als Gleitkomma geschrieben werden, also:
SQL-Code:
select cast (1 as int)/2.0
--versus
select myIntField/2.0 from myTable
-- versus
select 1.0/2.0 -- Hier eigentlich nicht nötig
Vielleicht meint er das.

Wie schon erwähnt: In Delphi ist-das-nicht-n-ö-t-i-g :stupid:


Alle Zeitangaben in WEZ +1. Es ist jetzt 12:01 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz