Formel über drei Tabellen

Beiträge zum Forumthread

Beiträge zu diesem Forumthread

Betreff

Datum

Anwender

…Werner,
und dann wäre tatsächlich die FmlText-Interpreter-Umstellung schuld. Aber mal der Reihe nach:
INDEX kommt mit nur einem weiteren Argument (Nr 2) aus, wenn Argument 1 ein Ko-/Vektor (Zeilen-/SpaltenBereich bzw entsprd Datenfeld als MatrixKonstante oder aus einem Ausdruck als Arg1 resultierend) ist. Anderenfalls wdn stets beide FolgeArgumente (2 u.3) benötigt, was durch das Setzen des vorstehenden Trennzeichens (;) eingeleitet wird. Bleibt diese Angabe dann leer, wird die entsprd PgmVariable nicht gefüllt und würde in VBA den Initialwert ihres Datentyps haben. Da INDEX mit Sicherheit in einer anderen Sprache (wahrscheinl ein C-Derivat) pgmmiert wurde, kann das auch etwas anders aussehen und mit 0 würde dann automatisch indiziert, es sei denn, ein anderer Default-Wert wurde explizit im Pgm angegeben. Das ist bspw bei W-/SVERWEIS für das 4.Argument der Fall, dessen Default-Wert 1 (WAHR) ist, wenn gar nichts (auch kein vorstehendes ;)* angegeben wurde. Anderenfalls wird 0 (FALSCH) verwendet. Bei VERGLEICH ist das ähnlich, 1 ist Default, -1 muss angegeben wdn, für 0 reicht die Angabe des ListenTrennZeichens (;).
* Allerdings hat der Fktsassi von Xl (bei Aufruf) die „Angewohnheit“, endständige Solo-Trennzeichen (;) zu löschen, wenn kein Wert folgt.
Nun besteht bei INDEX aber das Problem, dass mit Argg2/3=0 eine ganze Spalte bzw Zeile eines Bereichs oder Datenfelds wiedergegeben wdn kann, mit ;; bzw ;0;0 dann die ganze Matrix, was bei reiner Wiedergabe normalerweise die MatrixFmlForm erfordern würde. Es kann aber auch sein, dass man die ganze Matrix für weitere Berechnungen in derselben Fml benötigt und am Ende nur einen Wert erhält. Deshalb ist mir fraglich, ob das mit der neuen Fml-Interpretation noch so fktionieren würde*.
* Deshalb hatte ich vor Jahren bei meiner eigenen UDF zur Realisation automatischer Matrix-ErgebnisAusdehnung stets wenigstens 2 Zellen manuell auswählen lassen, womit gleichzeitig die Ausdehnungsrichtung von (Ko-)Vektor-Ergebnissen bestimmt wurde. Lt Lupo hat Google-Docs dafür ja auch eine spezielle ZusatzFkt verwendet, also wohl ähnliches Prinzip.
Ein #WERT!-Fehler entsteht idR dann, wenn einer Fkt ein nicht-optionales Argument nicht übergeben wurde, also in der Fml fehlt. Anderenfalls tritt der Default- (falls vorgesehen) oder der InitialWert des Arguments in Kraft. INDEX hatte bisher keine Default-, nur InitialWerte lt DatenTyp. Allerdings kann in der verwendeten PgmmierSprache zwischen gänzlichem Fehlen eines Arguments (inkl ;) und Nicht-Angabe desselben (nur ;) unterschieden wdn, was in VBA schwierig, aber auch schon in JavaScript möglich ist. Ich glaube auch nicht, dass es hierbei einen Interpretationsunterschied zwischen MatrixFmlForm und NormalForm gibt, denn immerhin hat Erich flgd Form bestätigt:
INDEX($A:$BZZ;ZEILE();VERGLEICH(CAA$1;$1:$1;0))=INDEX(Auswahl!$C:$C;SPALTE(B$1);0)
Man sieht, dass beim 2.INDEX die 0 als 3.Argument weiterhin zulässig ist. Wahrscheinlich wäre sie es auch für das 2.Argument des 1.INDEX. Die neue FmlTextInterpretation scheint hier doch zu verlangen, dass das 2.Argument angegeben wird, viell auch nur auf Grund des Vgls, weil so ggf jetzt zuviel vgln wird, was den #ÜBERLAUF!-Fehler verursacht. Es könnte also spezifische Gründe haben, aus denen man nicht unbedingt das von Dir Vermutete schlussfolgern kann. Als 1 ist ein nicht angegebenes Argument 2-4 von INDEX mE noch nie angesehen worden, aus den o.g. Gründen höchstens als 0. Bei einem (Ko-)Vektor ist es dann das n.Element (oder eben alle Elemente), bei einer Matrix müssen es eh immer 2 Indizes sein, wobei einer (oder auch beide) bisher auch 0 sein konnte(n).
Luc :-?

