Excel rechnet falsch bei Subtraktion von 0
Reiner Wolff
Null minus Null ist gleich?
Ich hatte in meinem jugendlichen Leichtsinn gedacht, die Antwort habe ich
in der Grundschule gelernt.
Gut auch Excel kommt bei der Formel
=0-0
zum richtigen Ergebnis.
Rechne ich
=2743-2078,08-664,92
kommt ebenfalls richtiger Weise 0 heraus.
Rechne ich aber
=2743-2078,08-664,92-0
kommt Excel auf
1,13687E-13
Warum ist das so?
Und viel wichtiger:
Wie kriege ich das weg?
=2743-2078,08-(664,92+0)
rechnet zwar richtig, aber ich wei� dann ja vorher nicht, wo ich wann
Klammern setzen muss, da die Zahlen typischer Weise aus anderen Zellen
stammen. Dort sind die Zahlen allerdings direkt eingetragen. Es gibt
nirgendwo dabei Punktrechnung. Zudem handelt es sich dabei um ein Problem,
dass sich hier unter WinXP und Win7 64 bit sowie Excel2000, 2007 und 2010
nachvollziehen l�sst.
Vielen Dank f�r die Unterst�tzung
und Gru� aus Kiel
Reiner
Werner P. Schulz
> Moin,
>
> Null minus Null ist gleich?
>
rechnet.
Google bitte nach "Excel rechnet falsch" und du wirst von der Fï¿œlle der
Antworten erschlagen.
--
Gruss Werner
mail nur an => nospam0601 at wp-schulz.de
"Persoenliche Knoppix-Rettungs-CD erstellen (Knoppix remaster)"
http://www.wp-schulz.de/rettung.html
Reiner Wolff
> Am 2010-10-20 schrieb Reiner Wolff:
>> Null minus Null ist gleich?
> rechnet.
Vielen Dank f�r's mitz�hlen.
> Google bitte nach "Excel rechnet falsch" und du wirst von der F�lle der
> Antworten erschlagen.
Vielen Dank f�r den Hinweis.
Ich bin allerdings kein Neuling und habe selbstverst�ndlich eine
Internet-Recherche durchgef�hrt.
Vielleicht ist es genau das Problem, dass man von den Suchergebnissen
_erschlagen_ wird. Es gibt zu viele Rechenfehlerm�glichkeiten. Ich bin bei
der Recherche zwar auch �ber exakt meinen Fehler gestolpert, konnte dabei
allerdings keine konkrete Begr�ndung finden, warum sich das richtige
Ergebnis in ein falsches Ergebnis �ndert, wenn man 0 subtrahiert.
Wenn es Dir allerdings so klar ist, w�re es nett, wenn Du mir das kurz
erkl�rst oder einen Link auf den entsprechenden - sicherlich existierenden
- KB-Artikel gibst.
Wenn Du lediglich einen kurzen Blick geworfen hast und bei Dir dachtest,
diese Frage gibt es doch bestimmt schon h�ufig , ohne von der Materie
Ahnung zu haben, w�re es mir lieber gewesen, wenn Du nicht geantwortet
h�ttest.
Merke Dir bitte meinen Namen und erspare Dir und mir Neuling-Hinweise in
dieser Form. Zumindest ich habe diesen nicht sonderlich h�flich
aufgenommen.
Gru� aus Kiel
Reiner
--
Treffen sich ein Kuhfladen und ein MS-DOS. Sagt das MS-DOS:
"Hallo, ich bin ein Betriebssystem, was bist'n du?".
Darauf der Kuhfladen:
"Wenn du'n Betriebssystem bist, bin ich 'ne Pizza!"
Joachim Eger
> Moin,
>
> Null minus Null ist gleich?
>
formatiere die Zelle mit 0,00
vielleicht klappts.
Joachim
Werner P. Schulz
>
> erklï¿œrst oder einen Link auf den entsprechenden - sicherlich existierenden
> - KB-Artikel gibst.
>
... schon der *erste* Treffer von Google brachte den entsprechenden Link zu
http://support.microsoft.com/default.aspx?scid=kb;de;78113
Ansonsten, mit deiner patzigen Antwort machst du dir hier keine Freunde.
Reiner Wolff
> Am 20.10.2010 16:52, schrieb Reiner Wolff:
>> Null minus Null ist gleich?
> vielleicht klappts.
Danke f�r den Tipp.
Dadurch war das Problem eigentlich erst aufgefallen.
Das Format der Zelle sah in etwa so aus:
+#.##0,00;-#.##0,00;0,00
Dabei war auff�llig, dass manche Nullen positiver waren als andere ...
Das bek�me man zwar �ber den Schalter 'Genauigkeit wie angezeigt' in den
Optionen geregelt, muss sich allerdings auch der Konsequenzen dieser
Einstellung bewusst sein.
Die andere M�glichkeit ist die Runden-Funktion (auch ein Dank an Martin f�r
den Hinweis), die ich bei der Strichrechnung mit bis zu maximal zwei
Nachkommastellen nicht unbedingt einsetzen m�chte.
Aber ich sehe das Problem als erkl�rt an, siehe Antwort an Werner.
Gru� aus Kiel
Reiner
--
In der Welt der EDV enden Pannen nicht, sondern gehen ineinander �ber.
Reiner Wolff
> Am 2010-10-20 schrieb Reiner Wolff:
>
>> erkl�rst oder einen Link auf den entsprechenden - sicherlich existierenden
>> - KB-Artikel gibst.
> ... schon der *erste* Treffer von Google brachte den entsprechenden Link zu
> http://support.microsoft.com/default.aspx?scid=kb;de;78113
Vielen Dank f�r den Verweis auf den KB-Artikel. Der hilft mir weiter.
Manchmal verwirft man gefundene Beitr�ge offensichtlich zu fr�h.
Dass reelle Zahlen im Bin�rsystem nicht immer abgebildet werden k�nnen war
mir bereits bekannt. Die Lekt�re hat mir allerdings noch die neue
Erkenntnis dazu gebracht, dass auch die 0 im benutzten System zu Gunsten
einer h�heren Genauigkeit nicht mehr "richtig" dargestellt werden kann,
sondern eine Sondervereinbarung darstellt.
Der Artikel erkl�rt im Bereich 'Repeating Binary Numbers and Calculations
with Results Close to Zero' warum meine erste Berechnung zum richtigen
Ergebnis von Null kommt:
Excel korrigiert den Umwandlungsfehler von Dezimal- zu Bin�rsystem und
zur�ck seit Excel97 automatisch, so dass der Benutzer ihn nicht mehr
bemerkt.
Warum diese Korrektur nicht funktioniert, wenn man vom Ergebnis nochmal 0
abzieht (oder hinzurechnet) bleibt allerdings offen.
Letztlich hei�t dies doch nur, dass man sich auch 13 Jahre nachdem der
Fehler im Grunde f�r den Benutzer bereits ausgemerzt wurde, immer noch
rum�rgern kann, wenn eine der Zellen keinen Inhalt hat. Schade eigentlich.
> Ansonsten, mit deiner patzigen Antwort machst du dir hier keine Freunde.
Zum einen sollte meine Antwort lediglich den Ton Deiner Antwort
wiederspiegeln. Dies ist mir offensichtlich gegl�ckt.
Und ansonsten hatte ich in der Charta dieser NG gar nichts davon gesehen,
dass es sich hier um ein Kontaktforum handelt, ich dachte es geht um Excel
;-)
Gru� aus Kiel
Reiner
Bernhard Sander
> Warum diese Korrektur nicht funktioniert, wenn man vom Ergebnis nochmal 0
> abzieht (oder hinzurechnet) bleibt allerdings offen.
> Letztlich heißt dies doch nur, dass man sich auch 13 Jahre nachdem der
> Fehler im Grunde für den Benutzer bereits ausgemerzt wurde, immer noch
> rumärgern kann, wenn eine der Zellen keinen Inhalt hat. Schade eigentlich.
Erster Ansatz für die Erläuterung: diese "Korrektur" ist reine Augenwischerei
und mathematisch nicht begründbar. Im Gegenteil, mathematisch gesehen wird zu
dem vorhandenen Fehler ein weiterer Fehler hinzugefügt.
Einige wichtige Rechnenregeln, die man in der Schule eingepaukt bekommen hat,
gelten am Computer nicht. Am Computer kann die Reihenfolge der Ausführung von
z.B. mehreren Additionen sehr wohl Auswirkung auf das Ergebnis haben. Kurz
gesagt: Distributivgesetz, Kommutativgesetz und Assoziativgesetz gelten am
Computer nicht. Dazu habe ich bei Excel leider noch nie einen Hinweis in den
Benutzerunterlagen gesehen.
Auch die Abhilfe "Runden" ist im Grunde eine gewagte Sache. Denn wenn z.B. 0,10
als Ergebnis des Rundens herauskommt, kann diese Zahl binär nicht korrekt
gespeichert werden. Im Speicher führt Excel dann eine andere Zahl als am
Bildschirm angezeigt wird!
Die wichtigsten Zahlen, die ein Computer genau speichern kann, sind Ganzzahlen.
Man behilft sich in Datenbanksystemen bisweilen damit, dass man z.B. Geldbeträge
als Ganzzahlen speichert indem man sie mit 100 oder oft auch mit 10000
multipliziert und so der Problematik der unendlichen Binärzahlen als Umsetzung
von endlichen Dezimalzahlen (für die Cent-Beträge) ausweicht.
Zur Veranschaulichung: im Bereich von 0..1€ gibt es genau 5 Beträge, die Excel
korrekt speichern kann: 0,00€ 0,25€ 0,50€ 0,75€ und 1€. Alle anderen Werte sind
nicht exakt speicherbar.
Gruß
Bernhard Sander
Volker Neurath
> Die wichtigsten Zahlen, die ein Computer genau speichern kann, sind Ganzzahlen.
>
> Man behilft sich in Datenbanksystemen bisweilen damit, dass man z.B.
> Geldbeträge
> als Ganzzahlen speichert indem man sie mit 100 oder oft auch mit 10000
> multipliziert und so der Problematik der unendlichen Binärzahlen als Umsetzung
>
> von endlichen Dezimalzahlen (für die Cent-Beträge) ausweicht.
Was letzlich auch nur eine Krücke ist.
Warum die Hersteller von zum Rechnen bestimmter PC-Software sich
standhaft weigern, das BCD-System zu nutzen, erschliesst sich mir nicht
wirklich. Ja ich weiss, dass das auch kein Allheilmittel ist.
Stattdessen wird weiter am Binärsystem festgehalten, was letzlich dafür
sorgt, dass z.B. Spreadsheets wie Excel zum Rechnen schlicht nicht
brauchbar sind -- es sei denn, der anwender ist experte in Mathematik
und kann den Rechenfehler formeltechnisch irgendwie ausgleichen (was
aber auch nur begrenzt möglich ist)
Volker
--
Wenn es vom Himmel Zitronen regnet -- lerne, Limonade zu machen.
Ka Prucha
> Warum die Hersteller von zum Rechnen bestimmter PC-Software sich
> standhaft weigern, das BCD-System zu nutzen, erschliesst sich mir nicht
> wirklich. Ja ich weiss, dass das auch kein Allheilmittel ist.
Ich habe etwa 20 Jahre mit eine BCD rechnenden System (HPL) gearbeitet.
Die Probleme sind dann eben bei 1/3 =0,333 und allen anderen Brüchen
deren Darstellung im Dezimalsystem zu lange bis endlos sind.
Es ist ein Tausch Teufel gegen Belzebub und bringt im Endeffekt nichts.
In VBA gibt es den Datentyp Currency.
Dieser wird als 64-Bit-Zahl (8 Bytes) in einem ganzzahligen Format gespeichert
und (automatisch) durch 10.000 dividiert, was eine Festkommazahl mit
5 Vorkomma- und 4 Nachkommastellen ergibt.
Ob dieser Datentyp in Excel auch von der Oberfläche aus anwählbar ist
kann ich nicht sagen.
mfg Ka Prucha
Volker Neurath
> "Volker Neurath" schrieb
>>
>> Warum die Hersteller von zum Rechnen bestimmter PC-Software sich
>> standhaft weigern, das BCD-System zu nutzen, erschliesst sich mir nicht
>> wirklich. Ja ich weiss, dass das auch kein Allheilmittel ist.
> Ich habe etwa 20 Jahre mit eine BCD rechnenden System (HPL) gearbeitet.
> Die Probleme sind dann eben bei 1/3 =0,333 und allen anderen Br�chen
> deren Darstellung im Dezimalsystem zu lange bis endlos sind.
> Es ist ein Tausch Teufel gegen Belzebub und bringt im Endeffekt nichts.
Und was spricht dagegen die software so zu gestalten, dass sie intern
nicht mit 0,3333333333333333333333333333333333333333....
rechnet, sondern mit 1/3?
Das k�nnen/machen heute schon diverse TR, die f�r kleines Geld auf'm
Grabbeltisch zu haben sind, warum nicht (teure) PC-Software?
> In VBA gibt es den Datentyp Currency.
> Dieser wird als 64-Bit-Zahl (8 Bytes) in einem ganzzahligen Format gespeichert
> und (automatisch) durch 10.000 dividiert, was eine Festkommazahl mit
> 5 Vorkomma- und 4 Nachkommastellen ergibt.
Bekannt.
> Ob dieser Datentyp in Excel auch von der Oberfl�che aus anw�hlbar ist
> kann ich nicht sagen.
Soweit ich weiss, nein.
Ka Prucha
> Und was spricht dagegen die software so zu gestalten, dass sie intern
> nicht mit 0,3333333333333333333333333333333333333333....
> rechnet, sondern mit 1/3?
Und was ist dann mit allen Zahlen die sich nicht durch eine Bruch
darstellen lassen.
Sollte aber das Problem der begrenzten Rechengenauigkeit gelöst
sein, folgt sofort das Problem der begrenzt genauen Eingabewerte.
mfg Ka Prucha
--
"Nichts zeigt den Mangel an mathematischer Begabung deutlicher,
als die übertriebene Genauigkeit beim Zahlenrechnen."
Johann Carl Friedrich Gauß