Live-Forum - Die aktuellen Beiträge
Datum
Titel
28.03.2024 21:12:36
28.03.2024 18:31:49
Anzeige
Archiv - Navigation
1496to1500
Aktuelles Verzeichnis
Verzeichnis Index
Übersicht Verzeichnisse
Vorheriger Thread
Rückwärts Blättern
Nächster Thread
Vorwärts blättern
Anzeige
HERBERS
Excel-Forum (Archiv)
20+ Jahre Excel-Kompetenz: Von Anwendern, für Anwender
Inhaltsverzeichnis

Paradoxer Vergleich

Paradoxer Vergleich
19.06.2016 09:08:12
Loge
hallo,
bin zum 1. mal hier und hoffe, dass mir jemand für folgendes problem eine erkärung liefern kann:
in 2 zellen steht die gleiche zahl:
0,3458333333
0,3458333333
wenn man testet, ob die zahlen gleich sind erhält man WAHR
wenn man die differenz bildet, erhält man 0,000...
wenn man allerdings die differenzen testet:
=WENN(ZAHL1-ZAHL2>0;1;WENN(ZAHL1-ZAHL2 bemerkt habe ich das, als ich zeitdifferenzen berechnet habe, die minimal 0 werden können. dabei habe ich in wenigen fällen als ergebnis ein "##############" erhalten. excel liefert als erklärung dafür, dass das u.a. dann passiert, wenn ein zeitformat auf negative zahlen angewendet wird und ein paar tests ergaben dann das oben beschriebene paradoxon.
wäre wie gesagt schön, wenn mir das jemand erklären könnte.
lg, bio

13
Beiträge zum Forumthread
Beiträge zu diesem Forumthread

Betreff
Datum
Anwender
Anzeige
AW: ist einerseits so nicht ganz korrekt ...und...
19.06.2016 09:33:41
...
Hallo,
... wenn Du in 2 Zellen wirklich die gleichen (identischen) Zahlen zu stehen hast, ergibt sich als nicht nur der Vergleich zu WAHR sondern auch die Differenz zu 0.
Womöglich hast Du jedoch zumindest eine der beiden Zahlen erst errechnet und sie erscheinen Dir nur als gleiche/identische Zahl. In Wirklichkeit sind diese jedoch minimal anders. Das ist bei Berechnungen in/mit Excel jedoch bekannt. Excel kann nämlich nur mit einer Genauigkeit von 15 Stellen rechnen.
Abhilfe: Du solltest Deine Berechnungen (insbesondere bei Zeitangaben) auf eine definierte Genauigkeit runden lassen, z.B. mittels der Funktion RUNDEN().
Gruß Werner
.. , - ...

Anzeige
AW: Paradoxer Vergleich
19.06.2016 09:48:41
Loge
hi werner,
danke für deine schnelle antwort. ich habe vergessen zu erwähnen, dass ich (um das rundungsproblem zu vermeiden) die ergebnisse der berechnung mit kopieren und "werte einfügen" in zahlen umgewandelt habe. danach wird in der bearbeitungszeile beim anklicken der entsprechenden zellen der identische wert angezeigt (auf 15 stellen genau). kann denn dann auch noch ein unterschied bestehen?
bio

AW: dann normalerweise nicht ...
19.06.2016 10:13:42
...
Hallo bio,
... kannst Du mal Deine Datei mit den zwei Zellen hier hochladen?
Gruß Werner
.. , - ...

AW: Paradoxer Vergleich
19.06.2016 16:43:30
Loge
sorry für die verzögerung...
ich habe die beiden zahlen in notepad kopiert und dann wieder eingefügt. dann ist alles so, wie es sein soll. also scheinen die beiden zahlen solange man nur in excel mit ihnen rumhantiert doch nicht exakt gleich zu sein (auch wenn die differenz wirklich gleich NULL ist). hier kommt jetzt die datei mit dem beispiel.
https://www.herber.de/bbs/user/106342.xlsx

Anzeige
das ist die Anzahl der Nachkommastellen
19.06.2016 16:59:54
WF
Hi,
=C3-C4 ergibt FALSCH
reduzierst Du die Nachkommastellen in C3 und C4 jeweils um eine, ergibt sich WAHR.
wie gesagt: Fließkommaproblematik in Excel
WF

was ich nicht verstehe...
19.06.2016 18:31:20
Michael
Hi zusammen,
im ersten Moment dachte ich, daß Excel vielleicht eine Klammersetzung benötigt...
=WENN((Z3S3-Z4S3)=0;0;"nicht Null")

... aber offensichtlicht wird zuerst die Subtraktion und dann erst der Vgl. ausgeführt.
Aber: wenn ich das schrittweise mit F9 mache...
Userbild
kommt das erwartete Ergebnis heraus: d.h., Excel KÖNNTE es eigentlich "richtig", tut es aber nicht.
Schöne Grüße,
Michael

Anzeige
AW: Genauigkeitsproblematik: 15 Ziffernstellen....
19.06.2016 20:17:03
...
Hallo Michael,
... die vom Fragesteller angeführte Problematik ist allein auf die von ihm als "Nachweis des paradoxen" eingesetzte Rechenoperation (hier Subtraktion) zurückzuführen. Denn Excel erkennt durchaus die puren Zahlenwerte als identisch, solange dazu eben nur Vergleichsoperationen mit = oder vorgenommen werden.
Dagegen kann es bei Rechenoperationen intern dazu kommen, dass die "Genauigkeitsgrenze" gebrochen wird. Diese Grenze liegt, wie ich schon schrieb, bei 15 Zifferstellen. 15 Stellen heißt aber nicht bei 15 Nachkommastellen, wie verschiedentlich zu lesen oder zu hören ist.
Die "Genauigkeitsgrenze" von Excel kann man mit einem simplen Test erkennen. Wenn man folgende Zahl: 1234567890123456 (hat 16 Zifferstellen) in eine Excelzelle (mit einem entsprechend definierten Zahlenformat) schreibt, werden davon eben nur exakt die ersten 15 Stellen wiedergegeben. Die letzte Ziffer 6 wird einfach und sofort von Excel zur 0 degradiert. Schreibt man nur die ersten 15 Stellen dieser Zahl, wird Excel diese dagegen immer exakt darstellen, egal wo immer man das Komma einfügt.
Im Sonderfall, dass vor die erste 1 der 15 stelligen Zahl ein "0," vorangestellt wird, hat man auch eine Genauigkeit von 15 Nachkommastellen. Aber eben nur in diesem Sonderfall. Sobald man anstelle der 0 vor dem Komma eine Ziffer ungleich 0 stellt, wird die letzte Ziffer 5 vorgenannter 15 stelligen Zahl zur 0. Somit reduziert sich die Nachkommastellengenauigkeit dieser Zahl von 15 auf 14 ... bis auf 0 je nach Kommastellung.
Möglicherweise wird deshalb die aufgezeigte Problematik als Fließkommaproblematik bezeichnet. Dieser Begriff allein erläutert aber mE die Problematik nur bedingt.
Ich schreibe deshalb immer, was ich auch hier bereits getan habe: Excel kann halt Zahlen nur mit max. 15 Ziffernstellen genau wiedergeben. Aber, das ist jedoch nicht damit zu verwechseln, dass Excel eine Zahl durch entsprechendes benutzerdefiniertes Zahlenformat auch mit mehr als nur 15 Zifferstellen darstellen kann. Aber eine solche lediglich dargestellte Zahl kann zwar muss aber weder dem Eingabewert noch dem exakten Ergebnis einer Operation entsprechen.
Warum MS überhaupt ein benutzerdefiniertes Zahlenformat von mehr als 15 Zifferstellen zulässt, dass musst Du allerdings MS fragen ;-).
Gruß Werner
.. , - ...

Anzeige
Das folgende Bsp illustriert das ganz gut, ...
20.06.2016 02:14:08
Luc:-?
…Werner,
wobei dann auch klar wird, dass intern mit mehr Stellen (hier Dezimalen) gerechnet wird, was auch erforderlich ist, um exakt runden zu können. Die Rechenbreite dürfte also mindestens 16 Stellen betragen, was auch mit den internen Bits und Bytes (der ZahlenCodierung) harmoniert.
 FGH
13gleichkleinergrößer
14NeeNeeJa
15JaNeeNee
16F14:=WENN(PI()-TEXT(PI();"0,"&WIEDERHOLEN(0;14))=0;"Ja";"Nee")
17F15:=WENN(PI()=--TEXT(PI();"0,"&WIEDERHOLEN(0;14));"Ja";"Nee")
18G14:=WENN(PI()-TEXT(PI();"0,"&WIEDERHOLEN(0;14))<0;"Ja";"Nee")
19G15:=WENN(PI()<--TEXT(PI();"0,"&WIEDERHOLEN(0;14));"Ja";"Nee")
20H14:=WENN(PI()-TEXT(PI();"0,"&WIEDERHOLEN(0;14))>0;"Ja";"Nee")
21H15:=WENN(PI()>--TEXT(PI();"0,"&WIEDERHOLEN(0;14));"Ja";"Nee")
Übrigens, FestkommaSysteme dürften das Problem nicht haben, denn das Komma wird nachträglich an eine zuvor festgelegte Position gesetzt. Bei GleitkommaSystemen ist das nicht der Fall (das Komma wandert bzw fließt/gleitet).
Bei begrenzter DatenLänge wird vor der Darstellung bedarfs­weise gerundet. Der Vgl von „fertigen“ Zahlen ist dadurch nicht problematisch, der aus der Berechnung heraus aber schon.
Gruß, Luc :-?

Anzeige
ja, aber
20.06.2016 08:42:55
Michael
Hi Werner & Luc :-?,
reden wir aneinander vorbei?
Die oberste Zeile der Grafik gibt den Zustand der zitierten Formel (allerdings wie im Original ohne die zusätzlichen Klammern) mit folgender Markierung
=WENN(Z3S3-Z4S3=0;0;"nicht Null")
NACH dem 1. F9 wieder.
Bei F9 kommt also (ob das nun richtig oder falsch ist, sei dahingestellt) 0 raus.
D.h., Excel führt mit F9 ANDERE Berechnungen durch als wenn ich nicht F9 verwende: das ist das, was mich verwundert.
Mann, ich erinnere mich dunkel an Physik: die Berechnung der Auswirkung von Rundungsfehlern bei mehreren, verschachtelten Berechnungen.
Man sollte mit Excel vielleicht nicht weiter als bis zum Mond fliegen, bis dahin tun's noch die Steuerdüsen...
Schönen Tag, bis heute nachmittag,
Michael

Anzeige
Keine andere Berechnung mit [F9], ...
20.06.2016 20:01:27
Luc:-?
…Michael,
nur vorzeitige ErgebnisDarstellung! Das Eine ist die Berechnung, das Andere die Abbildung desselben in Xl, ob nun im Fml-Assi, der EditierZeile oder direkt in der Zelle. Ist das RechenErgebnis erst einmal als Zahl fixiert, wird damit weitergerechnet. Anderenfalls führt Xl ggf noch Fml-Optimierungen aus, wodurch das Ganze zu einem einheitlichen RechenProzess verschmelzen dürfte, der dann mit 16 Ziffern arbeiten würde. Darauf deutet auch hin, dass deine Klammerung hier nichts nützt.
Das sieht man auch sehr schön an meinem Bsp. Wdn die beiden Werte subtrahiert, stehen die 15 Stellen allein für die Dezimalen zV, da die Ganzzahl=0 ist. Wdn dagg beide Zahlen vglichen, teilen sich die 15 Stellen auf 1 für die Ganzzahl und 14 für Dezimalen auf. Damit würde auch die 15.Dezimale unter den Tisch fallen, die bei Subtraktion noch ermittelt wird und den Wert 3 hat (⇒3,10862E-15). D.h., nicht nur eine 16.Stelle kann Einfluss ausüben, sondern auch die 15., sowie generell die darstellbar-letzte u/o die ihr bei Berechnungen folgende Dezimale. Das ist die kleine RechenUngenauigkeit, die sich aus der Gleitkomma­Problematik ergibt.
In wissenschaftlicher Darstellung wdn (wie oben) noch weitere Stellen sichtbar, also könnte die tatsächliche Rechen(-Ergebnis-)Breite noch größer, aber nicht unbedingt ergebnis­verwertbar sein.
Gruß, Luc :-?

Anzeige
Jein
24.06.2016 14:32:57
Michael
Hi Luc :-?,
bei WFs Beispiel kommt mit F9 tatsächlich =GANZZAHL((0,0599999999999996)*100) heraus, also das UNerwartete Ergebnis, aber bei den zwei Zahlen aus dem Beispiel eben (mit F9) 0, anders als ohne F9.
Siehe: https://www.herber.de/bbs/user/106491.xlsx
Tatsächlich haben beide Zahlen (mit len(r.text)) die Länge 18...
Na, ich kann damit umgehen, da ich immer brav runde, aber seltsam isses schon.
Schöne Grüße,
Michael

uralte Fließkommazahlproblematik
19.06.2016 11:44:00
WF
gib mal ein:
=GANZZAHL((2+0,06-2)*100)
und jetzt:
=GANZZAHL((4+0,06-4)*100)
und wundere Dich
WF

Anzeige
AW: mE nur bei Berechnung(en), jedoch ...
19.06.2016 12:50:48
...
Hallo WF,
... der Fragesteller schrieb in seinem zweiten Beitrag:
"... dass ich (um das rundungsproblem zu vermeiden) die ergebnisse der berechnung mit kopieren und "werte einfügen" in zahlen umgewandelt habe. danach wird in der bearbeitungszeile beim anklicken der entsprechenden zellen der identische wert angezeigt (auf 15 stellen genau)"
Auf die Rechen(un)genauigkeit hatte ich ja schon in meinem ersten Beitrag hingewiesen. Wenn aber bei ihm gemäß seiner Behauptung die Zellwerte wirklich identisch sein sollten, ist die Differenz der beiden Werte im Normalfall auch 0. Jedenfalls bei mir.
Ich vermutete deshalb, dass seine Zahlenwerte doch nicht identisch sind oder irgend ein anderer Einfluss vorliegt. Deshalb bat ich den Fragesteller um Einstellung seiner Datei, wo seine Behauptung auch nachvollziehbar wäre.
Gruß Werner
.. , - ...
Anzeige

Beliebteste Forumthreads (12 Monate)

Anzeige

Beliebteste Forumthreads (12 Monate)

Anzeige
Anzeige
Anzeige