Rundung?
-
frakccc schrieb:
significand hat doch 52 Bit. also kann ich damit schon mal 2^52 Zahlen darstellen oder?
Rechne mal aus. Wieviele Stellen hat die Zahl?
Grüssli
-
2^52 ist so viel wie 1024^5*4 ist also etwa 4 Billiarden + ein paar zerquetschte.
-
edit: Ach, ich denke zu englisch. Billiarden sind ja was anderes im Deutschen.
-
also die zahl ist
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...
-
Einfaches Beispiel weg von den Gleitkommazahlen:
Du willst die Zahl 5234 darstellen. Du kannst maximal 2 Stellen genau darstellen und kannst den Exponenten unendlich gross machen. Dann kannst du also schreiben. Der Exponent verschiebt die Ziffern nur, er sorgt nicht dafür, dass die Zahl irgendwie genauer wird. Es bleibt dabei, dass nur 2 Stellen korrekt sind.Grüssli
-
Dravere schrieb:
frakccc schrieb:
significand hat doch 52 Bit. also kann ich damit schon mal 2^52 Zahlen darstellen oder?
Rechne mal aus. Wieviele Stellen hat die Zahl?
Grüssli
Ich mache eine Schätzung: ist circa , also ist circa = = , hat also circa 16 Stellen. Richtig?

-
ALso erstmal danke an eure Geduld. Ich bin leider hier immer noch anfänger und würds dennoch gern verstehen:
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
-
Vielleicht hilft es dir, dir das ganze in einem (virtuellen) dezimalen Computer vorzustellen. Stell dir vor, du musst Dezimalzahlen abspeichern, und das vereinbarte Format, in dem du diese schreiben darfst, ist
Mantisse * 10Exponent
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
264 ≈ +1.844674407370955 * 10+19
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
log10(253) ≈ 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 -10308 bis 10308) 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?
-
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.
-
SeppJ schrieb:
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.