Genauigkeit beim Rechnen

[Steffen Kother]

Hallo Leute,

ich weiß, dass Thema ist alt. Doch dass das Problem mit der
Ungenauigkeit auch schon bei einfachen Rechnereien (20 Zahlen)
auftritt, ist mir neu.

Gibt es eine Möglichkeit, dieses Manko zu bereinigen oder muss man halt
damit leben müssen? Unsere Kollegin im CO ist fast am verzweifeln...

Für Zahlenbeispiel einfach melden...

[Thomas Ramel]

Grüezi Steffen

Post by Steffen Kother
ich weiß, dass Thema ist alt. Doch dass das Problem mit der
Ungenauigkeit auch schon bei einfachen Rechnereien (20 Zahlen)
auftritt, ist mir neu.
Gibt es eine Möglichkeit, dieses Manko zu bereinigen oder muss man halt
damit leben müssen? Unsere Kollegin im CO ist fast am verzweifeln...
Für Zahlenbeispiel einfach melden...

Meld! ;-)

Am besten hier und auch mit Angabe der Zellen.
...denn ohne konkretes Beispiel lässt ich bloss die Verwendung der Funkton
RUNDEN() empfehlen.

[Steffen Kother]

Hier das File:

http://www.steffenkother.gmxhome.de/Excel_ungenau.xls

System der Kollegin ist NT 4.0 mit MSO SB 2000. Rechnet aber auch unter
XP Pro (meins) und MSO SB XP "falsch".

[A. Eckl]

Hallo,

formatiere einfach die ganze Zahlenreihe C3:C25 als Zahl mit 2
Nachkommastellen.
--
bis denn

Alois Eckl
www.excel-inside.de
___________________________




"Steffen Kother" <***@gmx.net> schrieb im Newsbeitrag news:bv2hua$n3v4i$***@ID-209655.news.uni-berlin.de...
| Hier das File:
|
| http://www.steffenkother.gmxhome.de/Excel_ungenau.xls
|
| System der Kollegin ist NT 4.0 mit MSO SB 2000. Rechnet aber auch unter
| XP Pro (meins) und MSO SB XP "falsch".
|
| --
| Mit freundlichen Grüßen / Kind regards
|
| Steffen Kother
|

[Steffen Kother]

Ist mir schon klar... und, was bringts. :-) Wenn ich das zehn mal mache
kann ich meine CO-Berechnungen vergessen!

[Thomas Ramel]

Grüezi Steffen

Post by Steffen Kother
http://www.steffenkother.gmxhome.de/Excel_ungenau.xls
System der Kollegin ist NT 4.0 mit MSO SB 2000. Rechnet aber auch unter
XP Pro (meins) und MSO SB XP "falsch".

Die errechente 'Differenz' bewegt sich im Bereich von 1^-12; ist somit also
sehr klein.
Du läufst hier in die problematik mit der Gleitkommaberechnung hiein. Hier
zwei Links aud der Micrsosoft-KB zum Thema:

http://support.microsoft.com/default.aspx?scid=kb;de;78113
http://support.microsoft.com/default.aspx?scid=kb;de;78113



Dein Problem könntest Du wie folgt lösen:

C25 =RUNDEN(SUMME(C3:C23);10)

[Steffen Kother]

Thnx Thomas,

Ist aber eben trotzdem schlecht, wenn statt 0 mit einer Zahl (Zahl =
fast Null) gerechnet wird. Runden und Zahlenformat ändern ja intern
nichts - wie beim Lifting, die Falten sind weg aber das Alter bleibt
;-)

Müssen mer halt damit leben.

Danke nochmal

[Thomas Ramel]

Grüezi Steffen

Post by Steffen Kother
Ist aber eben trotzdem schlecht, wenn statt 0 mit einer Zahl (Zahl =
fast Null) gerechnet wird. Runden und Zahlenformat ändern ja intern
nichts - wie beim Lifting, die Falten sind weg aber das Alter bleibt
;-)

Nicht ganz; wenn Du in einer Zelle mit RUNDEN() arbeitest, wird beim
weiterrechnen mit dieser Zelle der gerundete Wert verwendet.
Das reine Zahlenformat in der Zelle ändert am Wert aber in der Tat nichts.

