Live-Forum - Die aktuellen Beiträge
Anzeige
Archiv - Navigation
1488to1492
Aktuelles Verzeichnis
Verzeichnis Index
Übersicht Verzeichnisse
Vorheriger Thread
Rückwärts Blättern
Nächster Thread
Vorwärts blättern
Anzeige
HERBERS
Excel-Forum (Archiv)
20+ Jahre Excel-Kompetenz: Von Anwendern, für Anwender
Inhaltsverzeichnis

Index_Vergleich-Funktion: nicht zsmhängende Matrix

Index_Vergleich-Funktion: nicht zsmhängende Matrix
21.04.2016 10:11:31
Dennis
Hallo zusammen,
ich habe ein kleines Excel-Problem hinsichtlich einer Formel:
Ich habe als Beispiel folgende Tabelle:
Spalte:A...B...C...D...E...F...G
Zeile1:2...5...4...1...6...9...3
Zeile2:g...f...e...d...c...b...a
Nun möchte ich mit quasi "umgekehrtem" WVerweis in Zeile 2 einen Buchstaben suchen und den dazugehörigen Wert aus Zeile 1 dazu angeben.
Das mache ich mit dem Index-Vergleich-Befehl.
Mein Problem ist, dass ich eine nicht zusammenhängende Matrix haben möchte.
Dafür habe ich den Bezügen Namen gegeben.
Suchzeile 2: Bezug: A2;C2;F2 = Name: Test
Ergebniszeile 1: Bezug: A1;C1;F1 = Name: Test2
Meine Formel sieht so aus: =Index(Test2;Vergleich("e";Test;0)) und sollte als Ergebnis die 4 ausspucken...
Nun gibt mir Excel allerdings ein #NAME bzw. beim Vergleich ein #NV aus. Ich denke, dies hängt damit zusammen, dass die Matrix nicht zusammenhängend ist, ich anstelledessen eben die von mir vergebenen Bezüge angegeben habe.
Gibt es eine Möglichkeit, wie ich das umsetzen kann? KÖnnte mir jemand mit einer Formal aushelfen?
Vielen Dank im Voraus und viele Grüße,
Dennis

42
Beiträge zum Forumthread
Beiträge zu diesem Forumthread

Betreff
Datum
Anwender
Anzeige
AW: Index_Vergleich-Funktion: nicht zsmhängende Matrix
21.04.2016 10:46:12
MB12
Hallo Dennis,
deine Vermutung dürfte zutreffen.
Schau mal hier (nur als Beispiel für nicht zusammenhängende Bereiche):
http://www.excelformeln.de/formeln.html?welcher=359
Gruß
Margarete

AW: durch Bedingungsdef.; hier mit AGGREGAT() ...
21.04.2016 12:10:48
...
Hallo Dennis,
... ich würde die geltenden Zellen(-bereiche) oder alternativ die nicht geltenden Zellen(-bereiche) als entsprechende Prüfungsbedingung entweder in die Auswertungsformel einbauen.
Meist kann man das das über geltende/nicht geltende Werte einer vorhandenen anderen Datenzeile/-spalte über eine zusätzlichen Bedingungsdefinition vornehmen oder durch eine entsprechende zusätzliche Hilfszeile/-spalte oder (im Ausnahmefall) auch durch direkte/indirekte Adressprüfungsangaben erfolgen.
In Deinem Fall hab ich nachfolgend letzteres angewendet. Deine Beispieldaten hab ich leicht abgewandelt (gelb hinterlegt) damit auch das von Dir angestrebte nachvollzogen werden kann.
 ABCDEFGH
12541693 
23eedebe 
3        
4e       
54       
6        

Formeln der Tabelle
ZelleFormel
A5=WENNFEHLER(INDEX(1:1;AGGREGAT(15;6;SPALTE(A1:G1)/(A2:G2=A4)/ISTZAHL(VERGLEICH(SPALTE(A1:G1); {1.3.6};)); 1)); "")


Excel Tabellen im Web darstellen >> Excel Jeanie HTML 4
Gruß Werner
.. , - ...
oT. Luc, ich war leider nicht dazu gekommen, mich mit Deinen Hinweisen zur INDEX()-Problematik auseinanderzusetzen. Der thread war schon in der "Versenkung" und ich bin ein miserabler Sucher :-(
Ich hab aber in Zusammenhang mit dieser Fragestellung hier zumindest wieder dran gedacht, dass da meinerseits noch etwas offen war.

Anzeige
Ja, daran hast du gut getan, ...
21.04.2016 14:43:24
Luc:-?
Werner,
nur das natürlich (wg günstigerer AGGREGAT-Alternative) nicht angewendet → vgl unten, dann musst du nicht mehr suchen… ;-)
Hallo, Dennis;
dein Bsp ist nicht wirklich sinnvoll, denn hier würde ja die Fml =INDEX(A1:G1;VERGLEICH("e";A2:G2;0)) völlig ausreichen, da jeder Buchstabe nur 1× in der 2.Zeile vorkommt. Deshalb hat Werner das auch verändert. Ich habe das auch getan, aber nur das f gg ein e getauscht.
In diesem Fall liefert die einfache Fml natürlich ein falsches Ergebnis, Werners das richtige.
Wenn du INDEX auf unzusammenhängende Bereiche anwenden willst, solltest du auch das dafür vorgesehene 4.Argument benutzen! Allerdings ist die Lösung dann oft etwas komplexer, denn sie liefert (hier) entweder ein falsches (in 1zelliger/1wertiger -singularer- MatrixFml) oder gleich 2 richtige Ergebnisse als quasi-1-zellige/-wertige -duale- MatrixFml über 2 Zellen:
{=INDEX((A1;C1;F1);1;1;VERGLEICH("e";INDEX((A2;C2;F2);1;1;SPALTE(A1:C1))&T(SPALTE(A1:C1));0))}
Das fktioniert hier aber nur, weil der unzusammenhängende Bereich aus lauter EinzelZellen besteht, die von INDEX in VERGLEICH zu einem Vektor zusammengestellt wdn, so dass VERGLEICH dann mit der Position in diesem Vektor dem äußeren INDEX dann auch gleich die Nr des TeilBereichs (für das 4.Argument) liefert. 2 Zellen sind erforderlich, damit INDEX alle berechneten Werte verwendet und nicht nur den ersten.
Dies soll dir allerdings bloß zeigen, wie hier eine Lösung nur mit INDEX und VERGLEICH aussehen würde und dich gleichzeitig auf diese 3.Form von MatrixFmln aufmerksam machen, denn es könnte sein, dass es mitunter keine andere Lösung mit StandardFktt gibt.
Feedback nicht unerwünscht! Gruß, Luc :-?
Besser informiert mit …

