Re: [de-users] Calc - Zählenwenn

Hallo Robert, *,

wenn das mit dem Bereich bei dir funktioniert, muss das ein Zufall sein.
Ich habe das Problem mal auf einen ziemlich einfachen Fall reduziert: 
alles spielt sich Zeile 2 ab, die Spalten beinhalten:
A: 1
B: 17
C: =A2/B2    Anzeige ist 0,058823529411765
D:                                      0,058823529411765    (ich habe 
das zum Vergleichen extra eingerückt)
E: =WENN(C1=D1;"gleich";"ungleich")    Anzeige: gleich
F: =ZÄHLENWENN(D2:D2;"="&C2)    Anzeige:0
G: =ZÄHLENWENN(D2:D2;"="&C2:C2)

Dass in E2 "gleich" steht, verblüfft, wenn man dann F2 und G2 anschaut, 
ich habe keine Erklärung dafür, es ist aber insofern eine glückliche 
Fügung, dass ich sicher sein kann, dass ich nicht falsch abgetippt habe 
und nur deshalb F2 und G2 immer 0 liefern.

F2 und G2 liefern nun beide den gleichen Wert 0, anders als in deinem Fall.

Abgesehen davon, dass die Hilfe auch von Leuten wie dir und mir 
beschrieben wird, man also keine Wunderdinge erwarten kann, die ganz 
besondere Situationen detailliert beschreiben, ist das eben gar kein 
Punkt, der in der Hilfe beshrieben werden kann, weil er nicht 
allgemeingültig ist, wie mein Beispiel zeigt.

Und das liegt, wie in den früheren Mails schon immer wieder angeklungen 
ist, an den Schwierigkeiten, die die Darstellung von gebrochenen 
Dezimalzahlen zumindest in den gebräuchlichen Computern macht, weil dazu 
in Binärzahlen umgerechnet werden muss und der Speicherplatz endlich ist 
(geregelt in der IEEE 754 seit 1985). Ein Dezimalbruch, der endlich ist, 
kann im Binärsystem unendlich sein (ich würde sogar gefühlsmäßig sagen, 
dass das die meisten sind, aber für eine präzisere Aussage müsste ich 
mich viel länger damit beschäftigen). Dadurch ergeben sich zwangsläufig 
Rundungsdifferenzen (den Begriff "Rundungs_fehler_" vermeide ich), da 
nur endlich viele Stellen zur Verfügung stehen. Es dürfte aber auch bei 
manchen auch im Binärsystem endlichen Brüchen zu Rundungsdifferenzen 
kommen, weil die Anzahl der zur Verfügung stehenden Stellen nicht ausreicht.
In meinem Beispiel ist sogar schon der Dezimalbruch periodisch und damit 
unendlich; im Binärsystem ist er es natürlich auch, weil 17 eine 
Primzahl ist.

Daher muss man _aus prinzipiellen Gründen_ beim Vergleich von 
Gleitkommawerten _immer _spezielle Maßregeln treffen (sobald einer davon 
berechnet ist, denn dann muss der interne Binärwert nicht unbedingt der 
gleiche sein wie der aus der Dezimaldarstellung errechnete), damit ein 
richtiges Ergebnis herauskommt: runden (wobei ich nicht die Hand ins 
Feuer lege, dass in seltenen Fällen auch das noch zu verschiedenen 
Werten führt; ich habe kein Beispiel, aber ich halte es für theoretisch 
möglich) oder noch besser die Abfrage, ob die Differenz der zu 
vergleichenden Werte größer ist als ein sehr kleiner Schwellwert, wie es 
ja auch schon in den früheren Mails beschrieben wurde.

Wenn die Funktion RANG tatsächlich immer das richtige Ergebnis liefert, 
dann hat deren Autor diese Maßnahmen offensichtlich in seinem Code 
getroffen, und du kannst froh sein, dass er deine Aufgabe bereits gelöst 
hat.

In der Hilfe kann meiner Meinung nach zu diesem Thema nichts stehen, da 
es sich um ein grundlegendes und der Computertechnologie immanentes 
Problem handelt, dessen man sich bewusst sein muss. Das wäre auch nicht 
anders, wenn man nicht die Basis 2 für die Speicherung von Zahlen 
verwenden würde, es wären dann nur andere Zahlen, die das gleiche 
Problem aufweisen würden. Und ich denke, mein Beispiel würde 
wahrscheinlich bei allen Systemen zum gleichen Problem führen, da 17 
eine Primzahl ist, und wenn nicht, dann wäre es Zufall und man fände 
schnell ein anderes.

Viel zum Thema findest du Im Wikipedia-Artikel "Gleitkommazahl".

Gruß

Gerhard

Am 27.05.2018 um 09:10 schrieb Robert Großkopf:
> Hallo Alois,
>
> > Kurz gesagt: eine direkte Prüfung auf Gleichheit funktioniert in der
> > Praxis nur mit Ganzzahlen (Integer,...).
> Na ja, dann würde ich aber doch in der Hilfestellung auf so etwas
> explizit hinweisen.
> Die Prüfung auf Gleichheit funktioniert ja schließlich auch dann, wenn
> ich die berechneten Zahlen (die gerundet sein mögen) nehme und
> vergleiche - siehe die erste Mail in diesem Thread. Die Prüfung
> funktioniert nur dann nicht, wenn ich die Rechnung als Grundlage nehme.
>
> Für mich sieht das eher so aus, als ob mit zweierlei Maß gemessen wird:
> Nehme ich die Elemente eines Bereichs, so wird nicht auf die Bezüge zu
> anderen Zellen geachtet. Nehme ich hingegen nur eine Zelle, so werden
> die Bezüge zu anderen Zellen berücksichtigt.
> Wenn ich statt
> =ZÄHLENWENN(D$10:D$14;">="&D11)
> z.B.
> =ZÄHLENWENN(D$10:D$14;">="&D11:D11)
> nehme, dann passt das Ganze.
>
> Ich darf also schlicht nicht Zellen mit Inhalten von Bereichen
> vergleichen, sondern muss aus Zellen Bereiche machen - und das liegt
> dann an den internen Berechnungsarten von Calc, die nirgendwo in der
> Hilfe auftauchen.
>
> Gruß
>
> Robert


--
Liste abmelden mit E-Mail an: users+unsubscribe@de.libreoffice.org
Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: https://listarchives.libreoffice.org/de/users/
Alle E-Mails an diese Liste werden unlöschbar öffentlich archiviert