Diskussion:IEEE 754

Frage nach Beispielen

Wie wäre es mit ein paar Beispielen zu Rechenoperationen und Umwandlung in Dezimalzahlen?

Bitte ansehen:

http://de.wikipedia.org/w/wiki.phtml?title=IEEE_754&diff=1277693&oldid=1277674

Die dritte Änderung bedarf der Diskussion am dringendsten. Ich finde die Formulierungen zu schwammig:

• ein "Programm" kann ein Pascal-Quelltext oder ein Binärprogramm sein, gemeint ist hier Quelltext)

Mein Versuch (auch nicht gerade schön):

Vor Einführung der Norm gab es viele unterschiedliche Prozessoren, die die Fließkommaberechnungen ausführten. Diese Prozessoren verwendeten unterschiedliche Datenformate und rechneten auch unterschiedlich genau. [stimmt "unterschiedlich genau"?]

Es konnte also sein, dass bei der Addition 2.123456 + 3.1415926 auf verschiedenen Rechnern auch unterschiedliche Resultate herauskamen. Um das zu verhindern, wurden zwei Standardformate für Fließkommazahlen definiert. Weiter wird definiert, dass die Berechnung der Summe erstmal mit unendlich großer Genauigkeit geschieht und dass danach soweit gerundet wird, wie es das Datenformat erfordert.

[Hier wären ein paar Beispiele ganz nett.]

Ich kümmere mich mal darum, kann aber ne Weile dauern. Anregungen sind willkommen. --RokerHRO 00:09, 5. Okt 2004 (CEST)

NZ

In der Tabelle steht was von "NZ", ohne dass das Kürzel erklärt wird. Wer kann abhelfen? --Nomeata 10:43, 7. Nov 2005 (CET)

Das soll wohl "Werte der Charakteristik bei normalisierten Zahlen" heißen. --RokerHRO 11:06, 7. Nov 2005 (CET)

Doch, das Kürzel wurde ganz oben bei der ersten Erwähnung der normalisierten Zahlen eingeführt. Es wurde verwendet, um die Tabelle schmal zu halten.

brf

Sehr unstrukturiert

Dieser Artikel ist sehr unstrukturiert. Das ist schade, denn der IEE 754 (1985)-Standard ließe sich eigentlich recht einfach rüberbringen, oder? Der Artikel braucht daher dringend ein "didaktisches Facelifting" ;) --Elwood j blues 16:09, 21. Aug 2004 (CEST)

Ich kümmere mich darum. Aber das kann eine Weile dauern. --RokerHRO 00:10, 5. Okt 2004 (CEST)

Umwandlung?

"Als Beispiel soll 166,125 unmgewandelt werden." Danach wird 166,125 Dezimal mit 10100110,001 gleichgesetzt, evtl. wäre es noch hilfreich zu erklären, warum 0,125 (Dez) = ,001 (binär) ist?

• 0,125 (Dez) = ,001 (binär)

die Rechnung geht genau wie bei den Zahlen links von Komma, nur sind hier die Exponenten von negativ.
 => 0 * 2^(-1) + 0 * 2^(-2) + 1 * 2^(-3)
 => 0 * 1/2    + 0 * 1/4    + 1 * 1/8
 => 0 * 0.5    + 0 * 0.25   + 1 * 0.125

alles klar?

Fortran?

"Auch gibt es Programmiersprachen, die für numerische Berechnungen optimiert sind, z.B. Fortran." Was hat das mit IEEE 754 zu tun? --NeoUrfahraner 10:53, 28. Mär 2005 (CEST)

IMHO nix, des Satz gehört ersatzlos gestrichen. Im wahren Leben benutzen Fortran-Implementierungen einfach die Gleitkomma-Arithmetik, die die Zielplattform zur Verfügung stellt, genau wie andere Programmiersprachen auch. Von der Arithmetik ist es in der Regel kein Unterschied, ob man ein Programm in Fortran, C oder Pascal schreibt. Gerade IEEE 754 hat dazu beigetragen, dass nun plattformübergreifend eine vernünftige Gleitkommaarithmetik zur Verfügung steht und Abweichungen von obiger Regel immer seltener werden. Die anderen Unterschiede zwischen Programmiersprachen haben mit der Norm und mit dem weiteren Kontext Gleitkommaarithmetik nix zu tun. -- T.Nitz, 20:00, 07. Jan 2006 (CET)

Hab's gestrichen. --NeoUrfahraner 07:02, 13. Jan 2006 (CET)

Terminologie: "Fließkommazahl" oder "Gleitkommazahl"?!

Können wir uns vielleicht darauf einigen, nur einen dieser beiden Begriffe zu gebrauchen? Ich würde das m.E. gebräuchlichere "Gleitkommazahl" vorziehen. — Falls wir uns dennoch auf "Fließkommazahl" einigen, sollten wir den Artikel Gleitkommazahl entsprechend umbenennen / verschieben! — Nol Aders 23:44, 5. Jun 2005 (CEST)