Das Problem ist *nicht* Excel-spezifisch sondern stellt sich generell beim
Umrechnen Dezimal-Dual-Dezimal, da bestimmte dezimale Bruchwerte nicht
exakt im Dual-System abgebildet werden können.
Hast Du nun per Zufall einige solcher Dezimalbrüche in deinen Werten,
läufst Du zwangsläufig in dieses Problem.

Du kannst es nur lösen über eine geeignete Rundngs-Funktion, wie es in den
KB-Artikeln auch geschildert wurde.

[Patrick Kowalzick]

Post by Thomas Ramel
Das Problem ist *nicht* Excel-spezifisch sondern stellt sich generell beim
Umrechnen Dezimal-Dual-Dezimal, da bestimmte dezimale Bruchwerte nicht
exakt im Dual-System abgebildet werden können.
Hast Du nun per Zufall einige solcher Dezimalbrüche in deinen Werten,
läufst Du zwangsläufig in dieses Problem.

Was zwangslaeufig bei diesem Beispiel eine andere Frage aufwirft:
In der zweiten Spalte sind die Dezimal-Werte der ersten Spalte
multipiliziert mit 100 enthalten und das gewunschte Ergebnis wird erreicht.
Veraendere ich nun in der ersten Spalte einen Wert, so, dass er statt der
zwei drei Nachkommastellen hat (82.11 -> 82.111) tritt ein Rechenfehler in
der zweiten Spalte auf.

Deshalb meine Spekulation hier:
Eine Gleitkommazahl multipliziert mit einer anderen Zahl kann ein Integer
werden, wenn die Nachkommastellen nicht mehr signifikant sind.
Hmm, das faende ich aber ungeschickt. Ich finde das nicht nett wenn einfach
meine Fliesskommazahlen in Integer umgewandelt werden.

Viele Gruesse,
Patrick

[Thomas Ramel]

Grüezi Patrick

Post by Patrick Kowalzick
In der zweiten Spalte sind die Dezimal-Werte der ersten Spalte
multipiliziert mit 100 enthalten und das gewunschte Ergebnis wird erreicht.
Veraendere ich nun in der ersten Spalte einen Wert, so, dass er statt der
zwei drei Nachkommastellen hat (82.11 -> 82.111) tritt ein Rechenfehler in
der zweiten Spalte auf.

Ja; durch das Verschieben des Kommas umgehst Du die Gleikomma-Berechnung
(geht aber nicht endlox, da Excel max 15 Dezimalstellen 'erlaubt').

Mit dem Hinzufügen der 3. Nachkommastelle läufst Du erneut in die
Gleitkommaproblematik hinein.

Die KB-Artikel (hast Du sie gelesen und studiert?) weisen explizit auf
dieses Problem hin:

"So kann beispielsweise der Bruch 1/10 in einem Dezimalzahlensystem durch
0,1 repräsentiert werden. Dieselbe Zahl wird jedoch im Binärformat zu einer
periodischen Binärzahl:

0001100110011100110011 (und so weiter)

Diese ist theoretisch unendlich. Diese Zahl kann also nicht auf einem
beschränkten Speicherplatz gespeichert werden und wird daher beim Speichern
um -2.8E-17 abgerundet."

Post by Patrick Kowalzick
Eine Gleitkommazahl multipliziert mit einer anderen Zahl kann ein Integer
werden, wenn die Nachkommastellen nicht mehr signifikant sind.
Hmm, das faende ich aber ungeschickt. Ich finde das nicht nett wenn einfach
meine Fliesskommazahlen in Integer umgewandelt werden.

Das (oder auch umgekehrt) ist aber nun mal die Krux mit der
Gleitkommaberechnung.
Die Werkzeuge und Hintergründe werden in den KB-Artikeln ausführlich
geschildert; eine weitere mögliche Handhabung habe ich in meinem Beitrag
ebenfalls aufgezeigt.

Wo gibt es nun noch Probleme, zu deren Lösung wir beitragen können?

[Patrick Kowalzick]

Hallo Thomas,

Post by Thomas Ramel