…Werner,
mich mit den Bspp in Deiner AW zu befassen. Eher bin ich leider nicht dazu gekommen, u.a. wg anderer interessanter Themen und diverser Arbeit.
Es ist zwar nicht völlig falsch, was ich bzgl des möglichen Ersatzes des LeerArguments in Deinem 1.INDEX durch 0 geschrieben hatte, aber das passiert ja ohnehin, auch wenn Du das bezweifelst, zwar nur für MatrixFmln, aber das ist auch nicht richtig. Andersherum hätte ich das eher verstanden, obwohl das auch nicht stimmt.
Deine FehlInterpretation des Beobachteten hängt offensichtlich wesentlich damit zusammen, dass Du MatrixFmln, falls überhaupt, nicht für den Zweck benutzt, für den sie mal geschaffen wurden → Ausgabe mehrerer Ergebnisse einer Fml auf einen Streich. Das nenne ich plurale MatrixFmln, andere bezeichnen es als MultiZellen-MatrixFml o.ä. Da ich aber auch eine Sonderform der singularen bzw EinzelZellen-MatrixFml (duale MatrixFml) entdeckt hatte, schien mir die begriffliche 3Teilung unter Namensanleihe bei der Grammatik sinnvoller. Du bemühst Dich zumeist darum, aus pluralen MxFmln singulare oder gar normale Fmln zu machen und missbrauchst dabei leider das 0-Argument, auch, indem Du es nur per gesetztem ; andeutest, also ein leeres (nicht fehlendes!) Argument setzt, was im Falle seiner Optionalität möglich ist, aber dann, je nach Kontext, 2 Bedeutungen hat, die wohl der fml-optimierenden Tätigkeit des Xl-FmlText-Interpreters geschuldet sind:
1. INDEX als Solist in einer normalen Fml → Einsatz der Zeile u/o Spalte des FmlStandorts
2. INDEX als Argument einer zusammenfassenden Fkt (zB SUMME) bzw als Solist einer MatrixFml → Wiedergabe aller Zeilen u/o Spalten des Bereichs bzw des Datenfelds lt Argument1
Da Du INDEX idR nur für normale oder singulare MxFmln nutzt, fällt Dir das nicht auf. Man konnte ja bisher auch nur einen Teil des Ergebnisses einer pluralen MxFml wiedergeben, je nachdem wie groß man den AusgabeBereich wählte. Das wird aber zum Problem, wenn dieser jetzt durch die Interpreter-Änderung automatisch auf seine MaximalGröße expandiert wird. Damit bekommst Du ein Problem, das in Programmen aus unsauberer Pgmmierung resultiert. Hier könnte man es auch unsaubere FmlBildung nennen. Die Quittung ist dann unter Xl365 der #ÜBERLAUF!-, sonst ggf der Standard-Fehler #WERT!.
Ich habe Dein Bsp mal entsprd umgesetzt und dabei flgd Ergebnisse erhalten:
&bullet; Für die NormalFmln → A3:D5: {"Daten"."Werte1".#WERT!.#WERT!;203.203.203.203;"Text_4".204.#WERT!.#WERT!}
&bullet; Für die als singulare „getarnten“ pluralen MxFmln bei entsprd manueller Expansion → E3:F3: {"Daten"."Werte"}
E4:E9: {"Werte";201;202;203;204;205}
E5:F10: {"Daten"."Werte";"Text_1".201;"Text_2".202;"Text_3".203;"Text_4".204;"Text_5".205}
Davon wirst Du natürlich stets nur den 1.Wert erhalten haben, weil mit dem die Wiedergabe beginnt. Das hat Dich dann wohl zu Deiner trügerischen Schlussfolgerung verführt.
Verwendet man Deine NormalFmln aber als Argument von SUMME, ergibt sich flgd Bild:
=SUMME(INDEX(Tabelle1!$A:$B;1;)) → 0
=SUMME(INDEX(Tabelle1!$A:$B;;2)) → 1015
=SUMME(INDEX(Tabelle1!$A:$B;;)) → 1015
Es wdn hier also auch alle Zeilen u/o Spalten benutzt. Noch deutlicher wird es, wenn ich die UDF VJoin (ab der Dir ebenfalls vorliegenden Vs1.5) einsetze, die ich hier auch zur ErgebnisWiedergabe als MxKonstante benutzt habe. Dazu habe ich Dein Bsp um eine weitere WerteSpalte erweitert (Spalte C - Werte2: 10-50). Mit SUMME ergibt das dies:
D3:=SUMME(INDEX($A:$C;2;)) → 211
D4:=SUMME(INDEX($A:$C;;3)) → 150
D5:=SUMME(INDEX($A:$C;;)) → 1165
Mit VJoin statt SUMME ergibt sich so nur für E3 ein Ergebnis:
E3:=VJoin(INDEX($A:$C;2;);;2) → {"Text_1".201.10}
Hier wird nur die Zeile 2 benutzt, deren Spalten ab D leer sind. Das überfordert VJoin noch nicht. Das ist aber bei den beiden anderen Fmln der Fall, die deshalb unter Xl14/2010 nach relativ langer LaufZeit #WERT! ergeben. Ein Zeichen dafür, dass INDEX bis zu meiner Version nicht an den tatsächlich benutzten Bereich angepasst wurde. Gleiches gilt für Xl365 zu vermuten, denn das liefert ja beim Versuch, den GesamtBereich aufzunehmen, #ÜBERLAUF!. Mit einer Einschränkung des Bereichs geht's aber und auch noch im Handumdrehen:
E4:=VJoin(INDEX($A1:$C6;;3);;2) → {"Werte2";10;20;30;40;50}
E5: {=VJoin(INDEX($A1:$C6;;);;2)} → {"Daten"."Werte1"."Werte2";"Text_1".201.10;"Text_2".202.20;"Text_3".203.30;"Text_4".204.40;"Text_5".205.50}
Wahrscheinlich würde es so auch bei Xl365 klappen, aber es ist natürlich besser, auf Leer-/0-Argumente zu verzichten, wenn sie eigentlich nicht benötigt wdn. Folglich ist auch anzunehmen, dass das zellweise Rechnen mit vollen OriginalMatrizen nicht im Sinne der Xl-Pgmmierer ist und zu Performance-Verlusten führen kann (schon gar nicht bei künstlicher Erzeugung singularer aus eigentlich pluralen MxFmln).
Gruß, Luc :-?

Beliebteste Forumthreads (12 Monate)

Arbeitsblatt mit dem Namen 'Tabelle1'
	A	B
1	Daten	Werte
2	Text_1	201
3	Text_2	202
4	Text_3	203
5	Text_4	204
6	Text_5	205

24 Beiträge zum Forumthread Beiträge zu diesem Forumthread

VBA Beispiele zu verwandten Themen

Beliebteste Forumthreads (12 Monate)

Beliebteste Forumthreads (12 Monate)

24
Beiträge zum Forumthread

Beiträge zu diesem Forumthread