Doppelspurigkeit zu Gleitkommazahl

Dieser Artikel überlappt inhaltlich mit Gleitkommazahl (z.B. Normalisierung, Hidden Bit, &c.)

Vorschlag: Die beiden Artikel aufeinander abstimmen in folgendem Sinn: IEEE 754 ist ein Standard für binäre Gleitkommazahlen; hier alles beschreiben, was zu diesem Standard gehört, also Binäre Darstellung, Hidden Bit, &c. — Dort unter Gleitkommazahl nur den allgemeinen Fall abhandeln mit beliebiger Basis b, &c., aber alles über den Spezialfall b=2 und den Standard IEEE 754 rausnehmen. -- Nol Aders 23:33, 5. Jun 2005 (CEST)

Weblinks

Ich denke, viele (d.h. mehr als fünf!) der folgenden Weblinks stellen das Thema gut dar — welches findet Ihr die wichtigsten?

1. http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm — Bruce Dawson: Comparing Floats. Excellent article on the traps, pitfalls and solutions for comparing floating point numbers. Hint — epsilon comparison is usually the wrong solution.
2. http://stevehollasch.com/cgindex/coding/ieeefloat.html — Steve Hollasch: "IEEE Standard 754 Floating Point Numbers" — Last update 2005-Feb-24
3. http://cch.loria.fr/documentation/IEEE754/ — IEEE standard 754 for binary floating-point arithmetic
4. http://grouper.ieee.org/groups/754/ — Die offizielle Website der IEEE-Arbeitsgruppe
5. http://www.validlab.com/goldberg/paper.pdf — David Goldberg: What Every Computer Scientist Should Know About Floating-Point Arithmetic — ACM Computing Surveys, 1991
6. http://www.cs.berkeley.edu/~wkahan/ieee754status/why-ieee.pdf — William Kahan: Why do we need a floating-point arithmetic standard? — Februar 1981
7. http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF — William Kahan: Lecture Notes on the Status of IEEE Standard 754 for Binary Floating-Point Arithmetic — Oktober 1997
8. http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html — An Interview with the Old Man of Floating-Point — Reminiscences elicited from William Kahan by Charles Severance, Februar 1998
9. http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf — William Kahan & Joseph D. Darcy: How Java's Floating-Point Hurts Everyone Everywhere — März 1998
10. http://perso.ens-lyon.fr/jean-michel.muller/Intro-to-TMD.htm — Vincent Lefèvre and Jean-Michel Muller’s work on the table-maker’s dilemma outlines the difficulties in specifying elementary functions.
11. http://www.cs.berkeley.edu/~dbindel/class/cs279/dsb-bib.pdf — annotated bibliography by David Bindel
12. http://babbage.cs.qc.edu/courses/cs341/IEEE-754references.html
13. http://www.math.utah.edu/~beebe/software/ieee/ — Nelson H.F. Beebe Test Software GNU GPL

Und, nebenbei gesagt, den Link Java-Applet zur Umrechnung zwischen Binär- und Dezimaldarstellung von IEEE 754-Fließkommazahlen, der jetzt im Artikel steht, finde ich ziemlich schwach ...

— Nol Aders 00:51, 6. Jun 2005 (CEST) — rev. — Nol Aders 02:39, 6. Jun 2005 (CEST)

Auch ganz nette Beschreibung in Fortran: #http://www.ibiblio.org/pub/languages/fortran/ch4-1.html

(nicht signierter Beitrag von 84.168.250.74 (Diskussion | Beiträge) )

Umbau

Ich habe den Artikel am Anfang ein wenig umgebaut und ergänzt.

Der erste Satz soll eine kurze Begriffserläuterung enthalten.

Unter Überblick findet sich eine kurze Erläuterung und vor allem eine Abgrenzung zu IEEE 854 und ein Hinweis auf die Weiterentwicklung IEEE 754r.

Unter Allgemeines steht jetzt eine grobe Angabe über das komplette Zahlenformat in IEEE 754 mit allen Varianten. Das kann dann weiter unten detailliert ausgeführt werden.

brf

Ich finde deine Änderungen sehr gut. Weiter so! :-) --Qbi 11:37, 5. Aug 2005 (CEST)

Ideen

Danke. Ich würde den alten Kommentar zur Geschichte ganz rausschmeissen (Ich habe ihn noch als Kommentar erhalten). Er sagt nichts aus, und das was er enthält betrifft nicht IEEE sondern *alle* Gleitkommazahlen.

Ausserdem würde ich die detaillierten Darstellungen komplett anders gliedern und kompakter darstellen. Aber ich will auch nicht die Arbeit meines Vorgängers einfach wegwerfen?

