Datentypen und Genauigkeitsverluste?

[tralala]

Wandelt der Compiler den integer in

1024 oder korrekt in 1024.0 um? Es geht um Nachkommaverluste auf die 8 Stelle

mfg

[mkinzler]

Genaugenommen in 0.16E48

[tralala]

@markus

danke für deine Antwort, nur nutzt sie mir leider nichts. Ich komme aus dem java umfeld und dort führt
es zu großen Ungenauigkeiten wenn man z.B. 2 * 2,5 berechnen möchte und die 2 nicht als 2.0 schreibt.
Es kommt dadurch zu großen Fehlern weil der Nachkommateil bei der Berechnung nicht einbezogen wird.

mfg

[nahpets]

Zitat von tralala:

@markus

danke für deine Antwort, nur nutzt sie mir leider nichts. Ich komme aus dem java umfeld und dort führt
es zu großen Ungenauigkeiten wenn man z.B. 2 * 2,5 berechnen möchte und die 2 nicht als 2.0 schreibt.
Es kommt dadurch zu großen Fehlern weil der Nachkommateil bei der Berechnung nicht einbezogen wird.

mfg

Dieser Effekt ist mir unter Delphi nicht bekannt.

[jfheins]

Zitat von tralala:

@markus
danke für deine Antwort, nur nutzt sie mir leider nichts. Ich komme aus dem java umfeld und dort führt
es zu großen Ungenauigkeiten wenn man z.B. 2 * 2,5 berechnen möchte und die 2 nicht als 2.0 schreibt.
Es kommt dadurch zu großen Fehlern weil der Nachkommateil bei der Berechnung nicht einbezogen wird.
mfg

Das dürfte so nicht stimmen.
Die Ursache dafür ist, dass in java (und vielen Sprachen, die mit C verwandt sind) der Divisionsoperator überladen ist. Und falls man zwei Integer dividiert kommt eben ein Integer als Ergebnis 'raus. Das ist bei der Multiplikation zwar auch so, macht da aber keine Probleme - denn deine 2,5 sind ja bereits ein float. Und damit wird die ganze Rechnung mit floats durchgeführt!

Deshalb ergibt z.B.:
1/120 = 1
1.0/8 = 1/8.0 = 0.125
2*2.5 = 5.0

In Delphi ist der / Operator ausschließlich Gleitkommazahl-Operator - Die Integerdivision geht mit div.

Zitat:

Es geht um Nachkommaverluste auf die 8 Stelle

Kannst du etwas mehr Code posten? Und vielleicht die Zahl, bei der das passiert?

[tralala]

@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.

Double:= Double * Double; -> zb. X:= 1,15478 * 2 vs. X:= 1,15478 * 2.0

(2 und 2.0 sind in dem Fall konstanten)

mfg

[p80286]

Zitat von tralala:

Ich bin da unter Java schonmal böse auf die Nase gefallen.

Wenn das nicht so wäre, gäb es ja nur noch Java...........

Gruß
K-H

[jfheins]

Zitat von tralala:

@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

[Amateurprofi]

Zitat von tralala:

Wandelt der Compiler den integer in
1024 oder korrekt in 1024.0 um? Es geht um Nachkommaverluste auf die 8 Stelle
mfg

Zitat von mkinzler:

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]

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