Date: prev next · Thread: first prev next last
2018 Archives by date, by thread · List index


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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.