Noch was: in meiner Ausgabe von IEEE 754 kommt das Wort Charakteristik nicht vor. Es heisst dort ganz normal Exponent/signed exponent/unbiased exponent. Ich habe keine Ahnung, wer das Wort Charakteristik hier eingebracht hat. Darf ichs ändern?

Dafür heisst im Standard die Mantisse signifikand. Ich würde das deutsche Mantisse trotzdem lassen. Wenn signifikand, dann würde ich es nicht übersetzen (Signifikant ? )

Und wie erzeugt man einen Link auf eine .ps-Datei??

brf

Charakteristik?

Ich würde zu gern wissen, wo dieser eher nichtssagende oder zumindest verwirrende Begriff im Zusammenhang mit Fließkommazahlen herkommt. Im Englischen steht stets bei Erläuterungen des Formats stets nur "exponent" oder "biased exponent", und auch in der Originaldokumentation vom IEEE finde ich nirgends "characteristic". --RokerHRO 14:06, 10. Aug 2005 (CEST)

Charakteristik und Exponent

In dem Artikel werden oft Charakteristik und Exponent miteinander verwechselt, das muss dringend behoben werden. Die Grafik ist falsch, da muss tatsächlich Charakteristik statt Exponent in das mittlere Feld.

Die IEEE-Dokumentation spricht von "biased exponent", nicht von "characteristic". Ich kann das gerne im Deutschen mit "eingestellter" od. "angepasster Exponent" übersetzen, wenn das von der Mehrheit so gewünscht wird. Letzten Endes ist es der Exponent, der in dem Feld gespeichert ist. Er ist eben nur auf eine spezielle Art kodiert, nämlich plus einem Bias-Wert. --RokerHRO 19:58, 13. Aug 2005 (CEST)

Hey hier wird gerade über die "Charakteristik diskutiert. Ich (und nicht ich alleine) bin der Meinung, dass dieses Wort ganz raus gehört! Es taucht im Standard und in aller wichtigen Sekundärliteratur *Überhaupt nicht* auf. Dann finde ich es nicht gut, wenn dieses Wort vor Abschluss der Diskussion wieder eingearbeitet wird! Vielleicht beantwortet wer-immer-es-wieder-rein-hat die von Rokerhro gestellt Frage, woher das überhaupt kommt?

brf

In meiner Vorlesung zur Technischen Informatik heißt die Bitkette konsequent "Charakteristik" - sowohl im Skript als auch in der Vorlesung. Drinlassen!

Dann frage doch bitte mal deinen Dozenten, wo er diese Bezeichnung denn herhat, damit wir hier auch mal die Quelle für diesen Begriff angeben können. Und gewöhnte dir außerdem bitte an, deine Diskussionsbeiträge mit --~~~~ zu "unterschreiben", damit man weiß, wer hier mitdiskutiert. Danke. --RokerHRO 16:32, 13. Nov 2005 (CET)

Der vorletzte Beittrag stammt von mir, hab die Sig nur vergessen. Wenn man nach "Charakteristik Exponent" bei Google sucht, wird man schnell erkennen, dass recht viele Universitäten den Terminus Charakteristik für die 8-Bits der Exponentendarstellung verwenden - auch im Kontext von IEEE 754. Ich war der Meinung, dass David Glodberg in seinem inzwischen zum Standard gewordenen Paper "What Every Computer Scientist Should Know About Floating-Point Arithmetic" auch von Charakteristik spricht, das tut er aber nicht. Er nennt das Ding biased representation. Vielleicht kann jemand Licht in das Dunkel bringen, der den genauen historischen Hintergrund des Terminus' kennt. --D135-1r43 20:00, 14. Nov 2005 (CET)

In meiner TI-Vorlesung heißt das auch konsequent Charakteristik: Exponent=Charakteristik-(k-1)^2+1, wenn die Charakteristik k Bit lang ist und natürlich im Bitmuster steht, nicht der Exponent. Daher ist schonmal Exponent!=Charakteristik und somit ist auch die Bezeichnung in der ansonsten recht hübschen Grafik falsch. Da gehört auf jeden Fall "Charakteristik" rein statt "Exponent"! Als Quelle führe ich Skript und Foliensatz von Dr.-Ing Tamim Asfour, Universität Karlsruhe (TH) an (Vorlesung Prof. Hanebeck). Nach diesen Vorlesungsunterlagen ist der Artikel im Moment ganz einfach falsch! Die Unterscheidung mit klein e und groß E finde ich äußerst irreführend.--tm, 2007-06-18

So lange wir keine Quelle für die Herkunft des Begriffes "Charakteristik" haben, bin ich dafür, den Exponenten weiterhin Exponent zu nennen. Er ist eben nur speziell kodiert. (siehe auch: Exzesscode - bei IEEE wird eben ein "Excess-128"- bzw. "Excess-1024"-Code verwendet (IEEE single, IEEE double) ) --RokerHRO 21:10, 14. Nov 2005 (CET)

