bei folgendem Code verstehe ich nicht warum er mir

#include <iostream>
#include <iomanip>

int main() {
        double a;
        double b;
        a = 0.2e-07;
        b = 2.23e09;
        std::cout <<  std::setprecision(20) << a+b << std::endl;

        return 0;
}

2230000000

als ergebnis bekomme. also warum die 0.1 nicht erscheint?
warum ist das so? hängt das mit der darstellung von float-zahlen zusammen und wenn ja - kann mir das jemand genauer erklären?

danke euch

Wenn du mittelkomplizierte Dinge mit Flieskommazahlen vor hast, dann solltest du deren Grundlagen kennen:
http://en.wikipedia.org/wiki/Floating_point
Für größere Vorhaben solltest du auch das Expertenwissen zumindest mal angesehen haben:
http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

das müsste doch reichen oder? Also die zahl (aus erstem post) passt doch in diesen bereich rein oder bringe ich da etwas durcheinander?

Edit: Auch wenn der Compiler dir Recht gibt...

Lies einfach den Artikel. Hier interessiert wieviel signifikante Stellen es gibt. Nicht wie groß (oder klein).

heisst dass das ich dann 2^52 ungefährt = 4.5*10^15 und deswegen das die maximalste zahl ist die ich darstellen kann?

Da musst du mir jetzt aber was erklären, Sepp
0.2e-07 ist - wenn ich richtig sehe - 0.2 hoch -7 , also einfach 1 / 0.2 hoch 7 , 0.2 hoch 7 ist circa 0.0000128 . Und 1 / 0.0000128 ist doch wohl kaum 0.000 ...?

Edit: Auch wenn der Compiler dir Recht gibt...

0.2e-07 ist $0.2\cdot 10^{-7}$. Deine Schreibweise, $0.2e-07 = 0.2^{7}$ könnte kein Mensch lesen, so gut sind wir einfach nicht im Kopfrechnen. Schätze schnell ab: Was ist größer? $0.7^{31}$ oder $0.2^7$? Und nicht schummeln! Gar nicht so einfach, oder?

frakccc schrieb:

heisst dass das ich dann 2^52 ungefährt = 4.5*10^15 und deswegen das die maximalste zahl ist die ich darstellen kann?

Nein, das ist Unsinn. Wenn dir schon ein Wikipediaartikel verlinkt wird, dann lies ihn bitte auch so weit, dass du wenigstens die Grundlagen kennst. Deine Beobachtung hat jedoch etwas damit zu tun, dass die Anzahl der signifikanten Stellen (im Dezimalsystem gerechnet) ungefähr 15.9 ist. Du hast jedoch ein paar der Grundlagen noch nicht gelesen, darum kommt bei dir ein bisschen weniger raus.

Hacker schrieb:

Da musst du mir jetzt aber was erklären, Sepp
0.2e-07 ist - wenn ich richtig sehe - 0.2 hoch -7 , also einfach 1 / 0.2 hoch 7 , 0.2 hoch 7 ist circa 0.0000128 . Und 1 / 0.0000128 ist doch wohl kaum 0.000 ...?

Edit: Auch wenn der Compiler dir Recht gibt...

0.2e-07 ist $0.2\cdot 10^{-7}$. Deine Schreibweise, $0.2e-07 = 0.2^{7}$ könnte kein Mensch lesen, so gut sind wir einfach nicht im Kopfrechnen. Schätze schnell ab: Was ist größer? $0.7^{31}$ oder $0.2^7$? Und nicht schummeln! Gar nicht so einfach, oder?

Sag doch gleich, dass es die wissenschaftliche Schreibweise war...

double ist ungefähr auf 15 Dezimalstellen genau

also ich hab ihn jetzt (nicht ganz) aber wesentlich durchgearbeitet und kann mir die frage immer noch nicht beantworten:

significand hat doch 52 Bit. also kann ich damit schon mal 2^52 Zahlen darstellen oder?

diese kann ich jetzt noch über den exponenenten steuern also vergrößern oder verkleinern.

wie kommt man auf die 15 stellen genauigkeit?

