Liste abfragen

Beiträge zum Forumthread

Beiträge zu diesem Forumthread

Betreff

Datum

Anwender

…Werner,
meine Re-AW: ;-]
1. soll heißen, dass die Bezeichnung Matrix zur VariantenUnterscheidung unglücklich gewählt ist, denn beide Fktt, INDEX und AGGREGAT können rechteckige Matrizen in Form von ZellBereichen oder Datenfeldern verarbeiten, wobei Letzteres bei AGGREGAT nur für die integrierten Fktt ab Nr14 gilt, obwohl auch die anderen integrierten Fktt das von Hause aus könnten. INDEX kann das aber generell. Beide Fktt können aber auch diskrete, also aus mehreren TeilBereichen zusammengesetzte (Gesamt-)Bereiche verarbeiten (bei AGGREGAT sofern die integrierten Fktt das ebenfalls können). Die Bezeichnung als MatrixVariante kennzeichnet dies also nicht hinreichend und verleitet eher zu falschen Schlussfolgerungen.
Es gibt allerdings auch Arten von Datenfeldern, die keine rechteckige Matrix bilden (in gewisser Weise ein Pendant zu diskreten Bereichen, obwohl hier immer ein gewisser Zusammenhang bestehen muss - entweder der Zeilen oder der Spalten -, bei diesen Bereichen aber nicht) und deshalb nicht oW auf Xl-ZellBereiche abbildbar sind.
2. Dein Argument ist natürlich unbestritten, wobei meine Statements allerdings allgemeinerer Natur waren und meist sind. Jede Fml bildet einen BerechnungsAlgorithmus in Textform ab. Das erkennt man daran, dass die 7-8 ZellEigenschaften, die den wertbezogenen Inhalt einer Zelle abbilden, stets alle einen beliebigen eingegebenen Text anzeigen, wobei die Eigenschaft .Text diesen unter Anwendung der Eigenschaft .NumberFormat anzeigt. Aber nur, wenn dieser Text mit einem = beginnt, wird er auch als Fml betrachtet und vom Fml-Interpreter der Xl-BerechnungsSteuerung behandelt, wobei der auf die 3 Eigenschaften zugreift, die die Fml in Original-US-Notation zeigen. Eine davon wird allerdings nur wirksam, wenn die ZellFml als MatrixFml abgeschlossen wird, eine andere, wenn die ZellAdressen in Z1S1-Schreibweise vorliegen (evtl aber auch generell). Die Bezüge von Namen sind dahingg stets FmlTexte, denen naturgemäß die Eigenschaft .Text fehlt, weil sie ja auch kein .NumberFormat haben. Dafür gibt es 4 der 5 fmlbezogenen Eigenschaften (MatrixFml fehlt, weil hier generell alles berechnet wird) und eine zusätzliche, die bei einfachen (bzw Listen von) Verweisen direkt auf die zugehörigen Objekte referenziert. Liegt so etwas nicht vor, liefert die Abfrage dieser Eigenschaft einen Fehler.
Bei RegelFmln bedingter Formatierung ist das ähnlich, nur noch weiter eingeschränkt. Der Fml-Interpreter arbeitet also in vollem Umfang nur bei ZellFmln, ansonsten mit eingeschränktem WirkungsSpektrum.
Ein FmlText kann ganz simpel aufgebaut sein, zB =A1+A2+A3. Hier gibt es nichts, woran eine MatrixFunktionalität festgemacht wdn könnte, die Auflösung und Berechnung obliegt allein dem Interpreter, der daraus (in polnischer Notation) so etwas wie + wertA1 wertA2 wertA3 machen könnte! Anders sieht es aus, wenn der Name einer Fkt auf bestimmte Weise in den Text eingebunden wurde, zB =SUMME(A1:A3). Hier ruft der Interpreter die (in eine DLL eingebundene) Fkt sum auf und übergibt ihr die Referenz auf den ZellBereich zur Verarbeitung. Das Ergebnis wird an das Interpreter-Pgm rückgeliefert.
Bei komplexeren Fmln kann auch in TeilBerechnungen, die auch bei MehrfachNotation idR nur 1× erfolgen dürften, zergliedert wdn. Dabei können auch ganze AlternativStränge entfallen (vgl WENN). Das meint MS wohl mit FmlOptimierung.
MS hätte auch eine andere Notationsform als die vorliegende, an mathematische FmlNotation angelehnte Darstellung wählen können. Das hätte auch komplexere Algorithmen bei gleichzeitig einfacherer Konstruktion, Darstellung, Nachvollzieh- und Interpretierbarkeit erlaubt, zB +A;A:=A1:A3 (Abarbeitung von rechts nach links). Hierbei hätte stets eine Summe-Fkt angewendet wdn können, nachdem ggf zuvor der Bereich von FehlerWerten bereinigt wurde, die im einfachen Additionsfall naturgemäß eine Summierung verhindern. (An so etwas arbeite ich ggw und komme darauf zu gegebener Zeit zurück.)
3. Um die Richtigkeit ging's mir hierbei primär. Wer .xlsm/b-Dateien generell nicht zulässt, verzichtet auch auf ProzessAutomatisierung, möglicherweise auch auf ganze Projekte und verlangt somit von seinen Mitarbeitern ggf edv-steinzeitliche Handarbeit. Aber das steht hier ja tatsächlich nicht zur Debatte, obwohl man AddIns ja auch zertifizieren (lassen) könnte.
4. Deine Definition von Pionier liegt im Rahmen der Möglichkeiten. Allerdings meint WP dazu, unter einem Pionier … versteht man im Bereich Forschung einen Menschen, der auf einem bestimmten Gebiet eine Vorreiterrolle einnimmt, der etwas Bahnbrechendes geleistet und damit weiteren wissenschaftlichen Arbeiten und Erkenntnissen den Weg geebnet hat. In anderen Anwendungsfällen ist er ein Wegbereiter, was auf Deinen Einsatz für AGGREGAT, den man ja tatsächlich auch, Dir folgend, als Werbung bzw Propaganda (noch dazu für eine bestimmte Einsatzform!) sehen kann, durchaus zutrifft → zwar nicht der Erste auf dem Mars, aber so etwas wie sein Terraformer… ;-]
Demggüber haben professionelle MS-Office-Dozenten ein eher berufliches Interesse daran, stets auf dem neuesten offiziellen Stand zu bleiben, vermitteln aber idR auch nicht mehr als diesen. Ein tieferes Durchdringen solcher Möglichkeiten ist von ihnen eher nicht zu erwarten.
5. Widerstand(/-spruch) ist zwecklos! Wogegen denn auch?! Bei 2 und 6 ging's in Deinem AW-Text für Ilka Maria tatsächlich etwas verquer und das, was Du machst und wofür Du AGGREGAT überhpt in dieser Form verwendest, verlangt ja stets Arg2=6 (von anderen Argument-2-Werten wird hier nur dieser Teil wirksam, alles Andere wird ignoriert)! Und diese bereits vorhandenen (oder ggf während der Argument-3-Berechnung entstehenden) Fehler wdn auch eliminiert, nicht aber solche, die erst nach Abschluss der AGGREGAT-Berechnung als solche sichtbar und wirksam wdn, zB generelles #NV für fehlende Daten, was bei 1zelligen Fmln wohl nur auftritt, wenn Bereichs-/DatenfeldGrenzen überschritten wdn.
Gruß, Luc :-?