Hans-Jochen Schneider (Hrsg.): "Lexikon der Informatik und Datenverarbeitung", Oldenbourg, 3. Auflage 1991 schreibt unter dem Stichwort "Gleitkommadarstellung": "[...] negative Exponenten über eine Verschiebung des Nullpunkts um den halben Zahlenbereich (Charakteristik oder Bias) dargestellt." Als Verfasser des Artikels ist Prof. Dr. W. H. Burkhardt, Universität Stuttgart, angegeben. Auch im Vorlesungsskript von Prof. Haupt (RWTH Aachen) zur Vorlesung "Datenverarbeitung II" aus dem Jahr 1988 findet sich die Bezeichnung "Charakteristik" für Exponent + Verschiebung an mehreren Stellen. Es scheint also im vorigen Jahrhundert durchaus gängige deutsche Fachsprache gewesen zu sein. Ich findes es praktisch, in der Formel e=E-B zwei verschiedene Begriffe für e und E zu haben. --T.Nitz 19:50, 07. Jan 2006 (CET)

Überarbeiten

Ich habe diesen Artikel auf die Liste zum überarbeiten gesetzt. — Nol Aders 01:58, 10 November 2005 (CET)

Insbesondere überarbeitungsbedürftig finde ich die folgenden Aspekte (Zusammenfassung des diesbezüglichen Teils der obenstehenden Diskussion plus was mir noch ein- oder aufgefallen ist):

1. Der Begriff "Fließkommazahl" soll vermieden und konsequent durch "Gleitkommazahl" ersetzt werden.
2. Der Begriff "Charakteristik" soll vermieden und konsequent durch "Exponent" bzw. "biased exponent" bzw. ein deutsches Äquivalent für diesen Ausdruck ersetzt werden.
3. Der Artikel überlappt inhaltlich mit Gleitkommazahl (z.B. Normalisierung, Hidden Bit, &c.). Die beiden Artikel sollen aufeinander abgestimmt werden in folgendem Sinn: IEEE 754 ist ein Standard für binäre Gleitkommazahlen; hier alles beschreiben, was zu diesem Standard gehört, also Binäre Darstellung, Hidden Bit, &c. — Dort unter Gleitkommazahl nur den allgemeinen Fall abhandeln mit beliebiger Basis b, &c., aber alles über den Spezialfall b=2 und den Standard IEEE 754 rausnehmen.
4. So wie sie jetzt ist, ist die Gesamtstruktur unübersichtlich; diese sollten wir straffen. Z.B. gibt es Unterabschnitte zu den Themen "Unendlich", "NaN" und "Null" je an zwei Stellen, einmal unter "Darstellbare Werte", einmal hierarchisch auf derselben Stufe wie "Darstellbare Werte" als eigene Abschnitte. Das ist unnötig verwirrend.
5. Auswahl der Weblinks (siehe oben)
6. Zahlenbeispiele: das bestehende Beispiel ist sehr speziell und sehr einfach (nur wenige Nachkommastellen); wir sollten es ersetzen. Ein weiteres Beispiel sollte auf die tückische Tatsache hinweisen, dass insbesondere 0,1 und 0,2 (dezimal) als Binärbrüche periodisch und daher als IEEE 754-Zahl nicht exakt darstellbar sind.
7. Der Hinweis auf Fortran als "... Programmiersprache[n], die für numerische Berechnungen optimiert [ist]", ist fehl am Platz und gehört raus.

— Nol Aders 15:36, 10. Nov 2005 (CET)

Okay, da hast du viel vor dir. Sei mutig und fang an, ich helfe dir dann gerne. --RokerHRO 17:00, 10. Nov 2005 (CET)

Ich habe mal den Überblick/Allgemeines/Interpretation/Beispiel neu formuliert. Den Rest habe ich schon vor einem Vierteljahr überarbeitet. brf

1. Vieleicht sollte man die hier genau falsch herum verwendete Bedeutung von E und e aus der IEEE Definition übernehmen.

Charakteristik

Ich habe auch das Wort Charakteristik entfernt. Auch wenn es in deutschen Wörterbüchern vorkommt (ich habe die Kommentare der Techniker gelesen), taucht es in der englischen Literatur und natürlich im Standard nicht auf. Ich plädiere für die Originalbegriffe. Und um das zweite Unwort zu erwähnen: Intel (Palmer) verwendet für die Mantisse das Wort Signifikant. Ich würde in einem Lexikon bei der allgemein üblichen Mantisse bleiben.

brf

