Hallo, ich schreibe morgen eine Klausur in Informatik 2. In diversen alten Klausuren ist gefragt warum es zu Rundungsfehlern bei der FPU kommt? Das einzige was ich bisher herausgefunden hab, ist das bei Operationen Zwischenergebnisse größer sein können als wie sie abgespeichert werden könne und dadurch Ungenauigkeiten entstehen. Doch ist das der Hauptgrund?
Das Hauptprobem ist eher, dass Fliesskommazahlen, wie sie die FPU verarbeitet, nicht für genaue Berechnungen gedacht/ausgelegt sind. Andersherum ausgedrückt: Sinn der FPU ist es nicht, exakte Werte zu berechnen, sondern eine Annäherung an das richtige Ergebnis zu liefern. Es ist also eher ein Sonderfall, wenn kein Rundungsfehler auftritt. =>http://de.wikipedia.org/wiki/Gleitkommazahl
@Oliver: Nein. Rechne dezimal 1 dividiert duch 3 mit Darstellung des Ergebnisses in endlicher Stellenzahl. Hoffentlich fällt jetzt der Groschen.
Oder mathematisch ausgedrückt: Die Gleitkommazahlen, mit denen die FPU arbeitet, sind eine endliche Teilmenge der Reellen Zahlen, und bilden keinen Körper. Beweis durch Gegenbeispiel: Das multiplikativ Inverse von 3 ist nicht als Gleitkommazahl darstellbar.
Oder ganz einfach die Addition von Werten mit sehr unterschiedlicher Größenordnung. Wenn die Mantissengenauigkeit nicht ausrecht, dann fällt der kleine Operand einfach unter den Tisch.
Rechne mal mit Excel 0.05+(-0.07)+0.02+0 Also schreibe untereinander 0,05 -0,07 0,02 0 Dann Addieren OpenOffice.org rechnet übrigens richtig.
Nicht ganz. Bei Openoffice basiert die Rechnerei auf Java und ist schnarchlangsam. Ein Bekannter von mir hat ein paar komplexere Berechnungen in einer Excel-Tabelle gemacht. Excel war nach ein paar Sekunden fertig, OO hat er nach 30min abgeschossen.
Da wäre die Quintessenz also nun langsam und richtig <=> schnell und falsch ?
Gast wrote: > Rechne mal mit Excel > > 0.05+(-0.07)+0.02+0 > > Also schreibe untereinander > > 0,05 > -0,07 > 0,02 > 0 > > Dann Addieren > > > OpenOffice.org rechnet übrigens richtig. Solche Effekte bekommt man, wenn man binär rechnet: Dann gehts sauschnell, aber es führt zu solchen Effekten. Wenn man stattddessen mit BCD-Darstellung rechnet, dann fallen die Rundungsfehler bei der Wandlung dezimal -> binär -> dezimal weg. Der Preis ist, daß es länger dauert.
Die X87 FPU hat intern mit 80 Bit gerechnet, wenn (Zwischen)Ergebnisse im RAM gespeichert werden müssen werden diesen auf 64 Bit gekürzt. Besonders eklig wenn durch leichte Änderungen im Code der Compiler anders optimiert und dadurch Zwischenergenisse im RAM gespeichert werden müssen, welche vorher in den internen Stack passten.
Blödsinn. OOo rechnet nicht mit Java. Es rechnet halt nicht mit Fließkommazahlen, was bei einer Tabellenkalkulation ja auch sinnvoll ist, auch wenns langsamer ist.
die Frage ist ob das mit dem Excel wirklich ein Problem ist, denn die abweichung von 1*10^-18 wird bei der ausgabe immer auf 0 gerundet. Und das bei viele werten wirklich mal eine Differenz rauskommt wo ist nicht egal ist dürfte an der Grenze von 65.000 Zeilen scheitern. Aber wenn OO mit java rechnet mit dort nicht mit Flieskommazahlen gearbeitet wird wie stellt dann java 1/3 dar? Nimmt es sich dann den ganzen arbeitspeicher und merkt dann das es nicht geht? Ich genke die rechnen intern auch mit Double aber runden das Ergebniss damit dieser Fehler nicht sichtbar wird.
Dezimal und binär wird mit Fest- oder Fliesskommarechnung aus 1/3 nie was, und eine korrekte Darstellung vom Ergebnis gibt es auch nicht. Allerdings können abhängig von der Art der Rechnung, also ob dezimal ober binär, unterschiedliche Rundungseffekte auftreten, die bei kaufmännischer Rechnung eine Rolle spielen. Denn so wie 1/3 dezimal nicht endlich darstellbar ist, ist 1/10 binär nicht endlich darstellbar.
Der Effekt, den Gast hier Beitrag "Re: FPU ungenau - warum?" vorgeführt hat, hat mit der 1/3-Problematik nichts zu tun. Das 1/3-Problem kann man mit Rational-Arithmetik in den Griff bekommen. Wenn aber reelle Zahlen ins Spiel kommen, dann bleibt nur symbolische Algebra und anschließend mit möglichst kleinen Fehlern zu wandeln. Die gesamte Fehlerproblematik spielt aber in dem Gebiet, in dem Excel hauptsächlich eingesetzt wird, keine Rolle. Die Kaufleute runden eh immer auf 2, 3 Nachkommastellen und dort verschwinden die Fehler dann freundlicherweise...
Also wenn bei einer Addition von Zahlen mit nur 2 Nachkommastellen schon Rundungsfehler auftreten, ist das für eine Tabellenkalkulation absolut inakzeptabel. Wie auch immer das Problem zu lösen ist, es muss zu lösen sein und wenn das bei einer Tabellenkalkulation nicht standardmäßig geht, ist die Tabellenkalkulation unbrauchbar. Mein Taschenrechner rechnet auch richtig.
Dein Taschenrechner rundet einfach, oder rechnet in BCD. Intern haben die einfachen Dinger auch mehr Stellen als auf dem Display erscheinen, eben um Rechenfehler ausgleichen zu können. Sag einfach er soll das Ergebnis auf 10 Stellen genau angeben, angefangen vor'm Komma. Wegen 10^-18 rumzudiskutieren ist Blödsinn.
Oliver Noll wrote: > Hallo, ich schreibe morgen eine Klausur in Informatik 2. In diversen > alten Klausuren ist gefragt warum es zu Rundungsfehlern bei der FPU > kommt? Da der Exponent und die Mantnisse nur in einer begrenzten Genauigkeit gespeichert werden kann der darstellbare Zahlenbereich nicht beliebig fein aufgeloest werden, alleine daher kommt es zu Darstellungsfehlern. In anderen Faellen ist die B-adische Entwicklung einer eigentlich geraden Zahl im Zielsystem aber periodisch -- und lauter solche Scherze ;) Es gibt bei diesen Zahlensystemen auch so etwas wie einen minimalen Abstand zwischen zwei darstellbaren Zahlen. Hast das in der Vorlesung nicht durchgenommen? Unwahrscheinlich sonst wuerde sowas doch nicht gefragt?
Gast wrote: > Also wenn bei einer Addition von Zahlen mit nur 2 Nachkommastellen schon > Rundungsfehler auftreten, ist das für eine Tabellenkalkulation absolut > inakzeptabel. Aua, aua... Der Fehler ist 10^-18 -- die 2. Nachkommastelle ist 10^-2, es ist also noch massenhaft 'Luft' da, den Fehler durch eine simple Rundungsoperation zu beseitigen. Das macht man üblichereise dadurch, daß man bei Excel das Zahlformat auf 2, oder wieviel auch immer im Rahmen der Möglichkeiten, Nachkommastellen einstellt und der Käs ist gegessen... Völlig inakzeptabel ist allerdings, wenn ein nicht-BWLer das nicht begreift. (Einem BWLer ist das sowieso wurscht.)
> Völlig inakzeptabel ist allerdings, wenn ein nicht-BWLer das nicht > begreift. (Einem BWLer ist das sowieso wurscht.) Ein BWLer muss nicht wissen, was Fließkommazahlen sind, der Anwender einer Tabellenkalkulation muss das auch nicht wissen. Die Tabellenkalkulation muss richtig rechen, darauf muss man sich verlassen können. Dem Anwender muss es egal sein, wie die Software intern die Zahlen darstellt und wie die Software gewisse Probleme umschifft. Es ist beängstigend, wie Microsofthörig viele schon sind und welches niedrige Qualitätsbewußtsein viele haben. Würde eine andere Tabellenkalkulation diese gravierende Fehler haben, würde alle wieder losschreien. Das angegebene Beispiel von Zahlen in diesem Wertebereich ist nun wirklich nicht realitätsfremd. Solche Konstellationen kommen in der Praxis oft vor. Da ist es dann schon wichtig, dass das Ergebnis stimmt. Das Beispiel mit anderen Programmen und mit dem Taschenrechner zeigt, dass es besser geht. Wie andere Programme und der Taschenrechner das intern rechnet, muss dem Anwender egal sein. Klar ist auch die Genauigkeit des Taschenrechners begrenzt und Rundungsfehler treten auch da auf, aber nicht bei solch einfachen Aufgaben mit so wenigen Nachkommastellen. > Aua, aua... Der Fehler ist 10^-18 -- die 2. Nachkommastelle ist 10^-2, Ich rechne im Dezimalsystem und da sind es in diesem Beispiel 2 Nachkommastellen. Die interne Rechnung interessiert nicht.
>Es ist beängstigend, wie Microsofthörig viele schon sind und welches >niedrige Qualitätsbewußtsein viele haben. Würde eine andere >Tabellenkalkulation diese gravierende Fehler haben, würde alle wieder >losschreien. Ich hätte das eher genau andersrum gesagt! Einem OpenSource System wie Linux gesteht man eher mal einen Fehler zu, das geht im Microsoft-Hass-Rausch vollkommen unter. >Das Beispiel mit anderen Programmen und mit dem Taschenrechner zeigt, dass >es besser geht. Bloß weil der Taschenrechner schon automatisch rundet wird der Fehler nicht besser.
> Ich rechne im Dezimalsystem und da sind es in diesem Beispiel 2 > Nachkommastellen. Die interne Rechnung interessiert nicht. Rechnen im Dezimalsystem oder mit Dezimalbrüchen ist auch kein Allheilmittel. Spätestens bei Quadratwurzeln wird's immer ungenau, da müsste man schon symbolisch rechnen (Maple, Mathematica). Eine Abweichung um 10^-18 ist in der Praxis fast nie ein Thema. Man sollte aber als Computernutzer dennoch aufpassen, insbesondere bei einer Abfrage auf Null der Form if (x==0)... Wenn hier x eine Gleitkommavariable ist, spielt der Unterschied zwischen 0 und 10^-18 sehr wohl eine Rolle. Gruss Mike
Wobei ich jetzt Linux nicht als Tabellenkalkulation bezeichne. Das sollte nur als ein Beispiel aus dem Open Source Lager herhalten, das auch nie vollkommen fehlerfrei ist. Es ist klar, dass vollkommene Fehlerfreiheit mit endlichen Mitteln praktisch nicht realisierbar ist, trotzdem finde ich, dass Microsoft in der öffemtlichen Wahrnehmung diesem Anspruch trotzdem genügen muss. Bei Open Source ist das häufig anders.
> Rechnen im Dezimalsystem oder mit Dezimalbrüchen ist auch kein > Allheilmittel. Spätestens bei Quadratwurzeln wird's immer ungenau Ja natürlich kann man immer irgendwelche Fälle herbeireden. Gleich kommt jetzt noch einer mit Winkelfunktionen. Wenn aber bei einer Tabellenkalkulation eine einfache Addition mit wenigen Nachkommastellen zum Problem wird, dann ist die zugehörige Software unbrauchbar. Da gibt es überhaupt keine Entschuldigung! Da hat der Programmierer versagt. Der Programmierer müßte nämlich wissen, was Fließkommadarstellung ist.
Hier war doch nicht die Rede von Taschenrechnern, hallo? Die rechnen nochmal wesentlich ungenauer und auch nicht nach IEE754. Hier nachlesen: http://de.wikipedia.org/wiki/IEEE_754 Und so nen Kaese mit der Tabellenkalkulation ist auch Dummfug. "Korrekt" heisst hier eben nicht "exakt". Wer den Unterschied nicht versteht ist schlicht und ergreifend als Anwender unfaehig.
@mike >if (x==0)... >Wenn hier x eine Gleitkommavariable ist, spielt der Unterschied zwischen >0 und 10^-18 sehr wohl eine Rolle. Richtig wäre sowieso if (x<epsilon)...
@Gast Nochmal zum mitmeißeln: Alle rechnen falsch. Egal ob Taschenrechner, Tabellenkalkulation oder FPU. Die Frage ist nur, ob sie dir den Fehler auch anzeigen oder die Ausgabe schönen. (a-b)^2 ist bekanntlich a^2-2ab+b^2. Nun setze mal Werte wie 1'000'001 und 1'000'000 ein, früher oder später kommt bei a^2-2ab+b^2 das falsche Ergebnis raus.
x==0 ist problematisch, x<epsilon ist falsch (wenn schon bitte fabs(x)<espilon, ist aber genauso falsch). Epsilon bezieht sich auf die relative Genauigkeit. Bei 1-1 passt das, bei 1e-90 - 1e-90 passt es dagegen nicht mehr, da müsste man auf fabs(x)<epsilon*1e-90 testen.
Gero A. wrote: > Und dass das Ergebnis eines Vergleichs den Wert "problematisch" haben > kann, ist mir auch neu. Doch, das geht, gewissermassen ;-). Heisst allerdings offiziell "unordered".
> Alle rechnen falsch. Egal ob Taschenrechner, > Tabellenkalkulation oder FPU. Die Frage ist nur, ob sie dir den Fehler > auch anzeigen oder die Ausgabe schönen. Entscheident ist doch das, was als Ergebnis rauskommt!!!! Wer es als Programmierer einer Tabellenkalkulation nicht schafft, das Ergebnis einer einfachen Addition richtig auszugeben, ist ein Versager. Ob er das dadurch schafft, dass er intern mit 1000facher Genauigkeit rechnet, oder indem er gar keine Fließkommaarithmetik verwendet (das ist wohl am sinnvollsten) oder ob er geschickt rundet sodass der Fehler im Endergebnis nicht auffällt, das ist doch für den Anwender sowas von schnurz piep egal! Dass es besser geht als es Excel macht, sieht man ja. Dass in speziellen Fällen, die von den Trollen hier angeführt wurden, trotzdem Rundungsfehler entstehen, ist zwar nicht schön, ist aber besser als der Murks von Excel.
Umgekehrt: Der Anwender, der nicht sieht, dass 1e-18 praktisch 0 ist, ist zu doof um mit einer Tabellenkalkulation zu arbeiten. @gero x<epsilon ist grundsätzlich falsch. Du hast nämlich nicht verstanden woher das epsilon überhaupt kommt, bitte informier dich mal ein bisschen über Numerik, und wenn du damit fertig bist überlegst du mal, ob das epsilon von der Mantisse oder dem Exponenten abhängt. Deine Reaktion auf "problematisch" zeigt aber, dass du sowieso keine Argumente hast.
Da der Beitrag grad verschwunden ist nochmal allgemein zur Klarstellung: http://de.wikipedia.org/wiki/Fehlerschranke > Eine Fehlerschranke wird mit dem griechischen Buchstaben ε (Epsilon) > angegeben und definiert eine vereinbarte oder garantierte, zugelassene > äußerste Abweichung von einem Sollwert. Ich ging davon aus, dass dieses Epsilon gemeint ist, damit lässt sich der Vergleich auf 0 präziser gestalten (x<epsilon ist trotzdem falsch). Ganz allgemein epsilon>0 reicht für den Vergleich auf 0 nämlich nicht aus.
Das mit der Fehlerschranke bringt Dir nur auch nicht recht viel... naja man sollte, wenn moeglich, Gleitkommazahlen sowieso vermeiden ;) Und in den meisten Faellen kann man das auch.
Vorsicht, du bist hier in einem PC Unterforum ;). Gleitkomma ist gut und bringt viel, wenn man damit umgehen kann. Auch auf einem Mikrokontroller. Die wichtigste Neuerung der letzten Jahre im Bereich PC CPUs war, dass sich ein SIMD Standard für Gleitkommaberechnungen durchgesetzt hat (SSE/SSE2). Dadurch ist die Rechenleistung auch in vielen praktischen Bereichen um Faktor 2 gestiegen.
I_ H. wrote: > Vorsicht, du bist hier in einem PC Unterforum ;). Gleitkomma ist gut und > bringt viel, wenn man damit umgehen kann. Auch auf einem > Mikrokontroller. Das ist mir durchaus bewusst.
> Umgekehrt: Der Anwender, der nicht sieht, dass 1e-18 praktisch 0 ist, > ist zu doof um mit einer Tabellenkalkulation zu arbeiten. Nein du Troll. Dem Anwender hat es nicht zu interessieren, wie die Zahlen intern dargestellt werden. Wenn bei solchen Rechenaufgaben Rundungsfehler bei der Ausgabe des Ergebnisses entstehen, so ist die interne Genauigkeit zu gering, oder man sollte bei bestimmten Aufgabenstellungen ganz auf Floatingpoint verzichten. Mit anderen Worten: Der Programmierer ist eine Niete. Bei anderen Anwendungen ist eine geringe Ungenauigkeit akzeptabel (z.B. Simulation von physikalischen Vorgängen), aber nicht wenn ich beispielsweise die Preise einiger Posten in einer Tabelle addiere, was eine häufige Anwendung für eine Tabellenkalkulation ist, und hinterher ein Rundungsfehler auftritt. Die Trolle hier sollten mal in die Grundschule gehen und das "Plusrechnen" lernen. Dort gibt es bei der Addition keine Rundungsfehler, auch nicht bei "Kommazahlen". Wer als Programmierer einfach überall unüberlegt die standardmäßig vorgefertigten Floatingpoint-Libs verwendet, ist ein Nichtskönner.
Ich möchte wirklich nicht in der Haut eines Programmierers für Tabellenkalkulationsprogramme stecken. Wie er es auch anstellt, er macht es immer komplett falsch: - Verwendet er die FPU für Berechnungen, kommen die Kaufleute und Bänker und schreien: "Igitt, da kommt jar gar nicht 0 heraus." Und im konkreten Fall: "Was bedeutet überhaupt dieses 'E' mitten in der Zahl? Sind das die Euros? Und das '-' nach dem 'E'? Hat da das Programm etwa gar nicht zu Ende gerechnet?" - Lässt er alles in BCD rechnen, kommen die Wissenschaftler und Techniker und jammern: "Bäh, das Programm ist ja a****lahm. Mein PC hat doch eine FPU, warum wird die nicht genutzt?" Und spätestens bei der ersten Division oder längeren Multiplikation in Verbindung mit Additionen und Subtraktionen beginnt auch das Gezeter der Kaufleute und Bänker aufs Neue. - Benutzt er rationale Arithmetik mit automatisch angepasster Genauigkeit, sind die Kaufleute und Bänker erst einmal ruhig, die Wissenschaftler und Techniker schmeißen das Programm jetzt aber endgültig weg. - Implementiert der Programmierer hingegen alle drei Varianten und überlässt die Auswahl dem Benutzer, ist die Verwirrung zu 100% perfekt (sofern überhaupt jemand den Menüpunkt zur Umschaltung des Zahlenformats findet). Und alle, die Kaufleute, Bänker, Wissenschaftler und Techniker beklagen sich zudem, dass die neue Programmversion schon wieder mehr Speicher frisst. Das mit dem Umschalten von Formaten klappt ja jetzt schon nicht, zumindest, was die Ausgabeformate betrifft: Würden die Kaufleute und Bänker für diejenigen Felder, die mit Geld zu tun haben, das Format "Währung" und für die Zinssätze das Format "Prozent" wählen, die beide defaultmäßig auf 2 Nachkommastellen runden, wäre der ganze Spuk vorbei und jeder glücklich.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.