Anzeige
Alternative ohne Aggregat
21.04.2016 15:16:28
WF
Hi,
{=WENNFEHLER(INDEX(1:1;VERGLEICH(1;(A2:G2=A4)*SPALTE(A1:G1)^0*{1.0.1.0.0.1.0};0));"")}
WF

Das ist jetzt die kürzeste Fml, ...
21.04.2016 15:30:54
Luc:-?
…Walter,
Werners die Längste, meine ohnehin nur als LehrBsp gedacht, wenn auch nur unwesentlich länger (dafür mit dualem Ergebnis, was wohl als Typ in eurer ganzen Fml-Sammlung nirgends erwähnt wird)… ;-]
Gruß, Luc :-?

mit Deiner Formel erhalte ich #NV ?
21.04.2016 15:43:12
WF
.

Ja, wenn du nur eine Zelle auswählst, ...
21.04.2016 19:29:38
Luc:-?
…Walter;
das ist aber eine duale MatrixFml (weder eine singulare noch eine plurale), die stets 2 Zellen benötigt, um in diesen nur ein richtiges Ergebnis (2×) zurückzugeben. Das hängt mit xl-internen Prozessen zusammen, bei denen (das innere) INDEX 1. davon „überzeugt“ wdn muss, mehrere Werte zu berechnen, und 2. auch noch davon, dabei nicht immer nur den ersten zu verwenden, sondern alle nacheinander. Auf das äußere INDEX wirkt sich das dann gleich mit aus.
Luc :-?

Anzeige
kapier ich nicht
21.04.2016 20:14:48
WF
Hi,
in Deiner Formel kommen 2 Zeilen vor: 1 und 2
Das, was ich auswerte hat auch nur genau diese Zeilen.
?
WF

Ich schon, ...
21.04.2016 22:18:34
Luc:-?
…Walter: ;-)
A5:B5:{=INDEX((A1;C1;F1);1;1;VERGLEICH("e";INDEX((A2;C2;F2);1;1;SPALTE(A1:C1))&T(SPALTE(A1:C1));0))}
Analyse:
• INDEX((A2;C2;F2);1;1;SPALTE(A1:C1))
→ Arg1: unzusammenhgder Bereich aus 3 Zellen
→ Arg2: Zeile jeder dieser Zellen
→ Arg3: Spalte jeder dieser Zellen
→ Arg4: 3 Bereichsnrn aus SPALTE(A1:C1), weil Arg1 3 Bereiche enthält
• &T(SPALTE(A1:C1))
→ muss damit verbunden wdn, um die 3malige Wiederholung der TeilFml zu erreichen
→ das ergibt 3× LeerText "", verändert also den Text aus den Zellen der Zeile 2 nicht
Hinweis: In einer MatrixFml wird die TeilFml zwar 3× wiederholt, aber nur mit dem 1.Wert; da diese Zelle aber kein e enthält, ergibt das in nur einer ausgewählten Zelle eben #NV; wählt man dagegen 2 Zellen aus, in denen dann die MatrixFml steht, wdn alle 3 Bereiche verwendet.
• VERGLEICH("e";zuvor_ermittelte_bereiche;0)
→ Arg2: hier muss zwingend das INDEX-Konstrukt verwendet wdn, weil nur so ein von VERGLEICH verlangter, zusammen­hängen­der Ergebnis­Vektor entsteht: hier {"g"."e"."b"}
• INDEX((A1;C1;F1);1;1;bereichsnr_aus_vergleichsergebnis)
→ Arg1…3: analog oben
→ Arg4: Ergebnis der inneren Berechnung als Bereichsnr
Folglich benötigt eigentlich nur das innere INDEX diese Form → MatrixFml über 2 Zellen. Dadurch erhält dann das äußere INDEX den allein noch benötigten Argument-4-Wert, um die richtige Zelle aus dem unzusammen­hängenden Bereich lt seinem Arg1 auszu­wäh­len. Da aber 2 Zellen ausgewählt wurden (übrigens egal, ob unter- oder neben­einander), wird er verdoppelt. Das ist eine lästige „Angewohnheit“ mehrzelliger MatrixFmln, wenn sie nur einen Wert ermitteln können. Sind es wenigstens 2, wdn überzählige Aus­wahl­Zellen mit #NV versehen.
Man könnte den 2.Wert ja nun auch unterdrücken …
A5:B5:{=WENN(SPALTE()=1;INDEX((A1;C1;F1);1;1;VERGLEICH("e";INDEX((A2;C2;F2);1;1;SPALTE(A1:C1))&T(SPALTE(A1:C1));0));"")}
…aber das bringt nicht viel, weil die Fml immer noch 2 Zellen beansprucht. Da müsste man eine Tabelle schon sehr geschickt gestal­ten, wenn so etwas mitten drin verwendet wird. Anderenfalls könnte man aber auch pinsel­formatierte Verbund­Zellen einset­zen, eine sinnvolle Anwendungs­möglichkeit derselben, die ich schon seit Jahren erwähne und dem Ausblenden ganzer Zeilen/Spalten vorziehe. Will man dabei evtlle Summations­Probleme vermeiden, kann man ja die Variante mit leerem 2.Wert verwenden.
Gruß, Luc :-?