Auch bei uns an der Uni Münster ist das Wort Charakteristik durchaus gebräuchlich! Und das nicht nur bei einem Prof in einer Vorlesung, sondern auch bei mehreren Profs / Veranstaltungen. Ich finde die Unterscheidung, abgesehen davon obs nun irgendwie im englischem original vorkommt oder nicht (dann ist Charakteristik halt die Übersetzung ins Deutsche für biased exponent) sinnvoll und hilfreich! Ich hatte zunächste leichte Verständniss Probleme beim erarbeiten des IEEE 754, dachte vieleicht hilft mir Wikipedia. Nix da! War nur noch schlimmer. Der Artikel ist wirklich würdig überarbeitet zu werden! Ausserdem MUSS HIER UNBEDINGT erklärt werden wie sich das verf**** B in der Rechnung e = E - B zusammen setzt!!! Ich finde das gehört direkt in Allgemeines mit rein! Und zwar auf jeden Fall!!!! Ich hab den Artikel hier gelesen, (vorm Script ausser Vorlesung) und dachte nur "what the fuck ist dieses ominöse B???". Toll n Wert in der Tabelle, und wo zum Geier kommt der her?

Und was auf jeden Fall ABSOLUT FALSCH IST, ist folgender Satz: Exponent e (r Bit), manchmal als Charakteristik bezeichnet Der Exponent ist der Exponent oben an der 2, und die Charakteristik stellt die bei z.B. singel die 8 Bits dar. Also quasi den "biased exponent"! Das ist unbedingt zu unterscheiden.

Man könnte sagen dass sich e berechnen lässt als e = E - B wobei E den biased exponent bzw manchmal als Charakteristik bezeichnet darstellt, und B den Biaswert (Restwert) darstellt, welcher sich wie folgt berechnet: ... So ähnlich würd ich das mal für arg sinnvoll halten!

Da tritt die erste Verwechselung auf! Und hat bei mir reichlich für Verwirrung gesorgt. Artikel sollten doch wohl so formuliert sein, dass ein Nichtwissender das Wissen hier erlangt, und nicht, dass die Wissenden wissen was damit gemeint ist, oder nicht???

Also der Satz: Der Exponent e ergibt sich aus der in den Exponentenbits gespeicherten nichtnegativen Binärzahl E durch Subtraktion eines festen Biaswertes B: e = E − B. Ist einfach zu kurz / ungenau!!! Vor allem so fest ist der Wert mal gar nicht. Achja, Bias = 2^(r-1) -1 wobei r die Anzahl der Bits der Charakteristik bzw des "biased exponents" darstellt.

Hätte das hier drin gestanden, hätte mir das circa eine bis zwei Stunden Sucherei und Verwirrung erspart!

Achja, schluss endlich sollte vieleicht auch noch erwähnt werden, dass der Standard die nicht normalisierten Zahlen "anbietet" aber die Hersteller der Chips daran keineswegs gebunden sind, das das zu einem sehr viel höherem technischem Aufwand geführt hat... So als kleiner Erklärung warum es die Unterscheidung zwischen normalisiert und nicht normalisierten Zahlen gibt, und welchen Hintergrund das hat. Dunstkreis 01:25, 29. Apr 2006 (CEST)

Wenn im Absatz "Allgemeines" steht, dass man "e" (den Exponenten) nicht mit "E" (Charakteristik) verwechseln soll, dann müsste man doch in der Tabelle im Abschnitt "Interpretation des Zahlenformats" anstatt "Exponnent E", "Exponent e" verwenden. Oder sehe ich das falsch? --84.164.159.239 12:03, 17. Feb. 2011 (CET)

KLeiner Fehler

Es scheint einen kleinen Fehler zu geben. Im Abschnitt "Beispiel" in dem Kästchen in dem es um die Darstellung des Exponenten geht steht die Rechnung: ...1+1024 = 1024... ich nehme an es soll 1+1032=1024 heißen, aber da ich mir nicht ganz sicher bin soll das jemand machen, der sich damit auskennt.(nicht signierter Beitrag von unknown (Diskussion | Beiträge) 14:56, 25. Feb. 2010)

Ich denke dass sich noch ein Fehler eingeschlichen hat (Abschnitt: Zahlenformate und andere Festlegungen des IEEE 754-Standards in der Tabelle) - und bitte die Fachleute nochmal darüber nachzudenken - ich bin jedoch zu dem Schluss gekommen, dass die Wertebereiche für den Exponenten nicht von -126 bis 127 sondern von -127 bis 126 gehen sollten (für die anderen in der Tabelle gilt das Gleiche), wenn der Bias bei 127 liegt (die Umwandlung von Exponent in Charakteristik soll ja die negativste Zahl auf die null verschieben duch die Addition des Bias)(nicht signierter Beitrag von unknown (Diskussion | Beiträge) 14:56, 25. Feb. 2010)

---