Hallo Luc,
... ich wollte und will hier keine "hochwissenschaftliche" Diskussion führen sondern ursprünglich der Bitte von Ilka Maria nachkommen. Gegen einen Meinungsaustausch hab ich natürlich keine Einwände.
zu 1) das die Matrixversion für AGGREGAT() nur für Funktionen ab Nr 14 gilt steht in der MSO-Hilfe. Für meine spez. Einsatz von AGGREGAT() benötige ich fast ausschließlich auch nur die 14 und 15. Ich hab natürlich schon des öfteren in Beiträgen bedauert, dass die Funktonprogrammierer diese Beschränkung derart vorgenommen haben. Doch was hilfst, dies ist Realität und mit dieser gehe ich in meinen Formellösungen um bzw. baue darauf auf.
zu 2.) Dazu hier mal folgendes: Ich hab noch nie einen Beitrag gelesen, der die "Frank-Kabel-Formel" =VERWEIS(2;1/(..."");...) als solche bzw. deren Erklärungen kritisiert hätte bzw. die dort angewendete Methode als "Klimmzug" oder ähnlich kritisiert hätte. Dies übrigens auch nicht bzgl. meiner auf vorgenannter basierenden aber erweiterten: =VERWEIS(9;1/(...)/(...)... - Formeln (mittlerweile sicher auch schon einige Hundert). Auch diese Formelart bezeichne ich als Matrixfunktion(alität)sformel und auch diese nutzen prinzipiell die gleiche "Technologie", wie die die von mir propagierten AGGREGAT()-Formeln, nur das deren Basisfunktion VERWEIS() eben ohne einen zusätzliche "Optionsschalter" die dortigen internen Fehlerwerte ignorieren kann. Und genau die Arbeit mit den "vorsätzlich" erzeugten internen Fehlerwerte ist ja eigentlich bei beiden Formelarten das A und O.
zu 3.) Die Realität ist nun mal widersprüchlich. Es wird meiner Kenntnis nach noch auf ganz anders verzichtet und im Gegensatz dazu anders erlaubt bzw. eingesetzt. Weder Du noch andere werden das ändern können.
4.) Hier dazu nur noch soviel. Ich hatte in meiner Erstaussage "Pionier" in Hochkomma gesetzt. Ich bin kein Wissenschaftler sondern Hobby-Excelformelianer.
5.) Doch, Deinen Aussagen hierzu muss ich besonders widersprechen. Zunächst, ich kann beim besten Willen nicht erkennen, wieso meine Aussagen bzgl. des 2. Arguments "tatsächlich etwas verquer" gewesen wären. Ich widerspreche aber vor allem, dass "stets Arg2=6" notwendig sei. Möglicherweise hast Du übersehen, dass ich hier im thread die AGGREGAT()-Formel von Uwe eingebracht wurden war und ich dessen Originalschreibweise (mit der 2) begründet beibehalten hatte. Nochmal, ich hätte zwar stereotyp die 6 als zweites Arg. in der Formel geschrieben, aber die 2 als zweites Argument war und ist im konkreten Beispiel ausreichend.
So, von meiner Seite würde ich hier auch keine weiteres Ping-Pong-Diskussion mehr wollen, möchte aber nicht den Anschein erwecken, dass ich das letzte Wort haben möchte.
Auf jedenfalls kannst und wirst auch Du mir nicht ausreden, dass ich die spez. AGGREGAT()-Formeln als eine der mächtigsten und vielseitigsten reinen Formellösungsart halte und deren Anwendung auch weiterhin bewerben werde.
Jetzt bedauere ich nur noch, das der threaderöffner (Max) nicht auf meinen ausdrücklichen Warnhinweis (in meinem ersten Beitrag hier im thread) reagiert hat, warum auch immer.
Und unverständlich ist mir vor allem, dass sich Ilka Maria nicht wenigstens noch einmal zu Wort gemeldet hat. Denn Formellösungen, welcher Art auch immer machen mir Spaß, aber Erläuterungen und Erklärungen dazu viel, viel weniger. Weil diese machen meist nur Arbeit, sind echte Zeitfresser und bereiten einen dann mir oft zusätzlichen Aufwand. Und zwar deswegen, weil ich mich dann in nicht immer nützlichen Diskussionen zeitlich verliere. Ich werde mich diesbzgl. künftig mehr beschränken wollen/müssen.
Gruß Werner
.. , - ...