Anzeige
ist mir zu viel Text
22.04.2016 06:24:02
WF
Hi,
der Frager hatte eine kleine, übersichtliche Frage gestellt.
Neopa's und meine Formel funktioniert - Deine ergibt #NV.
siehe:
https://www.herber.de/bbs/user/105138.xlsx
Dem Frager ist nicht mit einer theoretischen Abhandlung darüber geholfen, dass irgendwelche Voraussetzungen erfüllt sein müssen. Er will ein Ergebnis haben - und Dein Ergebnis ist #NV.
WF
Als Reaktion bitte keine seitenlange Abhandlung (lese ich nicht) sondern einen Zweizeiler oder besser: eine reparierte Formel.

Wer nicht lesen will, hat schon verloren!
22.04.2016 12:56:04
Luc:-?
Ich hatte dem Fragesteller nur zeigen wollen, wie das mit den von ihm verwendeten Fktt fktionieren würde, Walter!
Und meine Fml ergibt eben nur dann #NV, wenn die von mir und nicht von dir und deinen Mitautoren entdeckte spezielle Art von MatrixFmln nicht angewendet wird!
Dein Lese- und LernUnwillen mag ja deiner rheinischen Mentalität oder persönlichen Eigenschaften geschuldet sein, aber ich hatte von Anfang an geschrieben, was getan wdn muss. Wenn du dich nicht daran halten willst, ist das dein Problem, nicht meines! Wenn die Leser eurer Bücher mehrheitlich auch so denken würden, hättet ihr, zumindest mit dem ersten, wohl nicht DEN Verkaufserfolg gehabt! ;->
Dadurch, dass du diese Art von MxFmln ignorierst, ist sie ja nicht nicht existent! So ein Verhalten benennt man wohl (zu Unrecht) nach dem berühmt-berüchtigten Vogel Strauß ! Offensichtlich kennst du dich weniger gut mit MatrixFmln aus als du glaubst. Theorie ist also durchaus nicht unwichtig… ;-]
So wird meine Fml richtig angewendet:
 ABCDEFGHIJ
12541693 4neopa
23eedebe 4WF
3e      44Luc
Den 2.Wert, der der lästigen Xl-Automatik geschuldet ist, kann man (wie in der 2.Fml gezeigt) durch LeerText oder 0 (bzw einen FehlerWert) ersetzen.
Luc :-?
PS: Meine kleine Schwester ist so alt wie du… ;-]

Anzeige
wie sieht denn nun die (funktionierende) Formel
22.04.2016 15:15:26
WF
aus, die in I5 der von mir hochgeladenen Tabelle gehört?
WF
ps: Ich bin kein Rheinländer - ich stamme aus Bremerhaven.

Aha, na dann! ;-) Die Fml sieht immer noch ...
22.04.2016 15:52:41
Luc:-?
…genauso aus, Walter,
ich habe nur 2 Zellen ausgewählt, was am Ergebnis doch zu sehen ist. ;-)
Luc :-?

warum postest Du die Formel nicht ?
22.04.2016 16:05:44
WF
Ich möchte sie hier kopieren.
WF

Glaubst du mir nicht?! Ich habe deine Tabelle ...
22.04.2016 16:42:29
Luc:-?
…mit den von dir eingetragenen Fmln, nur richtig, benutzt, Walter:
 ABCDEFGHIJKLMNOP
12541693 4neopaI1:=WENNFEHLER(INDEX(1:1;AGGREGAT(15;6;SPALTE(A1:G1)/(A2:G2=A3)/ISTZAHL(VERGLEICH(SPALTE(A1:G1); {1.3.6};)); 1)); "")
23eedebe 4WFI2: {=WENNFEHLER(INDEX(1:1;VERGLEICH(1;(A2:G2=A3)*SPALTE(A1:G1)^0*{1.0.1.0.0.1.0};0));"")}
3e      44Luc 1H3:I3: {=INDEX((A1;C1;F1);1;1;VERGLEICH("e";INDEX((A2;C2;F2);1;1;SPALTE(A1:C1))&T(SPALTE(A1:C1));0))}
4       4 Luc 2H4:I4: {=WENN(SPALTE(A1:B1)=1;INDEX((A1;C1;F1);1;1;VERGLEICH("e";INDEX((A2;C2;F2);1;1;SPALTE(A1:C1))&T(SPALTE(A1:C1));0));"")}
5        #NVFALSCHI5: {=INDEX((A1;C1;F1);1;1;VERGLEICH("e";INDEX((A2;C2;F2);1;1;SPALTE(A1:C1))&T(SPALTE(A1:C1));0))}