Post by Patrick Kowalzick
In der zweiten Spalte sind die Dezimal-Werte der ersten Spalte
multipiliziert mit 100 enthalten und das gewunschte Ergebnis wird erreicht.
Veraendere ich nun in der ersten Spalte einen Wert, so, dass er statt der
zwei drei Nachkommastellen hat (82.11 -> 82.111) tritt ein Rechenfehler in
der zweiten Spalte auf.

Ja; durch das Verschieben des Kommas umgehst Du die Gleikomma-Berechnung
(geht aber nicht endlox, da Excel max 15 Dezimalstellen 'erlaubt').
Die KB-Artikel (hast Du sie gelesen und studiert?) weisen explizit auf
"So kann beispielsweise der Bruch 1/10 in einem Dezimalzahlensystem durch
0,1 repräsentiert werden. Dieselbe Zahl wird jedoch im Binärformat zu einer
0001100110011100110011 (und so weiter)
Diese ist theoretisch unendlich. Diese Zahl kann also nicht auf einem
beschränkten Speicherplatz gespeichert werden und wird daher beim Speichern
um -2.8E-17 abgerundet."

Post by Patrick Kowalzick
Eine Gleitkommazahl multipliziert mit einer anderen Zahl kann ein Integer
werden, wenn die Nachkommastellen nicht mehr signifikant sind.
Hmm, das faende ich aber ungeschickt. Ich finde das nicht nett wenn einfach
meine Fliesskommazahlen in Integer umgewandelt werden.

Das (oder auch umgekehrt) ist aber nun mal die Krux mit der
Gleitkommaberechnung.
Die Werkzeuge und Hintergründe werden in den KB-Artikeln ausführlich
geschildert; eine weitere mögliche Handhabung habe ich in meinem Beitrag
ebenfalls aufgezeigt.
Wo gibt es nun noch Probleme, zu deren Lösung wir beitragen können?

Verstaendnisprobleme ;-).

Ich verstehe die Problematik von Gleitkommazahlen im Prinzip schon. Das
stellt auch kein Problem da und ich weiss auch welche Stellen signifikant
sind und welche nicht. Was ich nicht wusste, ist die Tatsache, dass Excel
scheinbar ein eigenes Zahlenformat einfuehrt und sich nur eingeschraenkt an
die IEEE-Spezifikation haelt.

Was ich aber eben nicht gefunden habe ist folgendes:

-multipliziere ich eine Gleitkommazahl mit einer anderen Zahl (egal was),
was ist dann das Ergebnis der Multiplikation.
-oder in dem Fall oben: multipliziere ich eine Zahl auf zwei
Nachkommastellen mit 100 ist das Ergebnis ein Integer? (Ich muss nochmal
nachdenken ob ich nicht irgendwas falsch interpretiert habe)
-Unterscheidet Excel denn ueberhaupt in Integer und Fliesskommaarithmetik?

Sollte tatsaechlich eine Transformation einer Fliesskommazahl in einen
Integerwert auftreten, so empfinde ich dies als sehr ungewoehnlich, wenn
nicht sogar stoerend.

Viele Gruesse,
Patrick

[Thomas Ramel]

Grüezi Patrick

Post by Patrick Kowalzick

Post by Thomas Ramel
Wo gibt es nun noch Probleme, zu deren Lösung wir beitragen können?

Verstaendnisprobleme ;-).
Ich verstehe die Problematik von Gleitkommazahlen im Prinzip schon. Das
stellt auch kein Problem da und ich weiss auch welche Stellen signifikant
sind und welche nicht. Was ich nicht wusste, ist die Tatsache, dass Excel
scheinbar ein eigenes Zahlenformat einfuehrt und sich nur eingeschraenkt an
die IEEE-Spezifikation haelt.
-multipliziere ich eine Gleitkommazahl mit einer anderen Zahl (egal was),
was ist dann das Ergebnis der Multiplikation.
-oder in dem Fall oben: multipliziere ich eine Zahl auf zwei
Nachkommastellen mit 100 ist das Ergebnis ein Integer? (Ich muss nochmal
nachdenken ob ich nicht irgendwas falsch interpretiert habe)
-Unterscheidet Excel denn ueberhaupt in Integer und Fliesskommaarithmetik?
Sollte tatsaechlich eine Transformation einer Fliesskommazahl in einen
Integerwert auftreten, so empfinde ich dies als sehr ungewoehnlich, wenn
nicht sogar stoerend.