significand hat doch 52 Bit. also kann ich damit schon mal 2^52 Zahlen darstellen oder?

Rechne mal $2^{52}$ aus. Wieviele Stellen hat die Zahl?

Grüssli

4503599627370496

hat also 16 stellen. hmm...ne sorry ich komm einfach nicht drauf. deswegen wende ich mich ja an euch. ich kann doch die größe der zahl noch über den exponenten steuern. meine ursprungszahl war:

2230000000.0000002

was normalisiert
2.2300000000000002 * exp=9 wäre.

ich begreife den zusammenhang zwischen anzahl stellen und anzahl bits nicht...

Grüssli

frakccc schrieb:

significand hat doch 52 Bit. also kann ich damit schon mal 2^52 Zahlen darstellen oder?

Rechne mal $2^{52}$ aus. Wieviele Stellen hat die Zahl?

Grüssli

Ich mache eine Schätzung: $2^{10}$ ist circa $10^{3}$, also ist $2^{52}$ circa $10^{52 * 3 / 10}$ = $10^{15.6}$ = $10^{16}$, hat also circa 16 Stellen. Richtig?

Ich hätte leider immer noch fragen und würde mich über Antworten freuen:

Die significand hat 52 Bit also kann ich alle zahlen die mit 52 Bit darstellbar sind
exakt darstellen, alle anderen die größer sind nicht mehr?

Ist also die Normalisierung schuld an dem rundungsfehler?

Was ich nicht verstehe: eine natürliche zahl könnte doch über weniger
bit-stellen darstellbar sein oder nicht? oder kann das immer ausgeschlossen werden?

danke

Mantisse * 10^Exponent

Der Speicherplatz ist begrenzt; dir stehen drei Ziffern für den Exponenten zur Verfügung, sechzehn für die Mantisse und außerdem genug für das Vorzeichen des Exponenten sowie das Vorzeichen des gesamten Ausdrucks. So schreibt man

2⁶⁴ ≈ +1.844674407370955 * 10⁺¹⁹

Das ist nicht ganz genau, aber mit den gegebenen Einschränkungen geht es nicht besser. Dafür kann man aber

2^-64 ≈ +0.5421010862427522 * 10^-19

schreiben, was ebenfalls nicht ganz genau ist (aber bedeutend genauer als null).

In dieser Weise verfährt auch ein ieee754-Double, nur dass statt dezimalen binäre Ziffern verwendet werden und der Exponent auf eine Weise gespeichert wird, die die gesonderte Speicherung seines Vorzeichens unnötig macht. Die (ungefähr) 15 Ziffern kommen zustande, weil double 53 Bit Mantisse (eins davon implizit) hat und

log₁₀(2⁵³) ≈ 15,95.

ist. Die Sprechweise "x Stellen Genauigkeit" ist eigentlich nicht ganz richtig; ein Rundungsfehler kann sich sehr weit nach vorne durchsetzen, wenn die Bedingungen gegeben sind - denk an 0,999999... Eigentlich geht es hier um eine relative Fehlerschranke -- letztendlich läuft es darauf hinaus, dass double beliebige Zahlen innerhalb seines Wertebereichs (etwa -10³⁰⁸ bis 10³⁰⁸) mit einem relativen Fehler von 10^-15,95 kodieren kann. Der absolute Fehler hängt von der kodierten Zahl ab und kann dementsprechend bedeutend größer oder kleiner sein.

Merke: Dass double Zahlen mit einem relativen Fehler von 10^-15,95 kodieren kann, bedeutet nicht, dass deine Ergebnisse immer diese Genauigkeit haben. Das relevante(ste) Stichwort ist Auslöschung.

~edit durch SeppJ: Link korrigiert~

seldon: dein Link ist tot. Kennst du noch was anderes?

Guck dir die Adresszeile doch mal genau an, wie man die wohl korrigieren könnte.

Hacker schrieb:

seldon: dein Link ist tot. Kennst du noch was anderes?

Guck dir die Adresszeile doch mal genau an, wie man die wohl korrigieren könnte.

Ups . Editier das mal, Sepp.