Luc :-?

Anzeige
Ich wüsste jetzt aber nicht, was die Lösung ...
23.04.2016 18:31:27
Luc:-?
…eines Gleichungssystems mit einem eher simplen Effekt aus dem Zusammenspiel einer INDEX-Fml auf einen unzusammen­hän­gen­den Bereich mit der Xl-Berechnungs­Steuerung zu tun haben sollte, Walter;
H3:I3 und H4:I4 zeigen eindeutig, neben den {} in der Fml-Dar­stellung, dass es sich hier­bei um eine Matrix­Fml über 2 Zellen han­delt. Erst dadurch kann die Fml den einen rich­tigen Wert ermit­teln, der dann auf Grund der Auswahl 2er Zellen in beiden (H3:I3) gezeigt wird, wenn man das nicht beim 2.Wert verhindert (H4:I4). Im Falle der Auswahl nur einer Zelle (I5) wird die Fml nur den 1.Wert aus dem Bereich verwenden, was dann zum falschen Ergebnis #NV führt.
Gruß, Luc :-?
PS: War einen Tag abwesend.

Anzeige
nix INDEX
24.04.2016 09:21:40
WF
mir ging es nur um diese Aussage:
"Nochmal: NICHT die Formel KOPIEREN; - sondern 9 Zellen markieren und dann die Formel eingeben !"
WF

Versteh' ich nun nicht, ...
24.04.2016 20:11:25
Luc:-?
…Walter;
ist das ein Zitat? Von mir jedenfalls nicht! Ich habe stets nur von 2 Zellen geschrieben, aber auf eurer Seite steht so etwas. Aber das hat doch gar nichts mit dem hiesigen Problem zu tun! Eine plurale (mehrzellige) MatrixFml über mehrere Zellen ist doch ganz normal! Was ich hier beschreibe, ist etwas ganz anderes → der 3.Typ neben diesem und singularen (1zelligen) MatrixFmln → dual! Und der kommt bei euch eben nicht vor, jedenfalls nicht im verlinkten Bsp!
Hättest du meine Erläuterung gelesen, würdest du auch wissen, wovon ich schreibe. So reden wir nur aneinander vorbei. Unten bei Werner hatte ich noch mal eine GrobEinteilung der entsprd gekennzeichneten Matrix-ZellFmln eingestellt.
Luc :-?

Anzeige
AW: es geht nicht um die Kürze der Formel ...
21.04.2016 15:54:20
...
Hallo Luc,
... wenn es darum ginge, könnte ich meinen Formelansatz (für das Beispiel!) kürzer halten (und ohne {})
=WENNFEHLER(INDEX(1:1;AGGREGAT(15;6;SPALTE(1:1)/(2:2=A4)/{1.0.1.0.0.1.0};1));"")
Aber diese "direkte" ("Adressierungs"-Methode) ist wohl nur in bestimmten Fällen vertretbar. Ich würde allgemein gesehen schon lieber (wie bereits in meinem ersten Beitrag geschrieben) z.B. mit einer Hilfszeile arbeiten, wenn die Bedingung für die diskontinuierlichen Geltungsbereichs nicht anderweitig aus dem Datensatz "abgreifbar" ist.
Gruß Werner
.. , - ...

Aggregat soll ja eben vermieden werden
21.04.2016 16:04:08
WF
und komplette Zeilen 1:1 (außer beim INDEX) killen Performance.
WF

Anzeige
AW: Dein Ziel, meins ist das Gegenteil ...
21.04.2016 17:29:16
...
Hallo WF,
... AGGREGAT()-Formeln haben bzgl. der Performance den "echten" Matrixformeln vergleichbar genau so "die Nase vorn", wie z.B. die SUMMENPRODUKT()-Formeln den {SUMME()}-Formeln. Und SUMMEWENNs()-Formeln sind nochmal mal schneller als SUMMENPRODUKT()-Formeln in der Auswertung. Nur haben SUMMEWENNs()-Formeln eben eingeschränktere Anwendungsmöglichkeiten gegenüber SUMMENPRODUKT()-Formeln und diese wiederum gegenüber {SUMME(WENN())}-Formeln.
Ja, auch AGGREGAT() hat eingeschränkte Nutzungsmöglichkeiten gegenüber den ganz allgemeinen {}- Formeln. Aber die Einschränkungen halten sich in sehr engeren Grenzen. Die Vorteile dagegen tun sich nicht nur mir zunehmend auf.
Überall wo die Einsatzgrenzen von AGGREGAT() nicht erreicht werden, werde ich nicht ruhen den spez. Einsatz von AGGREGAT() zu empfehlen. Das genauso wie ich jahrelang dafür geworben habe, dass die meisten INDIREKT()-Formeln durch INDEX()-Formeln zu ersetzen sind.
Was hast Du wirklich sachlich gegen die die AGGREGAT()-Formeln einzuwenden, dass sie vermieden werden sollen? Deine Argumente dafür habe ich noch nicht gelesen. Die AGGREGAT()- Funktion(sgruppe) ist zwar seitens der Programmierung mE nicht ganz fehlerlos geblieben (welche komplexere Funktion ist das schon?) Doch die bisher festgestellten Mängel werden nur die allerwenigsten wissen bzw. überhaupt bemerken.
AGGREGAT() kann auch noch nicht alles das, was ich mir wünsche, aber ich bin überzeugt, sie wird trotzdem viele {}-Formeln nach und nach verdrängen.
Gruß Werner
.. , - ...