IMHO bleibt gemäss den Ausführungen in der KB die Fliesskommazahl eine
Fliesskommazahl. Je nach Grösse der Mantisse jedoch ist diese mehr oder
weniger genau.

Typenumwandlungen kommen in Excel (speziell VBA 'String' in Zahlen) zwar
vor, eine Fliesskomma --> Integer Umwandlucn dürfte es allerdings nicht geben.
Auch bei der Multiplikation eine Zahl mit 2 Nachkommstellen mit 100 wird
diese intern nach wie vor mit Exponent und manitsse gespeichert und
berarbeitet, obschon die *Darstellung* in der Zelle nun ganzzahlig ist.

[Patrick Kowalzick]

Hallo Thomas,

Post by Thomas Ramel
IMHO bleibt gemäss den Ausführungen in der KB die Fliesskommazahl eine
Fliesskommazahl. Je nach Grösse der Mantisse jedoch ist diese mehr oder
weniger genau.

Das hab ich in der KB nicht gefunden, aber ich hoffe es mal. Kommt aber
vielleicht dann in der naechsten Version :-(.

Ich denke bei dem urspruenglichem Beispiel ist folgendes passiert:

"In Excel 97 wurde jedoch eine Optimierungsfunktion eingeführt, mit der
versucht werden soll, dieses Problem zu beheben. Führt ein Additions- oder
Subtraktionsvorgang zu dem Wert Null oder zu einem Wert, der sehr nahe bei
Null liegt, kompensieren Excel 97 und spätere Versionen die Abweichungen,
die auf das Konvertieren eines Operanden in das und aus dem Binärsystem
zurückzuführen sind. Wird das vorstehende Beispiel in Excel 97 oder einer
späteren Version nachvollzogen, zeigt Excel korrekterweise 0 oder
0,000000000000000E+00 in der wissenschaftlichen Notation an."

Und das könnte IMHO so kommen (zweimal relativiert !!!!):
Multipliziert man in diesem Falle (eine oder zwei Nachkommastellen) mit 100,
erhaelt man Zahlen die sich rein ueber die Mantisse der Fliesskommazahl
ausdruecken liessen (was ja trotzdem nicht gemacht wird). Diese Zahlen
lassen sich also exakt abbilden. Kommt es das ein oder andere mal zu
Fehlern, fallen diese durch die guenstige Darstellung deutlich geringer aus,
als bei einer Multipklikation mit einer anderen Zahl. Der Fehler ist dabei
so gering, dass die tolle "Optimierungsfunktion" von Excel mal ein wenig
"herumoptimiert".

Verwendet man als Multiplikator ein Faktor 2^n der nur eine Veraenderung des
Exponenten hervorruft, wird man sehen, dass der Rechenfehler konstant
bleibt. (soll ja auch so sein) und in den meisten Faellen (ausser 6.25;
12.5; 25; 50; 100; 327(?)) entsteht eben auch ein Rechenfehler.

Viele Gruesse,
Patrick

P.S.: Ich finde es sehr schade, dass der Benutzer von Excel keinerlei
Moeglichkeiten hat, nettgemeinte "Optimierungen" von Excel zu umgehen. Siehe
z.B. die Eingabe von A1-1 in Excel 2002 o.ä..

[Thomas Ramel]

Grüezi Patrick

Post by Patrick Kowalzick
Verwendet man als Multiplikator ein Faktor 2^n der nur eine Veraenderung des
Exponenten hervorruft, wird man sehen, dass der Rechenfehler konstant
bleibt. (soll ja auch so sein) und in den meisten Faellen (ausser 6.25;
12.5; 25; 50; 100; 327(?)) entsteht eben auch ein Rechenfehler.

Ich denke hier waren wir bei des Pudels Kern - Danke für die angeregte
Diskussion.

Post by Patrick Kowalzick
P.S.: Ich finde es sehr schade, dass der Benutzer von Excel keinerlei
Moeglichkeiten hat, nettgemeinte "Optimierungen" von Excel zu umgehen. Siehe
z.B. die Eingabe von A1-1 in Excel 2002 o.ä..

Hmmm Formatierunng im Textformat oder vorangestelltes Hochkomma?

[A. Eckl]

Hallo Steffen,

ich denke das Problem liegt beim Runden. Wenn sich bei Rechenaktionen
Dezimalzahlen mit mehr als 2 Nachkommastellen ergeben und diese über die
Formatfunktion auf 2stellige Nachkommazahlen eingestellt werden ergibt sich
das Problem, dass Excel zwar 2 Nachkommastellen anzeigt, die interene
REchnung jedoch nach wie vor mit allen Nachkommastellen erfolgt. Abhilfe
schafft hier die Funktion Runden(Wert;Nachkommastellen) bspw.
=Runden(195,4567;2) die Zahl wird nun richtig auf 195,46 gerundet und es
wird auch mit dieser Zahl weitergerechnet.
--
bis denn

Alois Eckl
www.excel-inside.de
___________________________




"Steffen Kother" <***@gmx.net> schrieb im Newsbeitrag news:bv2ef1$ndc5n$***@ID-209655.news.uni-berlin.de...
| Hallo Leute,
|
| ich weiß, dass Thema ist alt. Doch dass das Problem mit der
| Ungenauigkeit auch schon bei einfachen Rechnereien (20 Zahlen)
| auftritt, ist mir neu.
|
| Gibt es eine Möglichkeit, dieses Manko zu bereinigen oder muss man halt
| damit leben müssen? Unsere Kollegin im CO ist fast am verzweifeln...
|
| Für Zahlenbeispiel einfach melden...
|
| --
| Mit freundlichen Grüßen / Kind regards
|
| Steffen Kother
|

[Frank Kabel]

Hallo Steffen

oder als eine weitere Möglichkeit unter 'Extras - Optionen' im Reiter
'Berechnen' die Option 'Genauigkeit wie angezeigt' ankreuzen.
Grundsätzlich rechnet excel<nämlich nicht falsch.
Frank

Post by A. Eckl
Hallo Steffen,
ich denke das Problem liegt beim Runden. Wenn sich bei Rechenaktionen
Dezimalzahlen mit mehr als 2 Nachkommastellen ergeben und diese über
die Formatfunktion auf 2stellige Nachkommazahlen eingestellt werden
ergibt sich das Problem, dass Excel zwar 2 Nachkommastellen anzeigt,
die interene REchnung jedoch nach wie vor mit allen Nachkommastellen
erfolgt. Abhilfe schafft hier die Funktion
Runden(Wert;Nachkommastellen) bspw. =Runden(195,4567;2) die Zahl wird
nun richtig auf 195,46 gerundet und es wird auch mit dieser Zahl
weitergerechnet.

Post by Steffen Kother
Hallo Leute,
ich weiß, dass Thema ist alt. Doch dass das Problem mit der
Ungenauigkeit auch schon bei einfachen Rechnereien (20 Zahlen)
auftritt, ist mir neu.
Gibt es eine Möglichkeit, dieses Manko zu bereinigen oder muss man
halt damit leben müssen? Unsere Kollegin im CO ist fast am
verzweifeln...
Für Zahlenbeispiel einfach melden...
--
Mit freundlichen Grüßen / Kind regards
Steffen Kother

[Steffen Kother]

Danke Frank,

Post by Frank Kabel
'Genauigkeit wie angezeigt'

Aber die (Sicherheits)Frage kennst du?

"Damit verlieren die Daten _endgültig_ ihre Genauigkei."

[Frank Kabel]

Post by Steffen Kother
Danke Frank,

Post by Frank Kabel
'Genauigkeit wie angezeigt'

Aber die (Sicherheits)Frage kennst du?
"Damit verlieren die Daten _endgültig_ ihre Genauigkei."

Hi Steffen,

kenne ich (leider). Einen Tod muss man bei Excel wohl sterben :-(. M.E.
hast du leider nur die zwei Möglichkeiten:
1. Die Runden Funktion in nahezu alle Formeln einbauen, wenn es wichtig
ist, das die angezeigten Ergebnisse mit den tatsächlich benutzten
übereinstimmen
2. Die Genauigkeit áuf die Anzeige beschränken (und evtl. 3
dezimalstellen benutzen)

Frank