Beliebteste Forumthreads (12 Monate)

	A	B	C	D
1	Vorname	Nachname	Geb	bezahlt
2	Karin	Klang	10.04.2001	ja
3	Karl	Mustermann	12.12.1999	nein
4	Susi	Frust	13.11.1998	ja
5	Martin	Schlau	23.01.2002	nein
6
7
8
9
10	Max	23.01.2002	Martin	Schlau
11	Min	13.11.1998	Susi	Frust
12
13
14
15	Folgende Teilnehmer haben bezahlt
16
17	Vorname	Nachname	Geb	bezahlt
18	Martin	Schlau	23.01.2002	nein
19	Karl	Mustermann	12.12.1999	nein

verwendete Formeln
Zelle	Formel	Bereich	N/A
B10	=MAX(C2:C5)
B11	=MIN(C2:C5)
C10:C11	=INDEX($A$2:$A$5;VERGLEICH($B10;$C$2:$C$5;0))
D10: D11	=INDEX($B$2:$B$5;VERGLEICH($B10;$C$2:$C$5;0))
A18:A19	=WENNFEHLER(INDEX($A$2:$A$5;VERGLEICH($C18;$C$2:$C$5;0));"")
B18:B19	=WENNFEHLER(INDEX($B$2:$B$5;VERGLEICH($C18;$C$2:$C$5;0));"")
C18:C19	=WENNFEHLER(AGGREGAT(14;2;($C$2:$C$5)/($D$2:$D$5="nein");ZEILE(A1));"")
D18: D19	=WENNFEHLER(INDEX($D$2:$D$5;VERGLEICH($C18;$C$2:$C$5;0));"")

23 Beiträge zum Forumthread Beiträge zu diesem Forumthread

VBA Beispiele zu verwandten Themen

Beliebteste Forumthreads (12 Monate)

Beliebteste Forumthreads (12 Monate)

23
Beiträge zum Forumthread

Beiträge zu diesem Forumthread