AW: Dein Ziel, meins ist das Gegenteil ...
21.04.2016 18:01:08
Daniel
Hi
das mit Summe und Summenprodukt kann ich so nicht bestätigen.
=SUMMENPRODUKT(($A$1:$A$100000="B")*$B$1:$B$100000) braucht bei mir c.a. 20% mehr Rechenzeit als
{=SUMME(($A$1:$A$100000="B")*$B$1:$B$100000)}
beim hochkopieren dieser Formeln auf 1000 Zeilen gibt's bei mir folgende Rechenzeiten:
{Summe}: 5,7 sec
Summenprodukt: 6,9 sec
SummeWenn: 3,8 sec
Gruß Daniel

Genau, weil die Matrix-{} ja auch gar nicht ...
21.04.2016 18:48:42
Luc:-?
…das Problem sind, Daniel & all;
sie sind doch nur eine Anweisung an Xl, wie die Fml zu behandeln ist. Meistens beeinflusst das nur die Wiedergabe (berechnet wird oft alles), bei komplexeren Fmln auch die Berechnung (zB bei dualen MatrixFmln).
Was SUMMENPRODUKT betrifft, wird hier sicher auch die Argument(e)Form eine Rolle spielen. Wird's klassisch eingesetzt, wdn alle Matrizen elementweise miteinander multipliziert und zum Schluss oder kumulierend die entstandene Matrix summiert. Wird aber schon eine MultiplikationsFml als zB nur ein Argument angegeben, erfolgt die elementweise Multiplikation extern (in Xl) und die fertige Produkte-Matrix wird der Fkt übergeben, wobei die dann nur noch summieren muss, was bei kumulativer Addition uU eine überflüssige Multiplikation mit 1 bedeuten könnte, falls die Multiplikation dann nicht ganz entfällt. Unter diesen Umständen verwundert es nicht, wenn eine gleichartige SUMME-MatrixFml schneller ist. Beide Fktt berechnen(/beziehen dann) ohnehin stets alles (ein).
Gruß, Luc :-?

AW: das kann zutreffend sein ...
21.04.2016 20:03:49
...
Hallo Luc,
... doch ich habe bzgl. der Performance der SUMMENPRODUKT()-Formel im Vergleich zur {}-Matrixformel auch schon andere Aussagen in Erinnerung. Möglicherweise war da bei der {}-Formel noch ein WENN() mit im Spiel.
Gruß Werner
.. , - ...

Wahrscheinlich, denn das verursacht zusätzl ...
21.04.2016 20:56:53
Luc:-?
…RechenAufwand, Werner;
außerdem berechnet SUMMENPRODUKT, je nachdem wie die Fml aufgebaut ist, uU mehr als nötig ist. Man kann also keine allgemeingültige Aussage zur Performance-Problematik treffen.
Luc :-?

Aggregat finde ich bescheuert
21.04.2016 18:06:23
WF
Hi,
es gibt die Funktion AGGREGAT(5;….. - das ist MIN
die ist unbrauchbar. Stattdessen nimmt man
die Funktion AGGREGAT(15;…..;1) - das ist KKLEINSTE(…..;1)
Was für ein Schwachsinn
Damit es dann funktioniert muss man durch Divisionen erst Fehlerwerte erzeugen, die man in der gleichen Formel mit der Option 6 wieder eliminiert.
Ich bin ein Anhänger von Logik.
Ich vermute, der Aggregatentwickler bei Microsoft ist, bevor er fertig war, abgehauen.
WF
Aggregat ist das bessere Teilergebnis - mehr nicht.
Funktioniert allerdings auch nicht mit obigen Berechnungen.

Tja, 'besseres TEILERGEBNIS' ist schon richtig, …
21.04.2016 19:20:32
Luc:-?
…Walter,
nur wird der Pgmmierer nicht „abgehauen“ sein, sondern es waren entweder 2, wobei der 2. den Rahmen für die Fktt ab Argument1-Nr 14 festgelegt und sich dabei nicht an die Gesamt­Konvention gehalten hat, oder MS hatte damit ursprünglich noch anderes vor (in älteren Xl-Hilfe-Versionen soll etwas von Bedingt­Formatierung gestanden haben, in meiner Xl14/2010-AGGREGAT-Hilfe finde ich aber nichts dazu!). Daraus resultiert dann die zu beobachtende Einsatz­Logik­Verletzung.
Auch, wenn einige Features, die mit Arg2 verbunden sind, nur auf ZellBereiche als Arg3ff anwendbar sind, heißt das nicht, dass man die ganze RahmenFkt auch so einschränkend hätte pgmmieren müssen, was ich mit meiner UDF AggregateXk ja bewiesen hatte. Letztendlich ruft AGGREGAT nach Vorbehandlung (lt Arg2) der übergebenen ZellBereiche ja nur die mit Arg1 verlangte XlFkt auf und die können alle auch mit Datenfeldern (aus Ausdrücken inkl der Ergebnisse als Argument übergebener Fmln) umgehen. Man hätte bei Übergabe eines Datenfeldes ja nur die entsprd Features ignorieren müssen, falls angegeben! Insofern ist AGGREGAT wahrlich kein Meilenstein der Pgmmierung; anders als TEILERGEBNIS (das an der gleichen Pgmmierer­Bequemlichkeit krankt) aber eher eine Mogel­Packung, denn wg der Zulässigkeit von Datenfeldern ab Arg1=14 entfällt die entsprd Eingabe­Warnung gleich ganz.
Gruß, Luc :-?

AW: mE nur teilweise (s.u) owT
21.04.2016 19:52:00
...
Gruß Werner
.. , - ...

'Besseres' muss nicht qualitativ gemeint sein! ;-)
21.04.2016 22:24:13
Luc:-?
Gruß, Luc :-?