Desweiteren ergibt die Division 1.0/0.0 nicht + Unendlich, sondern NaN)(nicht signierter Beitrag von unknown (Diskussion | Beiträge) 10:36, 03. Nov. 2010)

Nö. Kannst es gerne auf einer IEEE-754-konformen FPU deiner Wahl ausprobieren oder eben in den IEEE-Specs nachgucken. --RokerHRO 11:12, 3. Nov. 2010 (CET)

Noch einer? Da heisst es: Vorkommastellen: 10010 (2) = 18 (10)

18 dezimal entspricht binär 10010 ( 2 dezimal entspricht binär 10

da ist wohl etwas verdreht.

Kommentar zum Löschen

Ich habe diesen Satz gelöscht: "Vor allem für die Subtraktion ist das keine trivial erfüllbare Forderung (siehe Goldberg). Es kann nämlich bei der Subtraktion zweier fast gleich großer Gleitpunktzahlen zu dem so genannten Auslöschungseffekt kommen: Durch die Subtraktion selbst werden viele der höherwertigen Bits der Mantisse Null, sodass die verbleibenden (möglicherweise ausgesprochen ungenauen) niederwertigen Bits durch die Normalisierung nach links geschoben werden."

Die Forderung 2 Gleitkommazahlen exakt zu subtrahieren ist sicher leicht erfüllbar. Davon steht auch im Goldberg nichts. Das hat nichts mit dem Auslöschungseffekt zu tun --Mathemaduenn 15:48, 31. Aug 2006 (CEST)

Man kann mit Guardbits dieses Effekt einschränken, aber sehen wir mal den Fall, das wir zwei Zahlen subtrahieren und guardbits genutzt werden um die Auslöschung zu verhindern. Dann existieren im Ergebnis keine Guardbits mehr, da diese schon durch die höhere Genauigkeit realisiert wurden. Wenn diese beiden Ergebnisse mit den Aufgebrauchten Guardbits wieder nahe bei einander Liegen und subtrahiert werden, dann tritt die Auslöschung aufjeden fall ein. (Von der Umformung der Rechenschritte wird in diesem Beispiel abgesehen). MFG Micha

Wertebereich

Kann das stimmen mit dem Wertebereich (insbesondere des Doubles) ? Die maximale normalisierte Mantisse hat doch den Wert $1+(1-2^{-52})$ und der maximale biased Exponent ist 1023 (denn weiter oben steht, dass der Exponentenwert 1111....1 reserviert ist für Ausnahmen) - also beträgt der Maximalwert doch nicht 2^1024 sondern $(1+(1-2^{-52}))\cdot 2^{1023}\approx 8,9884656743105586663281989994968e+307$ ?

Korrekt. Die angegebenen Werte sind Näherungen. Die größte endliche in einem IEEE DOUBLE darstellbare Zahl ist

$\left(2-{\frac {1}{2^{52}}}\right)\cdot 2^{1023}$ =

179.769313.486231.570814.527423.731704.356798.070567.525844.996598.917476.803157.260780.028538.760589.558632.766878.171540.458953.514382.464234.321326.889464.182768.467546.703537.516986.049910.576551.282076.245490.090389.328944.075868.508455.133942.304583.236903.222948.165808.559332.123348.274797.826204.144723.168738.177180.919299.881250.404026.184124.858368

2¹⁰²⁴ dagegen ist:

179.769313.486231.590772.930519.078902.473361.797697.894230.657273.430081.157732.675805.500963.132708.477322.407536.021120.113879.871393.357658.789768.814416.622492.847430.639474.124377.767893.424865.485276.302219.601246.094119.453082.952085.005768.838150.682342.462881.473913.110540.827237.163350.510684.586298.239947.245938.479716.304835.356329.624224.137216

Der Unterschied ist gewaltig. :-) --RokerHRO 17:41, 12. Nov. 2006 (CET)

Abschnitte überarbeiten

Ich habe 2 Abschnitte erstmal auskommentiert, da sie IMHO so nicht im Artikel stehen bleiben sollten. Zum einen ist die Problematik, dass "einfache Dezimalbrüche" nicht exakt als IEEE-Zahl darstellbar sind, schon erwähnenswert und sollte mit einem einfachen Beispiel erläutert werden, aber bitte nicht so, wie es jetzt im ersten auskommentierten Abschnitt versucht worden ist.
Zweitens ist die Umwandlung von Pi in Dezimaldarstellung ins IEEE-Format doch ein bisschen zu ausführlich geraten, so dass man da auch kürzen kann, ohne dass der Artikel an Informationswert verliert. Was denkt ihr? --RokerHRO 22:26, 27. Nov. 2006 (CET)

epsilon

Hallo, falls mit Epsilon doch die Maschinengenauigkeit gemeint war so sollten die Konstanten geändert(sprich halbiert werden) Grüße --Mathemaduenn 13:41, 10. Mai 2007 (CEST)

