Fehlerhafte CALC-Funktionen?

Deutsch
, , ,
#1

Hallo,

Version: 5.2.1.2 /32-Bit
Version: 5.2.2.2 /32-Bit
WINDOWS 10 PRO 64-Bit

mit beiden obengenannten LO-Versionen habe ich
in angehängter Datei ein Problem, wenn ich die
CALC-Funktionen INDEX/ VERGLEICH und auch mit SVERWEIS arbeite.

Wenn ich auf Zahlen verweise wird kein Fehler erzeugt.
Wenn ich mit Texten arbeite, werden mir teilweise Fehler(#NV) angezeigt.

Weitere Beschreibung siehe in der Datei:
Index Vergleich SVerweis.ods

Für den Fall das bei Euch keine Fehler erzeugt weren, habe ich die Ergebnisse
der Funktionen in Textform, in den grünhinterlegten Zelle abgelegt.

Gruß

Craig

#2

Jede Software ist fehlerhaft (außer der von selbstfahrenden Autos natürlich). In diesem Fall steckt aber der maßgebliche Fehler in der Anwendung.

#3

Du benutzt VERGLEICH ohne den optionalen Parameter für die Vorsortierung. Das bedeutet per Voreinstellung das Gleiche, wie der Parameterwert 1: Steigende Vorsortierung des 1D-Suchbereichs wir zugesichert. In lexikographischer Sortierung ist aber z.B. “xx10” kleiner als “xx9”.
Falls du nie “zwischen die Posten treffen” musst, kannst du den Sortierungsparameter auf 0 setzen (exakter Treffer gefordert; keine Vorsortierung zugesichert). Die Funktion arbeitet dann zwar weniger effektiv, aber bei den ganz kleinen Datensätzen wird das ziemlich wurscht sein.
Bei SVERWEIS geht das auch. (Aber meistens ist eine Kombi mit MATCH empfehlenswerter.)

Nachtrag: Wie ich gerade zusätzlich sehe, ist der Suchbereich zu lang (bis Reihe 50 statt 35). Das ist auch mit der zugesicherten Sortierung unverträglich. Ansonsten könntest du die Formal lassen wie sie ist, wenn du deine Schuhgrößen mit fester Anzahl von Ziffern schreibst: xx03, xx04, …xx10, xx11 usw. Dann stimmt die lexikographishe Sortierung mit der arithmetischen überein, solange das “xx” schön irrelevant bleibt.

(Bearbeitung entsprechend meinem Kommentar zur Antwort von @Craig22:slight_smile:
Hier die erwähnte Beispieldatei.

#4

Hallo

…
Zusammegefasst:
Sortiere im Tabellenblatt Texte nach Spalte B aufsteigend, und alles ist gut.

Karolus

@Lupp Ja, das habe ich probiert… →→ _sortiert.ods
(Du darfst da nicht mit der Option [x]natürliche Sortierung arbeiten, die “versteht” VERGLEICH etc. nicht)

#5

Zusammengefasst?
Hast du das auch versucht?

#6

“Du darfst da nicht mit der Option ‘natürliche Sortierung’ arbeiten,…” Ja, das weiß ich natürlich auch. Allerdings hätte ich nicht erwartet, dass VERGLEICH und SVERWEIS die überschießenden leeren Zellen in ‘Texte.B36:B50’, die ja der Sortierungszusicherung nicht entsprecehen, duldet. Finde ich auch nicht gut.

#7

Hallo,

ich schäme mich in Grund und Boden, dass ich als erfahrener Anwender
diesem typischen Anfängerfehler aufgesessen bin.

Das Resümee der Geschicht, vergiss die optionalen Parameter nicht und sortiere ggf. richtig, bevor die Funktionen zum Einsatz kommen.

@Lupp

„Allerdings hätte ich nicht erwartet,
dass VERGLEICH und SVERWEIS die
überschießenden leeren Zellen in
‘Texte.B36:B50’, die ja der
Sortierungszusicherung nicht
entsprecehen, duldet. Finde ich auch
nicht gut. „

Ich verstehe hier nicht, was daran nicht gut sein soll?

Ist dies nicht ein alltäglicher Vorgang, dass man überschießende leere Zellen/Zeilen in einer Auflistung hat.
z.B. in Spalte A → Artikelnummer und in Spalte B → Bezeichnungen.

Die Liste ist definiert von A1:B1000, wobei z.Z. nur 800 Zeilen benutzt werden, aber zukünftig weitere Artikel hinzukommen.

Würde man in der Funktion nicht von vornherein auf den gesamten Bereich verweisen, dann wäre man bei jedem neuen Artikel gezwungen die Funktionen anzupassen.

Ich bedanke mich für Eure Zeit und Eure Antworten.

Viele Grüße

Craig

#8

“Ich verstehe hier nicht, was daran nicht gut sein soll?”
Leere Zellen sind < im Vergleich mit allem Anderen. Um sie am Ende des Suchbereichs der Sortierungszusicherung “steigend” erlauben zu knnen, muss der Suchbereich Schritt für Schritt durchgegangen werden. Das wesentlich effizientere Intervallhalbierungsverfahren scheuidet dann für die Treffersuche aus (oder muss in komplizierter Weise abgewandelt werden.

#9

Schritt für Schritt? Vielleicht wird auch im Hintergrund der Suchbereich vorab verkleinert. ‘Data’ > '‘Sort’ scheidet leere Zellen ganz aus. Eine Lösung des Problems ist das aber auch niccht, weil leere Texte (die aber von den meisten Usern als leere Zellen angesehen werden), ja einsortiert werden müssen. Übrigens wird (zumindest) von LiO 5.2 Eine Zelle, die durch Referenzierung einer leeren Zelle G11 mit {=OFFSET(G11;0;0;1;1)} “Transparent leer” ist, wieder als leer behandlet.

#10

Wer mag jetzt prüfen wie das in älteren Versionen ist? (Oft geändert, vermutlich.)
Alle Versuche von Office-Software, "smart"zu sein, kann man vermutlich widerlegen.
Naja. Ich hab’s gern klar und eindeutig spezifiziert. Die ‘OpenFormula’ Spezifikation für MATCH überläasst mal wieder Wichtiges der Implementierirung. Welch Glück, dass ich Calc kaum mehr brauche.

#11

“Würde man in der Funktion nicht von vornherein auf den gesamten Bereich verweisen, dann wäre man bei jedem neuen Artikel gezwungen die Funktionen anzupassen.”
Wenn man über die benötigte Metainformation korrekt buchführt, und kleine Komplikationen inkauf nimmt, kann man die Bereiche korrekt parametrisieren. Ich mache das auch. Nur die Größe der Sperrbereiche für die Ausgabe von Matrixfunktionen geht das nicht.

#12

“Wenn man über die benötigte Metainformation korrekt buchführt, und kleine Komplikationen inkauf nimmt, kann man die Bereiche korrekt parametrisieren. Ich mache das auch.” (Lupp)
Ich habe eine Beispieldatei in meine obige Antwort eingehängt.

#13

Hallo Lupp,
vielen Dank für Deine Erklärungen und ganz besonderen Dank für die Datei.
Die Datei zeigt mal wieder, dass mit einer intelligenten Kombinatorik von Funktionen und dem passendem Tabellenaufbau eine hohe Flexibilität erreichbar ist. Auch wenn Calc mal wieder als kleine Datenbank missbraucht wird. :slight_smile:
Die Datei gibt mir einen Anlass für mich eine kleines Projekt zu bilden.
Ich habe verstanden was Du mir mitteilen wolltest.
Viele Grüße
Craig

#14

@Craig22: Gerngschäng! (Das ist Mittelbairisch. Wörtlich: Gerne geschehen!))

#15

Hallo
@Lupp Kommentar 1:
Ich vermute hier, daß Calc über ein Art “Vorverarbeitung der Argumente” verfügt, die dafür sorgt das komplett leere Bereiche vor|hinter den relevanten Daten weggeschnitten werden, und dann nur das relevante an die eigentliche Funktion weiterreicht.

#16

@karolus: Ja, schon! Aber ob ‘blank’ und ‘empty text’ und ‘reference to a blank cell by OFFSET’ gleich relevant, irrelevant oder sonstws sind? Wo ist das spezifiziert? Was is vernünftig? Heute dies, morgen das? Raten oder vermuten (im Sinne von “reverse engineering”) ist spannend. Ich mache das auch gerne. Spreadsheetergebnisse sollten aber nicht spannend sondern verlässlich sein.
An “Smart Software” glauben ist des Teufels. (Meine unverbindliche Meinung.)

#17

Hallo,
meine Vermutung(!) ist, dass zur Sortierung die Eigenschaften der „.table.CellContentType“ hinzugezogen werden. Ich habe mittels Basic(CurrentSelection) und MRI die Eigenschaften einer Zelle untersucht:

 LEER  →  String=““ → Value=0.0 → Type =EMPTY
 FORMEL mit Ergebnis=0  →  String=0 → Value=0.0 → Type =FORMULA
 FORMEL mit „leerem Ergebnis“  →  String=““ → Value=0.0 → Type =FORMULA 
 Letzteres bei der obengenannten Matrixfunktion „Offset/Verschiebung"
#18

@Craig22: Ja, schon (so etwa)! Ich vermute allerdings eher, dass der “Core” des Programms auch Möglichkeiten nutzt, die von der API nicht unterstützt werden. Wenn wir sowas via API machen, müssen wir aber nicht jede Zelle einzeln als Objekt erzeugen (ineffizient!), sondern können die Array-Eigenschaften CellRange.DataArray und CellRange.FormulaArray auswerten.
Aber: Was ich @karolus bezüglich Vermutungen geantwortet habe, gilt natürlich auch hier.

#19

Hallo

Eigentlich hab ich hier keine Lust darauf eine Metadiskussion darüber zu führen was sinnvoll ist oder nicht, und oben schrieb ich auch … vermute ….
Andererseits gehe ich davon aus das Calc nicht jedesmal ~3*10^6 Zellen abklappert wenn smarter Benutzer z.B. B:D als Bereichsargument angibt.

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.