AW: sachlich gesehen sieht es anders aus ...
21.04.2016 19:49:50
...
Hallo,
... AGGREGAT() ist wohl möglicherweise oder wahrscheinlich als Erweiterungsfunktionalität bzw. zur späteren Ablösung für TEILERGEBNIS() unter Berücksichtigung von Fehlerwerten angelegt.
Dabei ist offensichtlich vieles nicht so realisiert, wie es vielleicht geplant war. Bestimmte maßgebliche TEILERGEBNIS()-Funktionalitäten sind sogar unverständlicherweise (z.B. bei Anwendung der Matrixversion) unverständlicherweise ganz unter den Tisch gefallen. Wer fehlerfrei ist, mag den ersten Stein (auf die Programmierer) werfen. Ich bin es jedenfalls nicht.
Andererseits haben sich zumindest Einigen "Excelformelianer" neue Möglichkeiten offenbart, die so bestimmt seitens der Programmiere nicht geplant waren. Und genau da knüpfe ich an und sehe darin den momentanen Hauptnutzeffekt der Funktionsgruppe.
Deine Aussage: "AGGREGAT(5;….. - das ist MIN die ist unbrauchbar" ist falsch. Diese Teilfunktion 5 kann wie alle Funktionen unterhalb der Funktionsnummer 14 eben nur nicht in der Matrixversion verwendet werden (leider). Aber sie ist wie alle anderen natürlich nutzbar, nur eben berechtigt uninteressant für die, die schon lange Excel anwenden.
Den Hauptnutzen von AGGREGAT() sehe ich im Wesentlichen in den matrixversionfähigen Funktionen 14 und 15. Deren spez. Anwendung mag zwar anfangs zunächst etwas ungewohnt sein, aber sie ist keinesfalls unlogisch und auch nicht unpraktisch. Das Schema der entsprechenden Formelkonstruktion ist im Prinzip immer gleich und allein dadurch ist sie mE einfacher an Unvoreingenommene zu vermitteln.
Und Dein Argument bzgl. das es unlogisch sei, erst Fehlerwerte zu erzeugen, widerspricht dagegen anderen Grundregeln. Übrigens wird die gleiche "Logik" z.B. in Excel seit vielen Jahren u.a. bei den =VERWEIS(2/(...);...) eingesetzt. Hast Du die kritisiert? Nein, denn da gibt es genauso wenig zu kritisieren.
Ich schreib nicht, dass Du die AGGREGAT()-Formeln einsetzen oder gar propagieren sollst, aber es wäre schön, wenn reine Polemik außen vor bleibt.
Zum Abschluss noch ein Vergleich, auch wenn Vergleiche immer hinken.
Viele Menschen kaufen heutzutage ihre Back- und Wurstwaren im Supermarkt und nicht beim Bäcker oder Fleischer um die Ecke und das mit allen Vor- und Nachteilen für alle Beteiligte. Und, auch im Supermarkt bekommt man nicht alles und vor allem nicht so, wie sich es ein Jeder es sich (anders) wünscht.
Gruß Werner
.. , - ...

das steht aber nicht in der Online-Hilfe
21.04.2016 20:06:21
WF
es gibt ca. 2 Mio (?) Excelanwender in Deutschland.
Wieviele haben Deine Ergüsse betr. Aggregat gelesen: 10 - 20 - 50 ?
Und bei =VERWEIS(2/(...);...) ist keine Option nötig, die Fehlerwerte eliminiert.

Mit 'Matrixversion' meinst du offensichtlich ...
21.04.2016 21:08:26
Luc:-?
…die Anwendbarkeit von Datenfeldern (aus Ausdrücken - MatrixKonstanten bzw Ergebnisse von TeilFmln) als Argument3ff, Werner;
der Begriff Matrix ist hierbei missverständlich, denn er kann, analog dem engl Array im Ggsatz zu Range und Data Array, sowohl einen ZellBereich als auch ein Datenfeld bezeichnen. Das ist auch genau der Grund, warum ich euch anfänglich (in Ermangelung von Xl14/2010) nicht verstanden hatte.
Luc :-?