Hi, der Einwand ist vollkommend korrekt: Im Artikel steht ja auch: "gemäß der Norm IEEE 754 werden nur die folgenden Ziffern gespeichert, die erste Ziffer ist eine implizite Ziffer oder ein implizites Bit (englisch „hidden bit“). Dadurch wird gewissermaßen 1 Bit Speicherplatz „gespart“." Daraus folgt, daß epsilon 2^-53 ist, nicht 2^-52. Gruß, MBS, 14.12.2007

Im Abschnitt "Zahlenformate und andere Festlegungen des IEEE-754-Standards" heißt es, dass $\epsilon$ den relativen Abstand zweier Gleitkommazahlen beschreibt. Das klingt so, als ob dieser Abstand konstant wäre. Das ist nicht der Fall. Der relative Abstand liegt zwischen der jeweils als $\epsilon$ angegebenen Zahl und der doppelt so großen. Besser wäre es, im Text vor der Tabelle festzustellen, dass der relative Abstand zweier Gleitpunktzahlen mindestens $\epsilon$ und höchstens 2*$\epsilon$ beträgt. Noch besser wäre es $\epsilon$ in der Tabelle zu verdoppeln. Dann entspricht diese Zahl dem Abstand zwischen der 1 und der nächstgrößeren Gleitpunktzahl, dh. derjenigen Zahl, die man zu 1 addieren muss, um nicht mehr das gerundete Resultat 1 zu erhalten. --Fritz Bierbaum (Diskussion) 19:19, 19. Aug. 2012 (CEST)

Geschichte etwas erweitern und Vergleich von Fließkommazahlen

Zur Geschichte sollte man Konrad Zuse nicht vergessen! Für die Gleitkommaarithmetik für Rechner hat er schließlich den Grundstein gelegt und dies auch Patentieren lassen. Die Geschichte sollte also nicht mit den 60igern Beginnen siehe ZUSE Z3.

Die Anordnung mit Vorzeichen – Exponent – Mantisse in genau dieser Reihenfolge bringt die dargestellten Gleitkommawerte in dieselbe Reihenfolge wie die durch dasselbe Bitmuster darstellbaren Signed-Integer-Werte. Damit können für die Vergleiche von Gleitkommazahlen dieselben Operationen wie für die Vergleiche von Signed-Integers verwendet werden. Kurz: die Gleitkommazahlen können lexikalisch sortiert werden.

Diese Aussage klappt nur bei float, da der Datentyp Int genau 32 BIT hat. Ok bei Double kann man noch den 64 Bit long long / __int64 Datentypen nehmen. Aber wie sieht es bei Extended aus? Oder eigenen Repräsentationen bei denen das MSB der Darstellung != der des ganzzahligen Datentypes.

Ich würde mal sagen, dass der Vergleich lediglich für positive Zahlen klappt wie erwartet. IEEE(-0) wäre als Integer aufgefasst der kleinstmögliche Integer (also $-2^{32}$) obwohl es eigentlich größer als jede andere negative Zahl ist. --134.102.204.124 16:44, 10. Dez. 2009 (CET)

Die Geschichte beginnt 1977, aber die Codenummer IEEE754 zeigt an, daß der Vorschlag der Erste im April/Monat 4 im Jahre 19-75 Eingereichte war. Weiß Jemand, was in der Zwischenzeit passiert ist. (nicht signierter Beitrag von 80.138.136.46 (Diskussion) 10:48, 14. Sep. 2020 (CEST))

Wertebereich: Untere Grenze

Lt. IEEE-754 ist die untere Grenze des Wertebereichs mit einem Sonderfall belegt: Die betragsmäßig kleinste mögliche Zahl ergibt sich wenn der Exponent gleich 0 ist (0000 0000), und die Mantisse ungleich Null. Dann ist die sich ergebende Zahl definiert über $(-1)^{S}\cdot 2^{-126}\cdot (0.m)$, d.h. es handelt sich um eine nicht-normalisierte Mantisse. Demzufolge ist die vom Betrag her kleinste Zahl 0|00000000|00000000000000000000001 ≈ 1.4E-45. Gleiches gilt natürlich auch für double und die extended Varianten.

Wenn der Exponent 0 ist, ist die SINGLE-Zahl stets $(-1)^{S}\cdot 2^{-126}\cdot (0.m)$, unabhängig von den Mantissenbits. Das sind dann die "denormalisierten" Zahlen einschließlich Null. Das steht im Artikel aber auch schon so drin. --RokerHRO 15:10, 2. Nov. 2007 (CET)