AW: die Begrifflichkeit steht in der MSO-Hilfe ...
22.04.2016 08:55:11
...
Hallo Luc,
... in der wird in meiner Excel 2010er Version zwischen der Bezugs- und Matrixversion unterschieden.
Musste jedoch eben feststellen, dass in der aktuellen Online-Hilfe anstelle Matrixversion da "Arrayversion" geschrieben steht. Ich bin mir aber zu 100% sicher, dass in meiner 2010er Version die ich auf einem andern PC nutze "Matrixversion" stand/steht (habe aber momentan auf diesen PC keinen Zugriff) und da evtl. in der Offline -Hilfe?! Dort stand/steht auch welche Funktionen von AGGREGAT() (14, 15,...) matrixversionsfähig sind und welche nicht.
In der Onlinehilfe steht das wirklich nicht. Warum auch immer. Möglicherweise meint das auch WF, wenn er schreibt, dass dies nicht in der Hilfe stünde.
Ein Blick in die MSO-Onlinehilfe von VERWEIS() zeigt mir, dass dort übrigens im Gegensatz zur AGGREGAT()-Funktion-Online-Hilfe von einer MATRIXversion die Rede ist und das genauso bei der Funktion INDEX().
Also kann man unser Verständigungsproblem auch teils den deutschsprachigen Übersetzern zuordnen. Oder?
Gruß Werner
.. , - ...

Ja, Letzteres glaube ich auch, denn die waren ...
22.04.2016 13:00:26
Luc:-?
…offensichtlich keine Muttersprachler, Werner,
sonst wäre SumProduct nicht mit SUMMENPRODUKT übersetzt worden, was definitiv falsch ist. Deutsche Mathematiker nennen das ProduktSumme.
Luc :-?

AW: deutsche 2010er-OFFline-Hilfe zu AGGREGAT()...
23.04.2016 17:34:06
...
Hallo Luc,
... habe ich mir eben noch mal angeschaut.
Dort steht, wie gestern von schon geschrieben "Matrixversion" nicht "Arrayversion" wie in der Onlinehilfe.
Weiter findet sich in der Offline-Hilfe im Gegensatz zur Onlinehilfe dazu u.a. auch nachfolgende Aussage:
"Für Funktionen, die mit einer Matrix arbeiten, ist Bezug1 eine Matrix, eine Matrixformel oder ein Bezug auf einen Zellbereich, für die/den Sie den Aggregatwert berechnen möchten:
Funktion
KGRÖSSTE(Matrix,k)
KKLEINSTE(Matrix,k)
QUANTIL.INKL(Matrix,k)
QUARTILE.INKL(Matrix,Quartil)
QUANTIL.EXKL(Matrix,k)
QUARTILE.EXKL(Matrix,Quartil)

Deine Feststellung zu SUMMENPRODUKT() teile ich auch, auch wenn ich kein Mathematiker bin.
Zumindest unglücklich finde ich auch die deutsche Funktionsbezeichnung BEREICH.VERSCHIEBEN()
Aber man gewöhnt sich halt an so manches ;-)
Gruß Werner
.. , - ...

Ja, das ist schon 'ne Begriffsverwirrnis, ...
24.04.2016 03:53:19
Luc:-?
…Werner;
auch darin ist MS schlampiger geworden…
Matrix und Array sind allgemeine Begriffe, die nur Aussagen über die Anordnung von Daten treffen lassen, was in Mathe ausreicht, aber nicht in Xl. Hier muss noch die unmittelbare Herkunft festgestellt wdn und damit sind die o.g. Begriffe nicht das Pendant zu ZellBereich, aber das hatte ich ja schon mit eindeutigeren Begriffen versehen, zumal es sonst zu Missverständnissen in bezug auf MatrixFmlForm und deiner hierbei eher zutreffenden bzw präziseren MatrixFktionalität kommen kann.
Aber noch mal zum anderen, von WF lange nicht verstandenen (ob jetzt ist fraglich!) Problem. Inzwischen habe ich mich zu einer 3Teilung der Arten (in Analogie zur Grammatik natürlicher indo­europäischer Sprachen) von auch als solche in ZellFmln kenntlichen MatrixFmln entschlossen (an dieser Stelle, weil WF ja nach eigenem Bekunden längere, zumal theoretische Texte nicht liest, und ich mir das dort dann sparen kann):
MxFml-TypenErgebnis (-Ausprägung/-Standort)
• singular → 1 Wert in 1 FmlZelle
• dual → 1 Wert in mindestens 2 FmlZellen beliebiger Ausrichtung (anderenfalls FalschErgebnis)
• plural → n Werte in n FmlZellen einer n=s×z ZellBereichsMatrix (entsprd Ausrichtung)
Damit dürften dann alle auftretenden Möglichkeiten formal einordenbar sein.
Morrn, Luc :-?

AW: Matrixformel-"Typenklassifikation" ...
24.04.2016 10:33:46
...
Hallo Luc,
... zu Deiner hier dargestellte Typisierung wäre meinerseits anzumerken:
Die "singularen" Matrixformeln sind bzgl. Anwendungsverbreitung, -Häufigkeit und -Vielfalt wohl dominant . Die "pluralen" Matrixformeln sind dagegen mE schon eingeschränkter aber durchaus gebräuchlich. Über deren Handhabung haben wir teils geteilte Meinung (ohne hier wieder darauf einzugehen).
Die spez. "dualen" INDEX()-Matrixformeln sind für mich schon interessant. Aber ich erkenne momentan (noch?) nicht, dass diese mehr als ein absolutes seltenes Dasein fristen werden. Außer von Dir, werden -wenn überhaupt- wohl ganz wenige diese anwenden, denn deren Erfordernis ist als solche mE schon selten und dann gibt es dazu meist gute oder gar bessere alternativen Formellösungsmöglichkeiten.
Ob die sehr große Gruppe der "Matrixfunktion(alität)sformeln" in die "singularen" Matrixformeln unter gruppiert oder diese als ein evtl. eigener Typ bezeichnet werden, sei jetzt einfach ohne diesbzgl. neuerliche Diskussion zwischen uns dahingestellt.
Gruß Werner
.. , - ...

Ja, dual ist sicher sehr selten wirklich ...
24.04.2016 16:13:32
Luc:-?
…notwendig, Werner,
obwohl ich mitunter schon solche Fälle hatte, aber immerhin eine Möglichkeit, die außerdem dieses (NoNetsche) INDEX-Phänomen erklärt.
Unsere Sprachen enthalten ja inzwischen meist auch nur noch Singular und Plural, den alten Dual höchstens noch in Resten. Aber so war das mal - die heilige 3-Zahl: 3 (ursprüngl) Zeiten, 3 (grammatische) Geschlechter, 3 AnzahlTypen - und alles auch in Kombi­nation. Das sich so etwas nun auch in der Berech­nungs­Steuerung von Xl verbirgt, entbehrt nicht eines gewissen Witzes, viell gar Hintersinns.
Die von dir Matrixfunktion(alität)sformeln genannten Fmln möchte ich hier nicht einordnen, denn deren Besonder­heiten ergeben sich aus der autarken Pgm­mierung beteiligter Fktt, die nicht auf gewisse Hilfe­Stel­lungen der allge­meinen Pgmmierung der Xl-Be­rech­nungs­Steuerung angewiesen sind. Dadurch „überspringen“ die sie enthal­tenen Fmln quasi bestimmte Daten­Bereit­stel­lungs­Stufen, die sonst erst durch die Matrix­Fml­Form ausgelöst würden. Das es so etwas überhaupt gibt, mag dem über Jahre hinweg entstan­denen „Gesicht“ des heutigen Xl geschuldet sein. Nicht jeder Pgmmierer wird sich die Mühe gemacht haben, die Routinen der Xl-Steuerung voll zu nutzen. Das mache ich idR auch nicht — abgesehen mal davon, dass ich das mangels (von MS geheim­gehaltener) Schnitt­stellen­Kenntnis auch gar nicht könnte —, wenn ich eine UDF schreibe.
Mit der Entdeckung der dualen MatrixFmln wissen wir jetzt aber auch, dass die Xl-Berech­nungs­Steuerung offen­sichtlich mehr­stufig agiert, weshalb ich früher auch den Begriff der Stufig­keit mit­ver­wendet hatte. Mitunter müssen also gleich 2 Voraus­setzungen erfüllt sein, damit man per MatrixFml zu einem richtigen Ergebnis kommt.
Übrigens, die pluralen MatrixFmln müssten gar nicht so selten sein, denn ihre Verwendung ist idR rationeller und meist schneller als 100× die gleiche Matrix zu berechnen, nur um dann nur einen einzigen (anderen) Wert pro FmlStandort­Zelle auszuwählen. Rational ist anders, weshalb das die Ausnahme aus besonderem Anlass bleiben sollte! Eigentlich sollten die singularen MatrixFmln in der Minderheit ggüber den pluralen sein, aber dafür versuchst du ja schon zu sorgen (mit AGGREGAT)… ;-)
SchöSoNamit, Luc :-?

AW: Das ist jetzt die kürzeste Fml, ...
22.04.2016 08:51:18
Dennis
Guten Morgen zusammen,
ich hatte leider gestern keine Zeit mehr, hier zu antworten, daher nun leicht verspätet.
Ich habe mich nun an die Lösung von WF gehalten und zusammen mit Kollegen das so "ummodelliert", dass es zu meiner Anwendung passt - vielen Dank für die guten Hinweise/Tipps/Denkanstöße.
Dazu freut mich sehr, dass ich wieder was gelernt habe - außerdem, dass mein präsentiertes Beispiel tatsächlich etwas unglücklich gewählt wurde, entschuldigt mich dafür.
Die nachfolgende "Diskussion" bzw. eure Ausführungen habe ich dann leider zum Teil nicht mehr ganz verstanden, das war mir dann zu viel Excel auf einmal :-)
Ich danke euch und wünsche schonmal jetzt ein schönes Wochenende.
Viele Grüße,
Dennis

Vereinfachung
22.04.2016 22:04:52
WF
Hi,
SPALTE(...)^0 ist ja vollkommen überflüssig.
statt:
{=WENNFEHLER(INDEX(1:1;VERGLEICH(1;(A2:G2=A4)*SPALTE(A1:G1)^0*{1.0.1.0.0.1.0};0));"")}
langt:
{=WENNFEHLER(INDEX(1:1;VERGLEICH(1;(A2:G2=A4)*{1.0.1.0.0.1.0};0));"")}
WF

...Allerdings wird sie durch die MxKonstante ...
21.04.2016 15:41:04
Luc:-?
…recht statisch!
Luc :-?

126 Forumthreads zu ähnlichen Themen

Anzeige
Anzeige
Anzeige

Beliebteste Forumthreads (12 Monate)

Anzeige

Beliebteste Forumthreads (12 Monate)

Anzeige
Anzeige
Anzeige