Im Artikel steht es richtig, in der Tabelle mit den Wertebereichen leider nicht. Ich habe mir heute die Mühe gemacht, die betragsmäßig kleinsten darstellbaren Zahlen neu und diesmal richtig zu berechnen, mit Berücksichtigung der nicht normalisierten Zahlen.

Ein Problem habe ich noch: In der vierten Zeile ist die kleinste Zahl $2^{-16445}$, leider habe ich noch keinen Rechner/Programm gefunden, das mir das in eine Dezimaldarstellung (vgl. die Spalten darüber) umrechnet. --Erlenmayr 01:05, 18. Jul. 2008 (CEST)

Mit (wx)maxima kann man das ausrechnen:

bfloat((2^-16445)*10^4951) ==> 3.645199531882475b0

Gegenprobe:

bfloat(3.6451995318825*(10^-4951 / (2^-16445))) ===> 1.000000000000007b0 (Ich musste da die Potenzen klammern, die so symbolisch ausgerechnet werden können, da es andernfalls einen Gleitkommaunterlauf gab)

Das Ergebnis ist also: $2^{-16445}\approx 3{,}6451995318825\cdot 10^{-4951}$.

Ich hoffe, ich hab mich da nirgendwo verrechnet. --RokerHRO 10:15, 18. Jul. 2008 (CEST)

Umwandlung reelle Zahl in IEEE 754

Da steht bei Punkt 3 Normalisieren: 10010,011011011... * 10^0 = 1,0010011001100... * 10^4

Müsste das nicht 10010,011011011... * 2^0 = 1,0010011001100... * 2^4 heißen, weil wir ja schon im Dualraum (also Basis 2) unterwegs sind? Bitte das mal checken, ich bin leider kein Experte. Vielleicht liege ich einfach einem Denkfehler auf? --GangMan 20:02, 11. Nov. 2007 (CET)

Exzess

 1. Berechnung des Exzesses

Das Wort Exzess taucht zum ersten Mal auf als er in dem Beispiel berechnet wird. Was genau ist er denn? --Lerad 20:53, 17. Nov. 2007 (CET)

Zahlenformate und andere Festlegungen des IEEE 754-Standards

Für die angegebenen Formate ergibt sich die folgende Beschränkung des jeweiligen Zahlenbereichs für normalisierte Zahlen. Ist falsch. Die kleinste Zahl ist denormalisiert angegeben. --Trac3R 21:11, 23. Okt. 2008 (CEST)

Abschnitt Denormalisierte Zahlen

Aus Sicht eines Audio/DSP-Programmieres finde ich den Abschnitt unausreichend. Da die deutsche Wikipedia dafür noch keinen eigenständigen Artikel hat, sollten ähnliche Informationen wie in der englischen enthalten sein. Es sollte der Faktor erwähnt werden um wieviel langsamer Prozessoren denormalsierte Zahlen berechnet (je nach Model 40-100 mal langsamer). Außerdem wäre eine dezimale Angabe des Schwellenwertes für denormalisierte Zahlen (bei single zb. 1e-18) sinnvoll neber der Angabe des Schwellenwert als Inverse der Binärzahl. Da im letzten Abschnitt erwähnt wird, wie man damit umgehen kann, sollte man zumindest ein paar Methoden anreißen, die nicht nur auf Maschinencode möglich sind: Skalierungen, Auf Null reduzieren, sehr kleines Rauschen, Niquist-Frequenz als Störsignal, DC-Offsets etc. Es wäre auch wünschenswert, wenn man der Begriff Perfomanz in dem Abschnitt erwähnt wäre, weil diese schöner bei den Suchmaschinen gefunden wird. Man würde ja eher diesen Begriff benutzen als Verlangsamung der Ausführung. (nicht signierter Beitrag von 78.52.22.205 (Diskussion) 18:48, 18. Aug. 2013 (CEST))

Verteilung der Zahlenwerte

Wenn ich das richtig sehe, enthält jedes Intervall [2^n, 2^(n+1)[ eine konstante Anzahl Werte (z.B. 2^52 bei Double). Wie nennt man so eine Verteilung? (nicht signierter Beitrag von 188.98.66.139 (Diskussion) 01:57, 31. Mär. 2014 (CEST))

"log-uniform" --Rainald62 (Diskussion) 15:49, 10. Nov. 2016 (CET)

Weblink

Der 2. Weblink zu http://www.h-schmidt.net/FloatApplet/IEEE754de.html führt auf eine Webseite mit eingebundenem Java APplet, welches aus Sicherheitsgründen aktuell in den browsern i.d.R. nicht funktioniert. Vom selben Autor gibtes eine Englische Seite mit einem JavaScript basierten Umrechner der weiterhin funktioniert: http://www.h-schmidt.net/FloatConverter/IEEE754.html. Ich wäre für einen Ersatz des Weblinks durch die andere Fassung. --91.103.115.13 08:40, 15. Sep. 2016 (CEST)