Herbers Excel-Forum - das Archiv

Zum WE: Kleiner Exkurs über Container-Fktt

Bild

Betrifft: Zum WE: Kleiner Exkurs über Container-Fktt
von: Luc:-?

Geschrieben am: 16.01.2016 20:08:21

N'Amd, Folks;
das Folgende richtet sich sowohl an VBA-Pgmmierer als auch Xl-Fml-Puristen!

  • Jeder VBAler kennt wohl die Container-Fkt WorksheetFunction, mit der sich viele Xl-Fktt direkt in VBA verwenden lassen. Etliche ziehen allerdings den DirektAufruf mit Application vor, weil der iW so fktt, wie man es auch von Xl gewohnt ist. Aber nicht alle Xl-Fktt lassen sich so verwenden (hier bleibt dann nur eine indirekte Anwendung mit vbFkt Evaluate, was hier aber nicht thematisiert wird), was darauf hindeutet, dass zu jeder dieser Fktt ein Adapter angelegt wurde, mit dem sie aufgerufen wdn. Deshalb wdn sie auch unter Application im ObjektManager des VBE angezeigt. WorksheetFunction hingg ist eine Container-Fkt, die alle diese Aufrufe intern ansteuert, wobei die DatenÜbergabe an die jeweilige Fkt ebenso wie die DatenRückgabe normiert zu sein scheint, d.h., einer Prüfung unterzogen wird. Dadurch können bspw keine FehlerWerte zurückgegeben wdn und die DatenÜbergabe ist ebenfalls auf das von der jeweiligen Fkt Festgelegte beschränkt (das Letztere gilt aber auch für Aufrufe mit Application!). Man darf hierbei nicht vergessen, dass von Xl erweiterte Möglichkeiten beigesteuert wdn, die in VBA naturgemäß fehlen!
    Übrigens unterstützt der VBE-Intellisense nur die Container-Fkt, nicht den FktsAufruf mit Application!

  • In Xl gibt es ebenfalls Container-Fktt Vglbares, nämlich Multipurpose- bzw Verteiler-Fktt wie zB die bekannte Fkt TEILERGEBNIS (SubTotal). Mit dem 1.Argument wird eine der intern ansteuerbaren Fktt angegeben, im 2. und ff Argumenten die eingehenden Daten als Bereichsbezug. Diese Einschränkung (As Range) ist allein dem RahmenPgm der Fkt geschuldet, denn die integrierten Fktt haben auch mit Datenfeldern aus Ausdrücken kein Problem. Ursache dürfte sein, dass diese Fkt allein zur TabellenGestaltung entwickelt wurde, quasi als fml-fktionales Gegenstück zur Teilergebnis-Methode von Xl. Darauf deutet auch die Beschränkung nur auf Berücksichtigung ausgeblendeter Zeilen hin, was einer Datensatz-Struktur (von Listen) entgegenkommt, weniger KreuzTabellen (dafür gibt's Pivot!).
    Kommen wir nun zu einer neuen derartigen Fkt (ab Xl14/2010) → AGGREGAT. Wie „neu“ ist diese wirklich? Nun, Erfahrungen diverser Nutzer und meine eigenen Tests deuten darauf hin, dass sie so neu gar nicht ist! Es scheint sich eher um ein erweitertes TEILERGEBNIS zu handeln, nur hat man hier (mit engl Aggregate) endlich eine angemessenere Bezeichnung gewählt als es SubTotal im Englischen war und ist. Aber das ist ja nicht das Wesentliche.
    Da das alte RahmenPgm von SubTotal anscheinend modular aufgebaut war/ist, hat man offen­sichtlich nur die Fehleingabe-Anzeige entschärft, sowie die Vorfilterung der Daten auf Fehler­Werte, Texte u.a. hinzugefügt und ansonsten ein neues Modul für den Aufruf der zusätzlichen Fktt angelegt, das nun auch Datenfelder zulässt. Nichts­desto­trotz scheint die alte Eingabe­Über­prüfung unverändert geblieben zu sein, so dass die Alt­Bestands­fktt von SubTotal immer noch nur mit Bereichen fktionieren, obwohl das nicht mehr als Fehleingabe kritisiert wird! Allerdings scheint auch dieses neue Modul gewisse Beschränkungen zu kennen, worauf einige bereits früher verschiedentlich thematisierte Seltsamkeiten hindeuten.

  • Fazit: Es scheint sich wieder einmal zu bestätigen, dass MS Änderungen und Erweiterungen, vor allem im Fktsbestand, wenn überhpt, dann mit minimalem Aufwand vornimmt, egal, ob dabei Ungereimtheiten zustande kommen, die wohl kein NormalNutzer je verstehen wird. Statt die vielen „SonderZugänge“ zu altvertrauten Fktt zu schaffen, hätte MS besser alle neueren Fktt so normieren sollen, dass sie endlich zu den alten passen. Für die schnelle Verarbeitung großer Datenmengen nach unterschiedl Kriterien gibt's ja seit eh und je schon die DB…-Fktt.
    Für jeden Entwickler einschlägiger Software, der auch einen Xl-Im-/Export mit Fml-Konvertierung anbieten will, ist das doch eine nahezu grauenvolle Anhäufung von Sonderfällen! Das ist ähnlich wie mit VBA und anderen MS-Entwicklungen, die sich oft durch Sonderwege und NichtEinhaltung festgelegter Konventionen „ausgezeichnet“ haben.

  • Eine evtl Diskussion sei hiermit eröffnet!
    Luc :-?

    Bild

    Betrifft: Weiteres zB hier im Archiv:
    von: Luc:-?
    Geschrieben am: 16.01.2016 20:13:59
    https://www.herber.de/forum/archiv/1464to1468/t1467832.htm#1468950
    Luc :-?

    Bild

    Betrifft: Ergänzung zum 1.Pkt
    von: Luc:-?

    Geschrieben am: 16.01.2016 20:24:08
    Bei WorksheetFunction handelt es sich strenggenommen nicht um eine Container-Funktion wie im 2.Pkt, sondern um ein Container-Objekt, das bestimmte FktsAufrufe/-Zugänge enthält. Damit wäre es per sé eher mit AuflistungsObjekten vglbar. Es hat aber nach außen eine ähnliche Wirkung wie die xlFktt unter Pkt 2.
    Luc :-?

    Bild

    Betrifft: AW: also nun … Du hattest es gewollt …
    von: ... neopa C

    Geschrieben am: 17.01.2016 12:03:12
    Hallo Luc,
    ... und der Beitrag von Luschi als TE sowohl an Dich und mich, entbindet mich von meiner bisher selbst gewählten Zurückhaltung auf den ursprünglichen völlig anderen Inhalt dieses thread, hier nun doch näher auf Deine Aussagen im thread https://www.herber.de/forum/archiv/1464to1468/t1467832.htm#1468950 einzugehen.
    Und dies hier, obwohl Du Gestern Abend nun doch einen neuen thread (hier https://www.herber.de/forum/archiv/1468to1472/t1469329.htm) aufgemacht hast. Dort werde ich deshalb auf nur diesen thread verlinken. Hier musst Du eben noch meine folgenden längeren Ausführungen zur Kenntnis nehmen. Erwiderungen bitte dann nur noch in Deinem thread.
    Vorab, unklar ist und bleibt mir, wie es Dir möglich war am 15.01. Mittags im erst erwähnten thread dort noch einen Ergänzungsbeitrag zu schreiben, obwohl dieser schon am Morgen des 15.01. nicht mehr aktiv war?
    Zunächst, nein, ich ärgerte und ärgere mich nicht über Deine Kritik an AGGRAGAT() und auch nicht der an mir. Das ist ein Jeden gutes Recht. Nur Dein gewählter Stil, also die Art und Weise Deiner „Kritik“ hatte mich veranlasst, Dir am 15.01 im thread kurz angebunden zu erwidern.
    Vielleicht hattest Du in Deinem Beitrag am 14.01. 16 im erwähnten anderen thread ja wirklich nur vergessen, Luschi explizit anzusprechen, als Du Deine spez. Ausführungen zum Einsatz der Funktion AGGREGAT() vorgetragen hast. Das ist aber weder für mich noch für Mitleser erkenntlich. Ich sah Deine Ausführungen vor allem auch im zeitlichen Zusammenhang mit Deinen Aussagen in einem dritten thread (hier: https://www.herber.de/forum/archiv/1464to1468/t1467881.htm ) und früheren Aussagen von Dir mir gegenüber.
    Deine Ausführungen zu AGGREGAT() in https://www.herber.de/forum/archiv/1464to1468/t1467832.htm#1468950 vom 14.01.16, die Du dann hier im thread, in einer Mail an mich und in Deinem neuen thread teils wiederholt hast, zeigen mir nur, dass Du die spez. Wirkungsweise der AGGREGAT()-Funktion im Wesentlichen nur aus Deinem Verständnis heraus betrachtest.
    Du lehnst Ihren Einsatz ab, weil die Funktion nicht komplett und vollkommen programmiert und (nicht nur) Deiner Meinung nach, nicht intuitiv anzuwenden sei. Du kannst offensichtlich nicht verstehen, warum andere Excelnutzer deshalb diese Funktion nutzen und für gut befinden, obwohl diese aus Deiner Sicht doch nur „Stückwerk“ der MS-Programmierer sei. Du meinst u.a., dass man doch alternative bessere Möglichkeiten auf Basis entsprechender Kombinationen klassischer Funktionalitäten hätte oder noch besser auf Basis Deiner UDFs.
    In diesem Zusammenhang erinnere ich mich an ältere Diskussionen, die ich in Spotlight Forum las, als mit Excel2007 die neuen Funktionen SUMMEWENNS() und ZÄHLENWENNS() eingeführt wurden. Wie haben sich dort einige Poweruser teilweise mokiert über die Eingeschränktheit dieser Funktionen und das man diese doch gar nicht oder jedenfalls nicht so bräuchte, weil man anstelle diesen z.B. mit SUMMENPRODUKT() und oder {=SUMME(WENN))} genauso und gar besser arbeiten könnte. Die MS-Programmierer hätten sich doch eher und mehr mit den wirklich Notwendigen beschäftigen sollen, war (und ist?) die Meinung einiger.
    In meiner damals (fortgeschrittenen) Excel-Anfangszeit, hat mich das beeindruckt aber damit auch lange Zeit um dem Vorteil, die diese WENNS-Funktionen für eine Vielzahl von Lösungen mit sich bringen, bringen lassen. Natürlich können diese Funktionen nicht eingeschränkt immer angewendet werden aber sie sind für viele Anwendungsfälle eine gute und vor allem effektive Funktionsergänzung.
    Nun verweise ich beispielsweise noch auf die spez. Einsatzmöglichkeiten der Funktion VERWEIS(). Diese ist ursprünglich seitens der Entwickler für das geschrieben, wie sie auch heute noch in der MS-Hilfe vordergründig beschrieben wird. Aber so verwende ich sie z.B. in meinen Forenbeiträgen wesentlich weniger, als in ihrer Matrixfunktion(aitäts)formelart =VERWEIS(9;1/(…)). Diese spez. Formelart ist zurückzuführen auf die ursprüngliche „Frank Kabel“ Formel. Mit deren grundsätzlichen Wirkungsweise habe ich mich so oft und so ausgiebig in sehr vielen Forenthreads im Spotlight und Online Excel Forum auseinandergesetzt und auch erläutert, dass ich diese nicht nur verinnerlicht hatte, sondern auf Basis dessen an deren „Weiterentwicklung“ (Bedingungskombinationen) zumindest auch einen kleinen Anteil hatte. Deshalb hatte ich mir auch schon seit Jahren erlaubt, eben für diese Formelkombination nicht mehr VERWEIS(2;1/…)) zu schreiben sondern anstelle der 2 die 9 einzusetzen.
    Die mit meinen VERWEIS()-Formeln von mir gesammelten Erkenntnisse kombiniert mit meinen parallel dazu gesammelten Erfahrungen im erweiterten Einsatz der Funktion INDEX(), haben mir dann im vorigen Jahr „Pate gestanden“, als ich begann, mich mit der AGGREGAT()-Funktion etwas näher auseinanderzusetzen.
    Übrigens war es Luschi, der gewissermaßen mich auf die Funktion AGGREGAT() im März 2015 aufmerksam gemacht hat (ich hatte Excel 2010 da noch nicht lange im Einsatz). Er hat die Funktion damals aber noch so gesehen, wie sie vordergründig seitens MS konzipiert und beschrieben ist.
    Die Beschreibung zur Funktion in der MS-Hilfe ist übrigens mE relativ eindeutig, insbesondere was ihre Matrixversionsfähigkeit angeht. So wie ich diese Funktion dann seither jedoch fast ausschließlich nutze, steht in der MS-Hilfe eben nur zwischen den Zeilen.
    Wie ich erst im Nachgang erfahren habe, bin ich natürlich nicht der Erste gewesen, der die Matrixfunktionalität der Funktion als Ersatz bzw. Alternative für andere Matrixformeln eingesetzt habe. Jedoch bin ich nach meiner bisherigen Erkenntnis zumindest hier und in Online Excel-Forum derjenige, der diese spez. Nutzungsart der Funktion wohl am meisten vorangetrieben hat. Ich betrachte sie eben nach wie vor als sehr nützlich.
    Hier im Forum hat sich dem vor allem Sepp „angeschlossen“, wie ich es jedenfalls in vielen seiner Threadsantworten vorgefunden habe. In OE auch noch Sepp Burch und Detlef (shift del). In anderen Foren bin ich nicht bzw. schon lange nicht mehr aktiv. Doch die von mir hier Genannten werden genauso wenig wie ich, AGGREGAT() nur der Funktion willen zum Einsatz bringen. Sondern sie haben und werden sie hauptsächlich nur dann einsetzen, wo es Sinn macht un nützlich ist. In dem diskussionsauslösenden thread machte dessen Einsatz für mich jedoch absolut keinen Sinn. Meine dort eingebrachte Matrixfunktion(altät)sformel auf Basis der Funktionskombination von u.a. FINDEN() und SUMMENPRODUKT() ist und war ausreichend gut als Lösung. Mit AGGREGAT() wäre das nur mit unvertretbaren Zusatzaufwand zu lösen gewesen. Denn AGGREGAT() ist zwar, wie ich von Anfang an immer geschrieben habe, eine nützliche Sammelfunktion aber keine eierlegende Wollmichsau-Funktion. Eine solche gibt es nicht und wird es auch nicht geben. Weder sonst-wo also auch nicht in Excel.
    Das solltest aber gerade Du wissen, denn warum sonst hast Du eine derartige Vielzahl von UDFs im „Angebot“? Jede von diesen hat sicherlich auch ihre Berechtigung. Deren Wirkungsweise und Handhabung kennst Du natürlich in- und auswendig. Doch deswegen sind diese für andere Nutzer nicht intuitiver einsetzbar (wie Duua. behauptest) als z.B. die AGGREGAT()-Funktion, jedenfalls nicht so intuitiv, wie ich diese Funktion mittlerweile anwende.
    Deswegen würde ich aber nie schreiben: „Fazit: UDF(s) von Luc? Nein, danke!“. Im Gegenteil, an einer gut dokumentierten (!) (Sammel-)funktion u.a. für das Trennen und Vereinen von Datenwerten mangelt es auch meines Erachtens Excel in der Standardfunktionalität ohne VBA wirklich sehr. Am liebsten wäre mir eine solche, wenn sich endlich MS zu einer solchen aufraffen könnte.
    Und natürlich wünschte ich mir seitens MS auch eine Ergänzung der Matrixfunktionalität von AGGREGAT() für alle Teilfunktionen und die konsequente Berücksichtigung ausgeblendeter Zellen und ...
    Na ja, aber ich bin auch realistisch ... doch wunschfrei bin und bleibe ich nicht! Und das genauso wenig wie sicher jeder Andere, egal ob Excel oder Wesentlicheres als Excel betreffend.
    Gruß Werner
    ..,-...

    Bild

    Betrifft: nicht aktiv - trotzdem schreiben
    von: KlausF

    Geschrieben am: 17.01.2016 14:33:27
    Hallo Werner,
    [ Vorab, unklar ist und bleibt mir, wie es Dir möglich war am 15.01. Mittags im erst erwähnten thread dort noch einen Ergänzungsbeitrag zu schreiben, obwohl dieser schon am Morgen des 15.01. nicht mehr aktiv war? ]
    Das hat Luc bei mir auch schon mal gemacht. Eine Möglichkeit besteht darin, zu warten
    bis der Eintrag fast ganz unten steht, dann das Antwortfenster in einem eigenen Tab öffnen
    und so lange zu warten bis der Eintrag aus dem Hauptfenster verschwunden ist (kann manchmal
    noch ein paar Stunden dauern). Dann antwortest Du in Deinem noch offenen Tab und schickst ihn ab ...
    Über die kranke Vorgehensweise will ich mich ausnahmsweise mal nicht auslassen ,-)
    Gruß
    Klaus

    Bild

    Betrifft: Aha, so macht der Klaus das! Das habe ich ...
    von: Luc:-?

    Geschrieben am: 17.01.2016 23:32:37
    nicht nötig! Ich muss nicht warten. Außerdem war der BT schon aus dem (angezeigten) Forum verschwunden. Da hätte diese Methode wohl nicht fktioniert! :->
    Mal etwas logischer denken und Hajos Standard-AW dazu weiterentwickeln wäre meine Empfehlung…
    Luc :-?

    Bild

    Betrifft: dummplump
    von: KlausF

    Geschrieben am: 18.01.2016 07:31:23
    Wer lesen kann ist klar im Vorteil. Ich habe ja exakt beschrieben, wie der Luc das macht
    obwohl der Beitrag im (angezeigten) Forum verschwunden ist.
    Aber wenn es denn nicht stimmen sollte ... dann erzähle uns doch mal Deinen Weg.
    Und vor allem: WARUM er das so macht. Denn dass das auf normalem Wege nicht funktioniert,
    wissen ja alle hier. Also Luc, WARUM machst Du das überhaupt?

    Bild

    Betrifft: Schon mal was von Archiv-Nachnutzern ...
    von: Luc:-?

    Geschrieben am: 18.01.2016 11:36:16
    …gehört, dummplump?
    Mache ich, wenn mir nachträglich noch was eingefallen ist. Ansonsten geht's dich gar nichts an! Krank ist nur dein Erklärungsversuch! Ich werde dir das Wie nicht auf die Nase binden. Musst du schon selbst draufkommen!
    Luc :-?

    Bild

    Betrifft: Nö
    von: KlausF

    Geschrieben am: 18.01.2016 15:20:30
    So so, „Archiv-Nachnutzern“ nennt er das.
    „Nachnutzern“ ist nichts anderes als die von mir beschriebene Technik, mit dem einzigen Unterschied,
    dass in Deinem Fall der User jeden möglichen Antwortlink bunkert statt als offenen Tab zu halten.
    Mich hast Du nach 5 Tagen und 5 Stunden nachts um halb eins schimpfend mit Bürgermeister von Wesel
    „nachgenutzert“. Sind es solche Ergüsse, die Du meinst, wenn Du von [ Zitat ]
    „Mache ich, wenn mir nachträglich noch was eingefallen ist“ sprichst? Du brauchst 5 Tage und 5 Stunden,
    damit Dir so etwas einfällt? Wow.
    Hätte Hans ein „Nachnutzern“ seines Archivs gewollt, dann würde es doch wohl schon lange als
    Funktion hier implementiert sein, oder?
    Und was sollte ein „Nachnutzern“ dem Frager wohl Wert sein können, wenn er doch nicht
    mehr darauf antworten kann, ja in der Regel sogar nicht einmal weis, wie die Antwort eingebracht wurde?
    Kann es sein, dass Du das Forum für Deine persönlichen Zwecke missbrauchst und „nachnutzern“ ein
    Synonym für das hier ist?:
    http://bfy.tw/3mjp
    SchöMo
    Klaus

    Bild

    Betrifft: 'Nachnutzern'=Dativ Plural von 'Nachnutzer', ...
    von: Luc:-?

    Geschrieben am: 18.01.2016 15:27:41
    …und damals hast du wohl auch noch im Archiv geantwortet, also tu' nicht so! Außerdem ist Bürgermeister doch 'n toller Job, den du offensichtlich gern ausübst, hier bspw um einen ernsthaften Thread, dessen Thema anscheinend deinen Horizont überschreitet, trollhaft zu stören.
    Ende der Toleranz! Luc :-?

    Bild

    Betrifft: Kommt wohl von Nichtsnutz
    von: KlausF

    Geschrieben am: 18.01.2016 16:02:11
    Zitat:
    …und damals hast du wohl auch noch im Archiv geantwortet, also tu' nicht so
    Aber klar doch !
    Nur um Dir zu zeigen, dass auch andere Leute hier nicht so dumm sind. Und soll ich Dir was sagen:
    Das ist vermutlich der einzige Thread bei Herber, in dem du NICHT das letzte Wort hattest.
    Und das wird Dich ungeheuerlich gewurmt haben :-) denn das wird für alle Tage so bleiben.
    Aber ich bin mir sicher, dass Du häufig darüber nachdenkst, ob man da nicht doch noch ...
    irgendwie ... das muss doch gehen ... vielleicht ...
    SchöMo, Luc!
    Klaus

    Bild

    Betrifft: ...Und jetzt willst du es so, …
    von: Luc:-?

    Geschrieben am: 18.01.2016 01:48:47
    …Werner! ;-]
    Ich verstehe in keinster Weise, warum du dich durch irgendeinen meiner von dir verlinkten BTe kritisiert fühlst! Mir ging's immer nur um Tatsachen, quasi die Sache an sich. Es war natürlich dir überlassen, ob und wie du auf meinen obigen Exkurs reagierst, aber ein solches Statement deinerseits war eigentlich weder erwartet noch notwendig.
    Du meinst, ich würde das nur aus meiner (speziellen) Sicht sehen. Aus welcher Sicht siehst du das denn? Doch sicher nicht aus der Sicht eines Otto Normalnutzers, der sich ggf wundert, warum er eine einfache Summe über ein Datenfeld nicht bilden, dafür aber Quantile und Quartile und auch KGRÖSSTE und KKLEINSTE einsetzen kann. Ja, soll der in diesem Fall nun suchen, wie er ein Ergebnis per Umschreibung durch die fktionablen Fktt erreichen kann? Das kann es doch nicht sein! MS hat's sich mit der Hilfe dazu denn auch leicht gemacht und nur ZellBereiche erwähnt, Datenfelder (aus Ausdrücken als Argument), die bei anderen Fktt ausdrücklich genannt wdn, weggelassen.
    Die Erwähnung von SUMMEWENNS und ZÄHLENWENNS deinerseits hat nur am Rande mit dieser Problematik zu tun, denn obwohl MS hier auf eine Gelegenheit verzichtet hat, zur Universalität der ursprünglichen FktsAusstattung von Xl aufzuschließen, impliziert der den bereits vorhandenen Fktt fast gleiche Name nicht gerade derartige Neuerungen. Umsomehr hoffte man, von AGGREGAT erwarten zu können. Stattdessen bekam man eine Mogelpackung, quasi eine Chimäre, von vorne das Goldene Kalb und von hinten immer noch der alte (Teilergebnis-)Ziegenbock; oder für Autofans - vorne Porsche, hinten Trabi.
    Während die Fml-Freaks sich eifrig an die Auslotung der Möglichkeiten dieser Fkt machten und dabei schnell merkten, dass Novitäten fast nur die neu hinzugekommenen Intern-Fktt bieten, muss der NormalNutzer diese Fkt doch als Einheit auffassen, zumal, wenn XL14/2010 seine 1.Xl-Erfahrung ist. Verwendet er sie wie in der Hilfe beschrieben wird, wird er wohl auch nicht enttäuscht wdn, anderenfalls schon eher. Würde man diese Fkt mit einem Gebäude vergleichen, wäre der neue Teil ein moderner Mehrzweckbau, der einem betagten Gebäude als Front vorangestellt und mit ihm verbunden wurde. Während sich nun die „Formulisten“ in den schicken Räumen dieses Frontgebäudes tummeln, kann Otto ganz schnell und plötzlich im maroden Hintergebäude landen und sich wundern, dass der Aufzug nicht fktioniert. Das ist keine Meisterleistung, sondern einfach nur handwerklicher Pfusch! Wer einen Gebrauchtwagen in der Mitte zerteilt, um die jeweils passende Hälfte mit der unbeschädigten von Unfallwagen zu verschweißen und das neu entstandene Fahrzeug dann ohne den Unfallmakel verkaufen zu können, handelt kriminell! Der Nutzer würde betrogen, während er im Falle der Fkt nur enttäuscht wäre (falls er mehr erwartet hätte).
    Diese Enttäuschung habe ich zum Ausdruck gebracht und gleichzeitig zu erklären versucht, wie diese Seltsamkeit grdsätzlich zustande kommt, nicht mehr und auch nicht weniger! Die Beschränkungen des neuen Teils vermag ich allerdings nicht zu begründen, denn sie entziehen sich meiner Logik.
    Jede Fkt stellt einen Algorithmus, eine Rechenvorschrift, dar, egal, ob sie als Σai für i=[1,3] oder SUMME(A1:A3) notiert wird. In beiden Fällen handelt es sich um a₁+a₂+a₃, nur dass im Fall der Xl-Fkt ein Pgm dahintersteht, das diese Daten prüft und nur echte Zahlen einbezieht, wobei beim 1.Fehlerwert ein Abbruch erfolgt und das Ergebnis dann diesen Fehlerwert zeigt. Da die xlFkt SUMME auch unzusammenhängende Bereiche und Datenfelder (aus Ausdrücken als Argument) verarbeiten kann, könnte man im Falle eines Bereichs die FehlerZellen einfach weglassen, im anderen, den F-Wert durch 0 oder Text ersetzen. Genau das Erstere macht AGGREGAT bei entsprd Argumentierung. Bei TEILERGEBNIS wäre das auch möglich, ist aber von MS nicht vorgesehen worden (das macht dann meine UDF NoErrRange, die ebenfalls einen unzusammenhängenden Bereich bildet). So etwas zu ergänzen, war also nicht sonderlich schwer. Gleiches gilt für die weiteren FilterMöglichkeiten.
    Es ist natürlich jedem unbenommen, die neuen Möglichkeiten auszuloten. Trotzdem muss erlaubt sein, das als Einheit erscheinende „Gesamt(kunst)werk“ zu kritisieren, denn es sollte nicht vergessen wdn, dass das allen zV steht und nicht exklusiv als „Spielwiese“ von Fml-Künstlern gedacht ist. Das hat auch nichts mit einer wie auch immer gearteten Eierlegenden Wollmilchsau, die ggf auch noch Honig produzieren kann, zu tun, sondern ist einfach nur eine Frage solider PgmmierArbeit. Man muss doch nicht jede Unzulänglichkeit tolerieren, nur weil sie einem offiziellen MS-Produkt anhaftet. Dort soll man gefälligst seine Hausaufgaben ordentlich machen!
    Mit der dürftigen MS-Hilfe richtet man sich ein und forscht selbst nach weiteren EinsatzMöglichkeiten; zu meinen UDFs verlangen gewisse Leute aber eine umfassende Hilfe mit Darstellung aller Möglichkeiten als EinsatzVoraussetzung, obwohl die genausogut „erforscht“ wdn könnten. Diese Forderung sollten diejenigen mal an MS stellen! Wäre interessant, was man dort antworten würde (wenn überhaupt)… ;-]
    Übrigens, wenn alle xlFktt so konstruiert worden wären wie die neueren und zT auch neuesten, gäb's wohl keine Fml-Gurus, denn jede Nebenrechnung würde Hilfszellen und ggf Unter-Hilfszellen erfordern — das Aus für superlange FmlSchlangen. Mit den DB~-Fktt war MS ja schon mal in diese Richtung unterwegs…
    Morrn, Luc :-?
    PS: Deine Frage beantworte ich dir per Mail, da es wohl nicht im Interesse von HWH liegt, dass das überhand nimmt, obwohl es inzwischen ja egal sein könnte.

    Bild

    Betrifft: AW: belassen wir es doch einfach dabei, dass ...
    von: ... neopa C

    Geschrieben am: 18.01.2016 08:30:24
    Hallo Luc,
    ... wir verschiedene Sichtweisen haben und/oder uns nicht so überzeugend artikulieren können, dass wir uns diesbzgl. verständigen könnten.
    Jedenfalls werde ich weiterhin AGGREGAT() in der derzeitigen auch noch so unvollkommenen Form als eine Bereicherung für Problemlösungen auf Formelbasis ansehen, einsetzen und propagieren.
    Gruß Werner
    .. , - ...

    Bild

    Betrifft: Na, dann sei es so! Gruß owT
    von: Luc:-?
    Geschrieben am: 18.01.2016 11:43:11
    :-?

    Bild

    Betrifft: AW: ...Und jetzt willst du es so, …
    von: Daniel

    Geschrieben am: 18.01.2016 14:23:13
    Luc schrieb:
    zu meinen UDFs verlangen gewisse Leute aber eine umfassende Hilfe mit Darstellung aller Möglichkeiten als EinsatzVoraussetzung, obwohl die genausogut „erforscht“ wdn könnten.
    nein Luc, es wurde nicht von dir verlangt,sondern es wurde dir empfohlen, wenn du den möglichen Nutzerkreis deiner UDFs etwas weiter ziehen willst als über die Handvoll Menschen, die sich die Mühe machen, so eine Funktion zu erforschen.
    Gruß Daniel

    Bild

    Betrifft: Als ich das schrieb, wollte ich mal sehen, ...
    von: Luc:-?

    Geschrieben am: 18.01.2016 15:56:43
    …ob sich gewisse Leute die Mühe machen, diesmal alles zu lesen und nicht mittendrin aufhören, wie in anderem Fall, Daniel;
    aber, wenn du nicht mehr beitragen willst oder kannst, als das, muss ich deine Beiträge hier gar nicht erst lesen.
    Im Übrigen kann ich mich nicht erinnern, dich als Tutor engagiert zu haben. Hast du überhaupt den entsprd Befähigungsnachweis? Außerdem, was würde wohl dein Chef dazu sagen, dass du einen Großteil deiner Arbeitszeit in Foren verbringst? Ich glaube ja kaum, dass deine Firma noch irgendeinen Nutzen davon hat. Nichts anderes zu tun? Dem kann dein Chef sicher abhelfen… :-]
    Gruß, Luc :-?

    Bild

    Betrifft: AW: Als ich das schrieb, wollte ich mal sehen, ...
    von: Daniel

    Geschrieben am: 18.01.2016 16:34:04
    jo, Luc, ist klar.
    dass du meine Beiträge nicht mehr lesen und darauf reagiern wolltest, hast du mir in der Vergangenheit schon mehrfach versprochen, wie wäre es, wenn du dich einfach mal daran hälst?
    Gruß Daniel

    Bild

    Betrifft: Illustration dazu
    von: Luc:-?

    Geschrieben am: 18.01.2016 18:22:46
    Die AGGREGAT-Fml aus Luschis Bsp, allerdings mit 9=Summe, fktioniert nur so:
    Userbild
    In Zeile 10 handelt es sich um eine spezielle VerbundZelle, die sowohl die Ergebnis- als auch die Argument-Fml enthält, also die erforderlichen Hilfszellen, was außerdem beweist, dass MatrixFmln in VerbundZellen möglich sind, wenn diese per FormatPinsel erzeugt wdn.
    Ein anderes Bsp als Vgl von AGGREGAT und TEILERGEBNIS (beide für ZellBereiche) zeigt folgd HTML-Tabelle:
     NOPQRS
    1WerteSummeFunktion(en)BereichFormel 
    2113AGGREGATN2:N7⇒AGGREGAT(9;6;N2:N7)
    3213AGGREGATN2:N3;N5:N7⇒AGGREGAT(9;4;(N2:N3;N5:N7))
    4#NV13AGGREGATNoErrRange⇒AGGREGAT(9;4;NoErrRange(N2:N7))
    54#NVF13: Typen unverträglichN2:N7⇒TEILERGEBNIS(9;N2:N7)
    6 13TEILERGEBNISN2:N3;N5:N7⇒TEILERGEBNIS(9;(N2:N3;N5:N7))
    7613TEILERGEBNISNoErrRange⇒TEILERGEBNIS(9;NoErrRange(N2:N7))
    Hierbei kam es mir vor allem auf die Demonstration an, dass beide Fktt unzusammenhängende Bereiche verarbeiten können, was die Ausfilterung von Fehlerwert-Zellen ermöglicht, wie auch die Bspp mit der UDF NoErrRange zeigen.
    Luc :-?

    Bild

    Betrifft: AW: warum solche "Verrenkungen" ...
    von: ... neopa C

    Geschrieben am: 19.01.2016 08:49:29
    Hallo Luc,
    ... Deine Formellösung wie Du sie als erstes angeführt hast ist doch nun wirklich unnötig. Es liegt dafür eine wesentliche bessere Lösungsformel vor. Ich weiß nicht, was Du damit bezweckst.
    Deine "Demonstration dass beide Fktt unzusammenhängende Bereiche verarbeiten können" ist wohl den meisten bekannt, die sich mit der Materie auseinandergesetzt haben. Ich sehe darin auch keinen keinen großen Zugewinn zum Diskussionthema.
    Gruß Werner
    .. , - ...

    Bild

    Betrifft: Die 1.Lösung unterstreicht, dass es sich ...
    von: Luc:-?

    Geschrieben am: 19.01.2016 14:58:19
    …hierbei immer noch um den alten Ansatz von TEILERGEBNIS handelt, Werner,
    denn mit Hilfszellen wäre auch eine solche Lösung, die der NormalNutzer sicher als Erstes versuchen würde, möglich. Das hier die Hilfszellen mit der ErgebnisZelle in einem Verbund stehen, hat den anderen genannten Zweck.
    Beim 2.Bsp hast du zwar im Prinzip recht, ich wollte aber demonstrieren, dass es nicht sonderlich schwer gewesen sein kann, das nachträglich in die Fkt zu integrieren, eben weil schon TEILERGEBNIS mit unzusammen­hängenden Bereichen umgehen konnte. Die PgmTechnik war also schon da!
    Gruß, Luc :-?
    Besser informiert mit …

    Bild

    Betrifft: AW: die "Normalnutzer" würden ... und ...
    von: ... neopa C

    Geschrieben am: 19.01.2016 17:40:25
    Hallo Luc,
    ... solche würde sicherlich keinesfalls eine derartige Lösung anstreben sondern entweder ein derartiges Problem gänzlich umgehen oder Excelkundige direkt oder über ein Forum konsultieren ;-)
    Wir sind uns wohl einig, dass es wünschenswert gewesen wäre, die Funktionalitäten der AGGREGAT()-Funktion seitens MS "homogener und vollständiger" anzubieten.
    Doch die Orientierung (oder Vorgabe) seitens MS war eben eine andere, womit ich mich aber wiederhole. In der MS-Hilfe (XL 2010) steht dazu als erster Satz: Die AGGREGAT-Funktion hat den Zweck, bestimmte Beschränkungen bei der bedingten Formatierung zu umgehen
    Da hatten die der Programmierer sicher nicht im Fokus, was einige Nutzer sonst noch mit der dann bereitgestellten Funktionalität anstellen würden. Wenn das diesen bewusst gewesen wäre, dann wären diese sicher auch in der Lage gewesen, das eine oder andere noch einzubauen (natürlich nur, wenn Ihnen der Aufwand auch entsprechend entlohnt wurden wäre).
    Diese Sichtweise ist aber sicher nicht nur für mich verständlich, sondern (fast) allen Angestellten zu eigen, wenn sie nicht ihren Job verlieren wollen, egal ob sie Angestellte oder Freischaffende von/für MS oder eine 2-Mann "Schmiede" sind.
    Gruß Werner
    .. , - ...

    Bild

    Betrifft: Also, wenn ich die xlHilfe von xl14/2010 ...
    von: Luc:-?

    Geschrieben am: 19.01.2016 18:45:59
    …unter Windows10 aufrufe, Werner,
    sieht es so aus, als ob eine Online-Verbindung zu MS aufgebaut würde. In der Hilfe zur Fkt AGGREGAT kommt dann der Begriff Bedingte Formatierung gar nicht vor, sondern der Text entspricht, mit den entsprd Ergänzungen, im Prinzip eher dem von TEILERGEBNIS. Beim Vgl fiel mir allerdings auf, dass letztere Fkt ja nur Fktt bis Nr 11 hat, 12 u.13 (Median, Modalwert) also auch schon neu hinzugekommen sind. Trotzdem fktionieren diese UnterFktt nur mit ZellBereichen, obwohl bspw die separate Fkt MEDIAN auch Datenfelder verarbeiten kann! Das Ganze ist also noch verrückter als bisher von mir angenommen. Das kann einfach nicht rational begründet wdn; der Grund wird eher sein, dass entweder mehrere Pgmmierer daran gearbeitet haben oder einer unter Zeitdruck geraten ist und deshalb nicht so fortgesetzt hat, wie er begonnen hatte.
    Du sprichst hier menschliche Verhaltensweisen an, die aber nicht unbedingt der primäre Grund für dieses eklektizistische Sammelsurium sein dürften. Da käme eher die bei MS schon seit längerem festzustellende Methode infrage, sich auf seine Marktmacht zu verlassen. Das ist auch typisch für Großkonzerne, die über ein Mono- oder Oligopol verfügen, und weltweit zu beobachten. Der NormalVerbraucher bekommt zunehmend nur noch Tünnef, das mittlere Qualitätssegment schwindet immer mehr. Am anderen Ende dann die Luxusgüter für die, die sie sich leisten können. Die Polarisierung der Gesellschaft zieht also zunehmend auch eine Polarisierung der ProduktPalette nach sich.
    Deshalb können wir uns auch viel wünschen, nur MS wird's nicht erfüllen, bei einzelnen Fktt schon gar nicht im Nachhinein (Stichworte: Produktsicherheit u.-gewöhnung).
    Ansonsten würde diese Zusammengewürfeltheit von AGGREGAT auch von den Gewohnheiten ggf mehrerer Pgmmierer abhängen - im VBA-Bezug: der eine hätte Arg3 As Range deklariert und der andere gar nicht oder As Variant, eben so wie auch die meisten der ältesten OriginalFktt daherkommen. Was MS aber explizit in der Hilfe erwähnt, ist die beabsichtigte TabellenBezogenheit unter Berücksichtigung ausblendbarer Zeilen, genau, was auch die Methode Teilergebnis vorsieht. Beide Fktt sind also quasi deren „kleine Brüder“. ;-]
    Und nur dank dieses einen Pgmmierers, der verstanden hat, worauf es bei TabBlattFktt ankommt, und nicht in allgemeinen, speziell DB-PgmmierKlischees ge- bzw befangen ist, könnt ihr mit den Fktt ab lfdNr 14 jonglieren. Der hätte das genauso unterbinden können, wie die anderen, aber viell hatte er ja nur was vergessen… ;-]
    Luc :-?

    Bild

    Betrifft: AW: Also, wenn ich die xlHilfe von xl14/2010 ...
    von: Daniel
    Geschrieben am: 19.01.2016 21:55:24
    in dieser Excelversion kannst du wählen, ob du die Online- oder Offline-Hilfe lesen willst.
    (die Offline-Hilfe muss natürlich installiert sein)
    Gruß Daniel

    Bild

    Betrifft: Der hat mich nicht gefragt und vorher ...
    von: Luc:-?

    Geschrieben am: 20.01.2016 00:19:30
    …(vor Win10-Update) war's wohl OffLine, Daniel;
    naja egal, OnLine wird eh' aktueller sein.
    Gruß, Luc :-?

    Bild

    Betrifft: Noch was: "Matrixformelfähigkeit"
    von: Luc:-?

    Geschrieben am: 20.01.2016 04:32:12
    Es wird verschiedentlich behauptet, AGGREGAT sei erst ab Fktsnr 14 „matrixformelfähig“. Das ist natürlich blanker Unsinn und beruht auf einer Fehldeutung von Struktur und Wirkungsweise der Fkt, sowie dessen, was eine MatrixFml ist und worauf Matrix(formel)funktionalität (wie neopa das nennt) beruht. Die Ursache dafür ist allein der heterogene Aufbau der Fkt aus alt und neu oder besser zwingend ZellBereiche verlangenden und auch Datenfelder (aus Ausdrücken als FktsArgument) tolerierenden Teilen. Bspw fktionieren die Fktt 14+15 genauso wie mit ZellBereichen auch mit Datenfeldern. Kommen in diesen Fehlerwerte vor, führt die Verwendung von Arg2=6 dazu, dass die Berechnung nicht abgebrochen wird. Im Falle von ZellBereichen wdn diese Zellen vermutlich ausgelassen, bei Datenfeldern zwingend durch etwas Anderes (keine Zahl!) ersetzt. Die Fktt liefern allerdings dann einen eigenen Fehlerwert, wenn die Klasse k (Arg4) zu groß gewählt wird, d.h., keine Zahlen in der/m Werte-Matrix/-Vektor für diesen Rang zV stehen (LeerZellen sind dabei unproblematisch). Das ist auch genau das Verhalten, dass beide Fktt auch separat angewendet zeigen, hat also nichts mit AGGREGAT zu tun. MS hat natürlich für den Rang nur ein skalares k angedacht, die Xl-Steuerung sorgt aber im Bunde mit der Pgmmierung dieser Fktt dafür, dass auch ein ganzes Datenfeld erzeugt wdn kann. Überschreitet dessen k-bedingte Größe die Anzahl numerischer Werte, wird der Fehlerwert #ZAHL! generiert, überschreitet sie die Anzahl der Werte insgesamt, erscheint wie üblich #NV in den überzähligen ErgebnisZellen bzw -Werten. Diese erst aus der Berechnung entstehenden Fehler wdn von AGGREGAT nicht kompensiert! Dadurch kommen bei Luschis Bsp auch die mind 25 QuellZeilen zustande, wenn mit entsprd hoher Zahl von SortierRängen in k gearbeitet wird!
    Eine Fkt kann entweder ZellBereiche u/o Datenfelder verarbeiten oder sie kann es nicht. Diese Fähigkeit kann in Gänze oder bezogen auf einzelne Argumente fktsimmanent sein oder nur durch WerteVariation der Xl-Steuerung verursacht wdn, wobei die MatrixFml-Form nur eine Mitteilung an Xl ist, dass alle aus einer vollständigen Berechnung resultierenden Ergebniswerte zu berücksichtigen sind. Das ist schon das ganze „Geheimnis“ hinter manchem nur scheinbar merkwürdigen Fktsverhalten. Bei einem Hybriden wie AGGREGAT hängt das Verhalten primär vom RahmenPgm und erst sekundär von den aufgerufenen Fktt ab. Die können nur wirksam wdn, wenn das RahmenPgm auch Daten durchlässt, d.h., sie mit Datenübergabe aufruft.
    Luc :-?

    Bild

    Betrifft: AW: Regeln kann man einhalten oder auch nicht ...
    von: ... neopa C

    Geschrieben am: 20.01.2016 09:49:38
    Hallo Luc,
    ... man sie natürlich auch deuten oder abändern oder ignorieren oder ...
    Wie auch immer, ich verstehe Deine Zielstellung bzgl. der Funktion AGGREGAT() nicht. Diese stellt sich mir jedenfalls so dar, dass Du deren Anwendungsmöglichkeiten möglichst in den Skat drücken willst. Ist Deine Sache. Ich habe mittlerweile in weit über 100 Anwendungsfällen in Forenthreads den Nutzwert des spez. Einsatzes der Funktion zur Geltung gebracht und werde es, wie bereits geschrieben, weiterhin tun.
    Jeder kann und sollte für sich selbst entscheiden, ob die Funktion ihm nützt oder nützlich sein könnte oder eben nicht.
    Gruß Werner
    .. , - ...

    Bild

    Betrifft: Sicher auch OK, aber die Fkt ist nunmal ...
    von: Luc:-?

    Geschrieben am: 21.01.2016 00:17:32
    …für ZellBereiche gedacht, Werner;
    und das sie ab Fktsnr 14 auch Datenfelder verarbeiten kann, ist eher ein Nebeneffekt, auf dem niemals die Betonung liegen sollte, zumal es für Datenfelder auch keine ausgeblendeten Zeilen gibt. Das Einzige, was hierbei nützlich ist, ist das Ignorieren von Fehlerwerten, aber das kann man mit WENNFEHLER (oder auch klassischer) ebenfalls erreichen. Wären Datenfelder ernsthaft vorgesehen worden, hätte das für alle Fktt gelten müssen. Auch sehe ich keinen Sinn im Aufbau sortierter Datenfelder mit AGGREGAT (Fktt 14/15), das kann man mit den EinzelFktt ja auch. Hier geht's MS wohl doch eher um die Rückgabe eines Werts mit einem bestimmten Rang.
    Um zu demonstrieren, dass es ein Klacks gewesen wäre, Datenfelder generell zuzulassen, habe ich über 5 Stdd mit vielen Pausen und Unterbrechungen inkl Kurztest (EffektivZeit max 1-2 Stdd) eine analoge RahmenFkt für Datenfelder geschrieben (zur 1.Variante von AGGREGAT - die 2. wäre auch kein Problem). Damit ließe sich Luschis Problem mit der 1zelligen MatrixFml …
    C10[:C13]:{=AggregateXk(9;6;ISTZAHL(FINDEN(DBase!B$3:B$99;B10))*DBase!C$3:C$99)}
    …für AggregateXk(Funktion;Optionen;DatenfeldAusdruck;k) so lösen (rot → optional):
     BC
    9sourcesummary
    10a;b;c;d38
    11a;f;g;l47
    12f;c;k;d50
    13hif243

    Das Pgm der UDF sieht so aus:
    Rem Aggregat f.Datenfelder aus Ausdruck (eXpression)
    '   als Arg3; nur f. 1 Datenfeld u.ggf 1es als Arg4;
    '   Umwandl Bereich in DFeld; nur Input-FWert-Ignor!
    '   Vs1.0 -LSr -cd:20160120\15:30 -1pub:20160121herber -lupd:20160120\20:30
    Function AggregateXk(ByVal Funktion As Integer, ByVal Optionen As Integer, _
    ByVal DatenfeldAusdruck, Optional ByVal k)
    Dim sx As Long, sz As Long, zx As Long, zz As Long, erg, kw, xw, zwErg
    On Error GoTo fx
    With WorksheetFunction
    If TypeName(DatenfeldAusdruck) = "Range" Then
    If DatenfeldAusdruck.Cells.Count > 1 Then
    DatenfeldAusdruck = .Transpose(.Transpose(DatenfeldAusdruck))
    Else: DatenfeldAusdruck = Array(DatenfeldAusdruck)
    End If
    End If
    If Not IsMissing(k) Then
    If TypeName(k) = "Range" Then
    If k.Cells.Count > 1 Then k = .Transpose(.Transpose(k))
    End If
    End If
    End With
    On Error Resume Next
    sz = UBound(DatenfeldAusdruck, 2) + 1 - LBound(DatenfeldAusdruck, 2)
    zz = UBound(DatenfeldAusdruck, 1) + 1 - LBound(DatenfeldAusdruck, 1)
    On Error GoTo fx: ReDim zwErg(zz - 1, sz - 1)
    Select Case Optionen
    Case 0, 1, 4, 5                 'k.1fachBhdl f.DF mögl!
    zwErg = DatenfeldAusdruck
    Case 2, 3, 6, 7                 'dito, nur FWertErsatz!
    For Each xw In DatenfeldAusdruck
    If Not IsError(xw) Then zwErg(zx, sx) = xw
    zx = (zx + 1) Mod zz: sx = sx - CInt(zx = 0)
    Next xw
    Case Else: Err.Raise xlErrNA
    End Select
    With Application
    If Funktion > 13 And IsArray(k) Then
    sz = UBound(k, 2) + 1 - LBound(k, 2)
    zz = UBound(k, 1) + 1 - LBound(k, 1)
    kw = k: zx = 0: sx = 0: ReDim erg(zz - 1, sz - 1)
    For Each k In kw
    On Error Resume Next: GoSub kf: On Error GoTo fx
    erg(zx, sx) = AggregateXk: AggregateXk = Empty
    zx = (zx + 1) Mod zz: sx = sx - CInt(zx = 0)
    Next k
    AggregateXk = erg: Exit Function
    End If
    kf:     Select Case Funktion
    Case 1:  AggregateXk = .Average(zwErg)
    Case 2:  AggregateXk = .Count(zwErg)
    Case 3:  AggregateXk = .CountA(zwErg)
    Case 4:  AggregateXk = .Max(zwErg)
    Case 5:  AggregateXk = .Min(zwErg)
    Case 6:  AggregateXk = .Product(zwErg)
    Case 7:  AggregateXk = .StDev_S(zwErg)
    Case 8:  AggregateXk = .StDev_P(zwErg)
    Case 9:  AggregateXk = .Sum(zwErg)
    Case 10: AggregateXk = .Var_S(zwErg)
    Case 11: AggregateXk = .Var_P(zwErg)
    Case 12: AggregateXk = .Median(zwErg)
    Case 13: AggregateXk = .Mode_Sngl(zwErg)
    Case 14: AggregateXk = .Large(zwErg, k)
    Case 15: AggregateXk = .Small(zwErg, k)
    Case 16: AggregateXk = .Percentile_Inc(zwErg, k)
    Case 17: AggregateXk = .Quartile_Inc(zwErg, k)
    Case 18: AggregateXk = .Percentile_Exc(zwErg, k)
    Case 19: AggregateXk = .Quartile_Exc(zwErg, k)
    Case Else: Err.Raise xlErrNA
    End Select
    If Not IsEmpty(kw) Then Return
    End With
    fx: If CBool(Err.Number) Then AggregateXk = CVErr(Err.Number)
    End Function
    Darf ausprobiert wdn! ;-]
    Gruß, Luc :-?

    Bild

    Betrifft: AW: hätte, wenn und aber ...
    von: ... neopa C

    Geschrieben am: 21.01.2016 10:04:22
    Hallo Luc,
    ... da ich keinen Einfluß auf die MS-Produktphilosophie habe (vielleicht auch gut so) nutze ich deren Produkte so, wie sie sich mir bieten. Das vermittle ich meinen (beschränkten) Verständnis und meinen (auch beschränkten) Möglichkeiten entsprechend, mehr oder weniger gut und oft auch Anderen. Ich bin nicht fehlerfrei und gestehe Anderen Gleiches zu.
    Bei Dir kann man manchmal schon den Eindruck gewinnen, dass Du das ganz anders siehst. Wie auch immer. Deine UDF werde ich, nicht Heute und Morgen, testen. Vorab aber gefragt, kann ich voraussetzen, dass mit dieser die bisher von Dir und mir gelisteten Mängel der AGGREGAT()-Funktion behoben sind?
    Gruß Werner
    .. , - ...

    Bild

    Betrifft: Nee, natürlich nicht, ...
    von: Luc:-?

    Geschrieben am: 21.01.2016 14:19:12
    …Werner,
    denn auf die AGGREGAT-Fkt an sich, hat das ja keinen Einfluss. ;-)
    Meine UDF erreicht für Datenfelder (aus Ausdrücken als Arg3) ab Fktsnr 14 genau das Ergebnis, das auch AGGREGAT liefern würde (war meine Absicht, hätte ich auch anders, ggf besser machen können). Für alle anderen FktsNrn liefert sie für Datenfelder überhaupt erst ein Ergebnis, allerdings auch nur für diese (ZellBereiche wdn in DFelder umgewandelt, um sie ebenfalls auf diese Weise behandeln zu können). Das, was AGGREGAT für ZellBereiche leistet, kann sie natürlich nicht liefern, denn die meisten dieser Optionen beziehen sich nunmal auf ZellBereiche und stünden somit auch AGGREGAT nicht zV, wenn denn auch Datenfelder bei diesen Unterfktt möglich wären (dann wäre allerdings auch die ganze Diskussion und damit meine UDF gegenstandslos!). Wollte man diese Optionen sich auch irgendwie auf Datenfelder auswirken lassen, müsste man sich auf deren QuellZellBereiche beziehen, was ungleich komplizierter wäre und sicher auch MS nicht machen würde. Einfacher wäre ggf ein Bezug dieser Optionen auf den ErgebnisBereich, aber das macht MS auch nirgendwo, wie man leicht bei den AGGREGAT-UnterFktt ab Nr 14 feststellen kann.
    Natürlich ist AGGREGAT wahrscheinlich eher nicht in VBA pgmmiert, anders strukturiert (Klassen) und (in Teilen?) in PgmBibliotheken (.dll) abgelegt worden, aber das ändert nichts am Grundsätzlichen, nur haben die MS-Pgmmierer noch andere Möglichkeiten als ein simpler VBAler. Umso deutlicher weist dann der AGGREGAT-Hybrid auf andere Intentionen ersterer hin und lässt das, was ihr daraus macht, als Nutzung von Pgmierungslücken erscheinen, ist also quasi das, was auch Hacker tun → „Sicherheitslücken“ ausnutzen (das war und ist übrigens bei SUMMENPRODUKT schon ganz ähnlich, folglich könnte man Fml-Freaks auch als Fml-Hacker oder „Hack-Formulierer“ bezeichnen, wenn man nicht Fml-Forscher bzw FktsErforscher vorziehen wollte!)… ;-]
    Natürlich sehe ich (zwangsläufig) einiges anders als du, denn ich habe eine Vorstellung davon, was die MS-Pgmmierer gemacht haben könnten, um ein bestimmtes Ergebnis zu erreichen. Eine xlFkt (bzw UDF) ist nun mal ein rechentechnisch umgesetzter mathematischer Algorithmus und mit so etwas war und bin ich seit fast einem HalbJhdt konfrontiert. U.a. deshalb habe ich mich auch auf UDFs spezialisiert, denn hier kann man idR noch eigene Ideen in Algorithmen und diese in Rechenschritte umsetzen und kann(/muss) nicht immer nur FertigBausteine zusammensetzen, wie ich das allerdings in der hier vorliegenden UDF iW mal (ausnahmsweise) getan habe. Wenn ich sonst Bausteine verwende, füge ich sie iaR in komplexere Abläufe ein, die ihren Nutzen potenzieren.
    Meine Ausführungen hier dienten dem Zweck, einige Vermutungen in bezug auf die Wirkungsweise und Funktion von AGGREGAT richtigzustellen und gleichzeitig eine (mögliche) Erklärung dafür zu liefern, warum das so ist und was wohl ursprünglich damit bezweckt wurde. Das hat nichts mit grundsätzlicher Ablehnung von Experimenten zu tun, wohl aber mit (aus meiner Sicht) wenig realen Spekulationen. Auch bin ich der Ansicht, dass eine kleine Lücke in einer ansonsten dem bei vielen neueren MS-Fktt Üblichen folgenden Fkt nicht unbedingt zu ideentechnisch kaum noch nachvollziehbaren Salti mortali führen sollte, begleitet von einer gewissen „Aha- und Na-Endlich“-Euphorie. Das ist hier schlimmer als bei SUMMENPRODUKT, bei dem die ganze Fkt solche Raffinessen unterstützt; bei AGGREGAT ist es nur ein kleiner Teil, was NormalNutzer zur Verzweiflung bringen kann. Deshalb ist diese Fkt auch nur für den von MS vorgesehenen Zweck „massentauglich“. Wer darüber hinaus gehen will — bitteschön. Allerdings sollte dann so etwas nie einer soliden Lösung auf normaler Basis vorgezogen wdn, denn das wäre ja eigentlich nur ein „Lückenspringer“…
    Gruß, Luc :-?

    Bild

    Betrifft: AW: dann doch wieder Beitrag vom 18.01.16 8:30 owT
    von: ... neopa C
    Geschrieben am: 21.01.2016 14:49:45
    Gruß Werner
    .. , - ...

    Bild

    Betrifft: Wichtiger Nachtrag
    von: Luc:-?

    Geschrieben am: 21.01.2016 18:55:24
    Ah, Werner,
    jetzt habe ich verstanden, worum es dir/euch eigentlich geht und weshalb du die Sache mit VERWEIS erwähnt hattest, die ja jede Menge Fehler produziert, wobei einem Pgmmierer die Tastatur streikt. Nachdem ich diesen Beitrag von dir gesehen hatte, wurde mir klar, dass es eigentlich gar nicht um AGGREGAT und seine generelle Funktion, sondern nur um die Ausnutzung eines kleinen Fensters dieser Fkt für einen ganz anderen Zweck, nämlich wiedermal die Vereinzelung von MatrixFml-Ergebnissen nebst mögli­chem Verzicht auf die MxFmlForm ging:
     IJKLM
    1AGGREGAT 1zellig{KKLEINSTE 1zellig}{AggregateXk 1zellig}{AggregateXk m-zellig}{AGGREGAT m-zellig}
    2User1@xyz.deUser1@xyz.deUser1@xyz.deUser1@xyz.deUser1@xyz.de
    3User3@xyz.deUser3@xyz.deUser3@xyz.deUser3@xyz.deUser3@xyz.de
    4User8@xyz.deUser8@xyz.deUser8@xyz.deUser8@xyz.deUser8@xyz.de
    5User13@xyz.deUser13@xyz.deUser13@xyz.deUser13@xyz.deUser13@xyz.de
    6User16@xyz.deUser16@xyz.deUser16@xyz.deUser16@xyz.deUser16@xyz.de
    7User18@xyz.deUser18@xyz.deUser18@xyz.deUser18@xyz.deUser18@xyz.de
    8User22@xyz.deUser22@xyz.deUser22@xyz.deUser22@xyz.deUser22@xyz.de
    9User23@xyz.deUser23@xyz.deUser23@xyz.deUser23@xyz.deUser23@xyz.de
    10User24@xyz.deUser24@xyz.deUser24@xyz.deUser24@xyz.deUser24@xyz.de
    11User26@xyz.deUser26@xyz.deUser26@xyz.deUser26@xyz.deUser26@xyz.de
    12     
    13I2[:I11]:=WENNFEHLER(INDEX(Tab!G:G;AGGREGAT(15;6;ZEILE(A$1:A$99)/(INDEX(Tab!$B$1:$F$99;;VERGLEICH("x";Tab!$B$1:$F$1;))="ja"); ZEILE(A1))); "")
    14J2[:J11]: {=WENNFEHLER(INDEX(Tab!G:G;KKLEINSTE(WENNFEHLER(ZEILE(A$1:A$99)/(INDEX(Tab!$B$1:$F$99;;VERGLEICH("x";Tab!$B$1:$F$1;))="ja");999);ZEILE(A1))); "")}
    15K2[:K11]: {=WENNFEHLER(INDEX(Tab!G:G;AggregateXk(15;6;ZEILE(A$1:A$99)/(INDEX(Tab!$B$1:$F$99;;VERGLEICH("x";Tab!$B$1:$F$1;))="ja");ZEILE(A1)));"")}
    16L2:L11: {=WENNFEHLER(INDEX(Tab!G:G;AggregateXk(15;6;ZEILE(A$1:A$99)/(INDEX(Tab!$B$1:$F$99;;VERGLEICH("x";Tab!$B$1:$F$1;))="ja");ZEILE(A1:A10)));"")}
    17M2:M11: {=WENNFEHLER(INDEX(Tab!G:G;AGGREGAT(15;6;ZEILE(A$1:A$99)/(INDEX(Tab!$B$1:$F$99;;VERGLEICH("x";Tab!$B$1:$F$1;))="ja"); ZEILE(A1:A10))); "")}

    Mit Verlaub, dieser „Ehrgeiz“ ist mir höchst suspekt! Denn was bringt das außer einem gewissen Vorteil für Leute, die mit unrationell aufgebauten Tabellen arbeiten wollen? Im oben gezeigten Bsp ist ja deutlich zu sehen, dass das Ergebnis immer dasselbe ist!
    Im Ol-Xl-Tutorial hat PH vor Jahren über MxFmln geschrieben und dabei erwähnt, wer die wohl als Erster in deutsch-sprachigen Foren „entdeckt“ hatte und wie verdienstvoll das war. Nun ist seit einiger Zeit festzustellen, dass das (AntiMxFml-)„Imperium zurückschlägt“, d.h., unter Fml-Gurus ein Trend weg von mehrzelligen, hin zu 1zelligen MxFmln und am besten noch Verzicht auf die lästigen {} zu beobachten ist. Euch ist doch hoffentlich klar, dass das die Rechenbelastung einer Datei erhöht! Denn so muss pro Zelle immer wieder das gleiche Gesamt-Datenfeld gebildet wdn, nur um einen, jeweils anderen Wert daraus zu entnehmen, obwohl man letztlich ja alle braucht! Rationell ist anders! Eine mehrzellige MxFml wird nur 1…2× berechnet und dann alle ihre Ergebnisse auf 1× ausgegeben. Aber das hatten wir ja bereits ausgiebig diskutiert…
    Die Genialität der ursprünglichen Kalkulation von Xl bestand ja gerade darin, dass viele Mechanismen geschaffen wurden, die FktsPgmmierer nutzen konnten, was die meisten auch taten. Andere haben sich offensichtlich nicht auf die Datenbereitstellung ganzer Datenfelder durch die XlSteuerung verlassen und das selbst pgmmiert. Die Folge waren Fktt wie SUMMENPRODUKT, die pgmtechnisch das mitbringen, was du Matrix(formel)funktionalität nennst. Da das bei (TeilFml-)Ausdrücken als Argument in gewissem Umfang auch fktioniert, obwohl das normalerweise MxFmlForm erfordern würde, ist das in VBA nicht so ganz leicht nachzupgmmieren. Eine UDF ist nämlich normalerweise auch auf das angewiesen, was ihr Xl zV stellt, weshalb meine hiesige auch nicht auf die MxFmlForm (als Botschaft an die XlSteuerung!) verzichten kann. Wollte man das autochthon gestalten, müsste die jeweilige VBA-UDF den Text ihrer Fml auslesen, den relevanten Teil ermitteln und eigenständig neu berechnen. Das bedeutet KlammernZählen! In geringerem Umfang habe ich so etwas schon gemacht, sonst würden Explore (Pendant zu Compute und XLM-Fkt AUSWERTEN) und VectAr nicht auch (in geringerem Umfang) mit lokalen FmlTexten (ggf als Dummy-Fmln!) fktionieren, aber es ist halt aufwendig und von MS auch nur bis zu einem gewissen Grad durchgezogen worden.
    Was ihr also eigentlich haben wollt, ist nicht AGGREGAT, sondern eine Fkt, die genau das tut, ein aus einem wie auch immer gearteten Ausdruck ermitteltes Datenfeld komplett zV zu stellen, ganz unabhängig von der XlSteuerung. Die Elimination von Fehlerwerten ist dabei zweitrangig; das kann man mit in die Fkt einbauen, aber auch den jeweiligen Ausdruck entsprd ergänzen. Darüber werde ich mal nachdenken und mich ggf wieder mit dem Ergebnis melden. Immerhin habe ich ja auch schon andere Ergänzungsfktt geschrieben wie zuletzt NoErrRange, davor ChooseIf (noch in Arbeit) und vor Jahren seinen Vorgänger ChooseIn (beide erzeugen einen unzusammen­hängenden Bereich nach Auswahl­Kriterien, der allerdings weiter­verarbeitet wdn muss), sowie Sort4Match, die unsortierte Bereiche intern vorsortiert (auch Texte!), damit schnellere VERWEIS- und VERGLEICH-Varianten eingesetzt wdn können, ohne das physisch sortiert oder Hilfszellen gebildet wdn müssen.
    Trotzdem und zuletzt doch noch eine Korrektur. Bei der geposteten UDF habe ich leider glatt 2 Anweisungen vergessen, weshalb die 1zellige MxFml-Version im obigen Bsp nicht fktionieren würde. Hier ist die Korrektur:
    Rem Aggregat f.Datenfelder aus Ausdruck (eXpression)
    '   als Arg3; nur f. 1 Datenfeld u.ggf 1es als Arg4;
    '   Umwandl Bereich in DFeld; nur Input-FWert-Ignor!
    '   Vs1.1 -LSr -cd:20160120 -1pub:20160120herber -lupd:20160121t
    Function AggregateXk(ByVal Funktion As Integer, ByVal Optionen As Integer, _
    ByVal DatenfeldAusdruck, Optional ByVal k)
    Dim sx As Long, sz As Long, zx As Long, zz As Long, erg, kw, xw, zwErg
    On Error GoTo fx
    With WorksheetFunction
    If TypeName(DatenfeldAusdruck) = "Range" Then
    If DatenfeldAusdruck.Cells.Count > 1 Then
    DatenfeldAusdruck = .Transpose(.Transpose(DatenfeldAusdruck))
    Else: DatenfeldAusdruck = Array(DatenfeldAusdruck)
    End If
    End If
    If Not IsMissing(k) Then
    If TypeName(k) = "Range" Then
    If k.Cells.Count > 1 Then k = .Transpose(.Transpose(k))
    End If
    End If
    End With
    On Error Resume Next
    sz = UBound(DatenfeldAusdruck, 2) + 1 - LBound(DatenfeldAusdruck, 2)
    zz = UBound(DatenfeldAusdruck, 1) + 1 - LBound(DatenfeldAusdruck, 1)
    On Error GoTo fx: ReDim zwErg(zz - 1, sz - 1)
    Select Case Optionen
    Case 0, 1, 4, 5                 'k.1fachBhdl f.DF mögl!
    zwErg = DatenfeldAusdruck
    Case 2, 3, 6, 7                 'dito, nur FWertErsatz!
    For Each xw In DatenfeldAusdruck
    If Not IsError(xw) Then zwErg(zx, sx) = xw
    zx = (zx + 1) Mod zz: sx = sx - CInt(zx = 0)
    Next xw
    Case Else: Err.Raise xlErrNA
    End Select
    With Application
    If Funktion > 13 And IsArray(k) Then
    On Error Resume Next
    sz = UBound(k, 2) + 1 - LBound(k, 2)
    zz = UBound(k, 1) + 1 - LBound(k, 1)
    On Error GoTo fx
    kw = k: zx = 0: sx = 0: ReDim erg(zz - 1, sz - 1)
    For Each k In kw
    On Error Resume Next: GoSub kf: On Error GoTo fx
    erg(zx, sx) = AggregateXk: AggregateXk = Empty
    zx = (zx + 1) Mod zz: sx = sx - CInt(zx = 0)
    Next k
    AggregateXk = erg: Exit Function
    End If
    kf:     Select Case Funktion
    Case 1:  AggregateXk = .Average(zwErg)
    Case 2:  AggregateXk = .Count(zwErg)
    Case 3:  AggregateXk = .CountA(zwErg)
    Case 4:  AggregateXk = .Max(zwErg)
    Case 5:  AggregateXk = .Min(zwErg)
    Case 6:  AggregateXk = .Product(zwErg)
    Case 7:  AggregateXk = .StDev_S(zwErg)
    Case 8:  AggregateXk = .StDev_P(zwErg)
    Case 9:  AggregateXk = .Sum(zwErg)
    Case 10: AggregateXk = .Var_S(zwErg)
    Case 11: AggregateXk = .Var_P(zwErg)
    Case 12: AggregateXk = .Median(zwErg)
    Case 13: AggregateXk = .Mode_Sngl(zwErg)
    Case 14: AggregateXk = .Large(zwErg, k)
    Case 15: AggregateXk = .Small(zwErg, k)
    Case 16: AggregateXk = .Percentile_Inc(zwErg, k)
    Case 17: AggregateXk = .Quartile_Inc(zwErg, k)
    Case 18: AggregateXk = .Percentile_Exc(zwErg, k)
    Case 19: AggregateXk = .Quartile_Exc(zwErg, k)
    Case Else: Err.Raise xlErrNA
    End Select
    If Not IsEmpty(kw) Then Return
    End With
    fx: If CBool(Err.Number) Then AggregateXk = CVErr(Err.Number)
    End Function
    Die eingefügten Anweisungen sind durch blaue Schrift ausgezeichnet.
    Gruß, Luc :-?

    Bild

    Betrifft: Und noch etwas, ...
    von: Luc:-?

    Geschrieben am: 22.01.2016 01:16:28
    …Werner;
    über die ganze Diskussion ist mir doch noch etwas in den Hintergrund geraten, obwohl ich das schon des Öfteren benutzt habe und du gelegentlich ja wohl auch. Warum in aller Welt benutzt ihr für den zuvor von mir ausgemachten eigentlichen Zweck der ganzen Übung nicht ein Feature, das Xl schon seit langer Zeit hat? Dann könntet ihr auch nach Herzenslust 1zellige Fmln mit Matrix(formel)funktionalität bilden - ganz ohne {} und ohne die Berechnungslast zu erhöhen! Eine UDF dafür wäre also gar nicht nötig, denn benannte Fmln können das schon immer. Hatte ich das nicht längst schon bei unseren Diskussionen erwähnt?! Eine benannte Fml wird idR immer vollständig berechnet, nur nicht unbedingt auch alle Ergebniswerte in einer Zelle zV gestellt. Dafür ist dann die Xl-(Zell-)Steuerung zuständig. Aber eine spezifische EinzelErgebnisAuswahl kann jederzeit in einer ZellFml vorgenommen wdn. Die benannte Fml wird auch nur 1× berechnet, nicht in jeder ZellFml, die ihren Namen enthält, aufs Neue. Darum ergänzt, sähe das Bsp dann so aus:
     IJKLMNO
    1AGGREGAT 1zellig{KKLEINSTE 1zellig}{AggregateXk 1zellig}{AggregateXk m-zellig}{AGGREGAT m-zellig}KKLEINSTE 1zelligAggregateXk 1zellig
    2User1@xyz.deUser1@xyz.deUser1@xyz.deUser1@xyz.deUser1@xyz.deUser1@xyz.deUser1@xyz.de
    3User3@xyz.deUser3@xyz.deUser3@xyz.deUser3@xyz.deUser3@xyz.deUser3@xyz.deUser3@xyz.de
    4User8@xyz.deUser8@xyz.deUser8@xyz.deUser8@xyz.deUser8@xyz.deUser8@xyz.deUser8@xyz.de
    5User13@xyz.deUser13@xyz.deUser13@xyz.deUser13@xyz.deUser13@xyz.deUser13@xyz.deUser13@xyz.de
    6User16@xyz.deUser16@xyz.deUser16@xyz.deUser16@xyz.deUser16@xyz.deUser16@xyz.deUser16@xyz.de
    7User18@xyz.deUser18@xyz.deUser18@xyz.deUser18@xyz.deUser18@xyz.deUser18@xyz.deUser18@xyz.de
    8User22@xyz.deUser22@xyz.deUser22@xyz.deUser22@xyz.deUser22@xyz.deUser22@xyz.deUser22@xyz.de
    9User23@xyz.deUser23@xyz.deUser23@xyz.deUser23@xyz.deUser23@xyz.deUser23@xyz.deUser23@xyz.de
    10User24@xyz.deUser24@xyz.deUser24@xyz.deUser24@xyz.deUser24@xyz.deUser24@xyz.deUser24@xyz.de
    11User26@xyz.deUser26@xyz.deUser26@xyz.deUser26@xyz.deUser26@xyz.deUser26@xyz.deUser26@xyz.de
    12xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    13I2[:I11]:=WENNFEHLER(INDEX(Tab!G:G;AGGREGAT(15;6;ZEILE(A$1:A$99)/(INDEX(Tab!$B$1:$F$99;;VERGLEICH("x";Tab!$B$1:$F$1;))="ja"); ZEILE(A1))); "")
    14J2[:J11]: {=WENNFEHLER(INDEX(Tab!G:G;KKLEINSTE(WENNFEHLER(ZEILE(A$1:A$99)/(INDEX(Tab!$B$1:$F$99;;VERGLEICH("x";Tab!$B$1:$F$1;))="ja");999);ZEILE(A1))); "")}
    15K2[:K11]: {=WENNFEHLER(INDEX(Tab!G:G;AggregateXk(15;6;ZEILE(A$1:A$99)/(INDEX(Tab!$B$1:$F$99;;VERGLEICH("x";Tab!$B$1:$F$1;))="ja");ZEILE(A1)));"")}
    16L2:L11: {=WENNFEHLER(INDEX(Tab!G:G;AggregateXk(15;6;ZEILE(A$1:A$99)/(INDEX(Tab!$B$1:$F$99;;VERGLEICH("x";Tab!$B$1:$F$1;))="ja");ZEILE(A1:A10)));"")}
    17M2:M11: {=WENNFEHLER(INDEX(Tab!G:G;AGGREGAT(15;6;ZEILE(A$1:A$99)/(INDEX(Tab!$B$1:$F$99;;VERGLEICH("x";Tab!$B$1:$F$1;))="ja"); ZEILE(A1:A10))); "")}
    18N2[:N11]:=WENNFEHLER(INDEX(Tab!G:G;KKLEINSTE(DFeldoF;ZEILE(A1))); "")DFeldoF⇒WENNFEHLER(DFeld;999)
    19O2[:O11]:=WENNFEHLER(INDEX(Tab!G:G;AggregateXk(15;6;DFeld;ZEILE(E1)));"")DFeld⇒ZEILE($A$1:$A$99)/(INDEX($B$1:$F$99;;VERGLEICH("x";$B$1:$F$1;))="ja")

    Luc :-?

    Bild

    Betrifft: AW: ach ... Luc ...
    von: ... neopa C

    Geschrieben am: 22.01.2016 09:59:20
    Hallo Luc,
    ... Deine Argumentationen beziehst Du aus Deinen Theorien und setzt voraus, dass diese das NonPlusUltra sind. Ich konnte Dir schon öfters an konkreten Beispielen aufzeigen, dass diese jedoch weder hieb- noch stichfest sind. Ich orientiere mich aus meiner Sicht eher an Lösungen. Diese können natürlich durchaus manchmal inkorrekt sein (Keiner ist fehlerfrei) oder auch unvollständig. Wenn dies der Fall ist, korrigiere bzw. ergänze es und ich bin dankbar.
    Bzgl. Deiner Theorien und oder schlussfolgernden Aussagen, will ich mich aber jetzt nicht wiederholen, was ich schon in früheren Beiträgen entgegnet hatte.
    Hier und jetzt dazu nur noch ein kleines Beispiel bezogen auf Deinen letzten Beitrag.
    Glaubst Du wirklich, dass ich mir nichts dabei gedacht habe, die AGGREGAT()-Formel (bei Dir in I2) einer "klassischen" Matrixformel, wie Du sie in J2 gegenübergestellt hast (und wie ich sie so noch bis März 2015 selbst angeboten hätte), vorzuziehen?
    Ein Vergleich der Ergebnis beider Formeln ergibt natürlich, dass diese identisch sind und sie in Ihrer Konstruktion ähnlich. Nur kommt die AGGREGAT()-Formel ohne "{}" und ohne eine zusätzliche Funktion (hier WENNFEHLER(), meist WENN() aus) ...
    Doch hab ich mich nun für diesen thread entschieden: schade um unsere Zeit, diese Diskussion weiter zu führen. Ich kenne Deine Meinung und Du hast ja mein Fazit: dazu siehe meinen Beitrag hier im thread: belassen wir es doch einfach dabei, dass ... - von ... neopa C am 18.01.2016 08:30:24 auch schon gelesen und akzeptiert.
    Gruß Werner
    .. , - ...

    Bild

    Betrifft: Nachdem ich deinen Betreff gesehen hatte, ...
    von: Luc:-?

    Geschrieben am: 22.01.2016 13:38:45
    …Werner,
    musste ich schon annehmen, dass du wiedermal uneinsichtig sein würdest. Schlimmer, dass du den entschei­denden Nachtrag (Noch etwas…) gar nicht mehr gelesen hast. Das wird dir aber nichts nutzen, denn immer, wenn ich so ein abenteuerlich-unratio­nelles AGGREGAT-Konstrukt mit Arg1=14|15 und Auswahl nur eines Elements, um den zuvor genannten Effekt zu erreichen, sehe, werde ich auf diesen verweisen.
    Das hat schon nichts mehr mit dem Ausloten der AGGREGAT-Möglichkeiten zu tun, sondern ist nur noch formelverliebte Bastelei als Selbstzweck. Man sollte dabei aber auch an das denken, was im Hintergrund abläuft. Und wenn ich sage, dass deine künstlich vereinzelte Fml in jeder Zelle inkl ihrer Datenfeld-Argumente neu berechnet wdn muss, dann ist das eine überprüfbare Tatsache und nicht einfach nur eine Behauptung meinerseits.
    Detlef (Shift-Del), der viell als Erster diese Fkt (angeblich ohne Zugangsmöglichkeit zu ihr) angewendet hat, hat das getan, um aus einem erst in der GesamtFml gebildeten Datenfeld den Median zu berechnen, allerdings über ein Quantil (engl percentile). Darauf kann er eigentl nicht ohne Probieren gekommen sein, sonst hätte er wohl Nr 12 (Median) benutzt, was aber aus den von mir genannten Gründen nicht fktioniert (hätte). Was du im Bsp machst, ist per benannter Fml auch und rationeller zu erreichen, also ziemlich überflüssig.
    Fazit: AGGREGAT ist auf dem Anwendungsgebiet, für das es gedacht ist, sinnvoll, gut und nützlich. Darauf sollte man sich denn auch konzentrieren und nur in Ausnahmefällen mit Datenfeldern experimentieren, zumal solchen, bei denen die Fkt kaum nützt (die einzige anwendbare Option wäre das Ersetzen bereits im Datenfeld vorhandener Fehler, was man bei Datenfeldern aber auch anderweitig erreichen kann!). Und das dürfte stets bei Arg1=14|15 der Fall sein, die selbst in BedingtFormat- und Gültigkeitsregeln verzichtbar sein dürften.
    Entschuldige bitte den etwas rauheren Duktus meiner AW, aber meinst du nicht, das jemand, der bereits Dtzde, wenn nicht gar Hdte UDFs, darunter hochkomplexe, pgmmiert hat, eine gut begründete Ahnung davon haben könnte, wie die MS-Pgmmierer bei der Umsetzung eines FktsAlgorithmus vorgegangen sind, warum also eine xlStandardFkt so fktioniert wie sie es tut?! Sowohl UDFs als auch xlStandardFktt sind Pgmm, die einer immanenten Logik folgen, die einerseits auf dem umzusetzenden Algorithmus und andererseits auf den Regeln der jeweiligen Sprache und den Vorgaben und Möglichkeiten des HptPgms (Xl) beruht. Eine VBA-UDF ist nicht irgendetwas Abgehobenes, quasi zwischen Baum und Borke, und eine xlStandardFkt kein davon völlig unterschiedener Zauberstab, den man nur richtig zu schwingen lernen muss, sondern beide beruhen auf prinzipiell gleicher Logik (der einzige Unterschied besteht in der PgmmierSprache und den Zugriffsmöglichkeiten eines MS-Pgmmieres im Ggsatz zu denen eines VBAlers). Es kommt also in beiden Fällen nur heraus, was auch dafür vorgesehen wurde, wobei es natürlich auch mal passieren kann, dass mehr heraus­kommt als ursprünglich angedacht war. Das hängt dann schon mal von unterschiedlichen „Pgmmierer­Handschriften“ u/o der Komplexität des Pgms ab… ;-]
    Gruß+schöWE, Luc :-?

    Bild

    Betrifft: AW: hatte schon Deinen Zusatzbeitrag gelesen ...
    von: ... neopa C

    Geschrieben am: 22.01.2016 22:18:51
    Hallo Luc,
    ... ich hatte nur meine Antwort darauf aus Versehen nicht diesen zugeordnet.
    In meinem Beitrag von Heute Morgen findet sich ein eindeutiger Beweis dafür, dass ich Deinen Beitrag nicht nur gelesen hatte, denn ich bezog mich sogar auf diesen. Womit sich aber auch feststellen lässt, dass Du meinen Beitrag nicht gelesen hattest!
    Deine Fähigkeiten als VBAler und insbesondere Verdienste bzgl. Erstellung von UDFs hab ich nie in Abrede gestellt und werde es nicht tun. Aber um die ging und geht es zumindest aus meiner Sicht in dieser spez. Diskussion nie. Kann es ja auch nicht gehen, weil mir da die Grundlagen fehlen, wie Du wissen solltest.
    Doch verstehe ich von Excel-Formelkonstrukten mittlerweile soviel, dass ich eben diesbzgl. bei bestimmten Themen anderer Meinung bin als Du.
    Ich erwarte nicht von Dir, dass Du das akzeptierst, aber verlange bitte auch von mir, dass ich mich Deinen Meinungen "einsichtig" anschließe, solange diese für mich eben nicht tragfähig sind.
    Gruß Werner
    .. , - ...

    Bild

    Betrifft: Nun gut, das ist aber Empirie, nicht Kenntnis ...
    von: Luc:-?

    Geschrieben am: 23.01.2016 04:11:09
    …(bzw Vorstellung von) interner(/n) Abläufe(n), Werner,
    wie du ja selbst immer wieder betonst! Und was heißt „nicht tragfähig“? Es ist doch ganz leicht feststellbar und damit auch „einzu­sehen“, dass eine einzelne ZellFml in jeder Zelle, in der sie steht, komplett neu berechnet wdn muss. Das ist bei mehrzelli­gen Matrix- und wohl auch benannten Fmln eben nicht so - sie wdn nur 1-2mal komplett berechnet und die Ergebniswerte auf alle zuge­hörigen, also markierten Zellen verteilt. Wurden zuwenig markiert, fehlen Werte, sind es zuviel, erscheint in diesen Zellen der Fwert #NV. Meine Bspp mit benannten FmlTeilen wirken quasi wie INDEX - die benannte Fml wurde extern berechnet und die Zell­Fml holt nur den jeweiligen Ergebniswert ab. Das ist allemal rationeller als die Fml immer wieder komplett neu zu berechnen. Bei wenigen Daten macht das ja nichts aus, aber bei sehr vielen schon. Du versuchst doch selber stets volatile Fktt zu vermeiden, hier aber verursachst du rechnerischen Mehraufwand, wenn auch nicht andauernd wie bei INDIREKT & Co.
    Ich habe deine AW gelesen, aber mir fiel die von dir erwähnte Eindeutigkeit nicht auf, da du auf den HptPkt meiner Ergänzung ja gar nicht eingegangen bist, weshalb ich alle evtl Bezüge nur auf meinen Erst-BT bezogen hatte, worauf mir auch dein Betreff hinzudeuten schien. Es ist nämlich eindeutig und nachweislich so, dass Xl grundsätzlich alle Werte eines Datenfeldes ermittelt, nur nicht immer alle weiterverwendet. Die Fktt, die das vermögen, greifen wohl direkt auf diese Schnittstelle zu, wobei es dabei Grenzen gibt. Anders sieht es bei skalar erwarteten Argumenten aus. Da ist idR nicht unbedingt zu erwarten, dass ein Datenfeld über ggf hier übergebene Datenfelder bzw Bereiche aufgebaut wird. Das kann man schon am Fml-Assi ablesen. Hierfür ist idR MxFml-Form zwingend erforderlich, ja, es sieht beinahe so aus, als ob das dann auch für benannte Fmln gelten würde. INDEX ist exemplarisch dafür (keine Überlistung möglich).
    So, jetzt habe ich es aber doch noch getan, obwohl ich es eigentlich für überflüssig halte. Die neueste Version meiner Bsp-UDF enthält nun auch eine interne Selbstauswertung, was in deinem Sinne quasi Matrix(formel)funktionalität bedeutet. Da die vbFkt Evaluate genauso wie die XLM-Fkt AUSWERTEN interne Xl-Mechanismen in Anspruch nimmt, also so etwas wie eine verborgene 2.Xl-Instanz, kann man einen FmlText nicht auswerten, wenn er eine Fkt enthält, die dabei selber aktiv auf diesen Mechanismus zugreift. Aber meine diesbzgl Erweiterung ist optional, weshalb das für FmlTexte mit dieser Fkt nur fallweise zutrifft. Das bedeutet aber auch, dass Xl tatsächlich alle Werte berechnet und die Fkt dann daraus den gewünschten auswählt, denn hierbei ist dann auch keine MatrixFmlForm erforderlich wie im Folgenden zu sehen ist:
     IJKLMNOP
    1AGGREGAT 1zellig{KKLEINSTE 1zellig}{AggregateXk 1zellig}{AggregateXk m-zellig}{AGGREGAT m-zellig}KKLEINSTE 1zelligAggregateXk 1zelligAggregateXk 1zellig*
    2User1@xyz.deUser1@xyz.deUser1@xyz.deUser1@xyz.deUser1@xyz.deUser1@xyz.deUser1@xyz.deUser1@xyz.de
    3User3@xyz.deUser3@xyz.deUser3@xyz.deUser3@xyz.deUser3@xyz.deUser3@xyz.deUser3@xyz.deUser3@xyz.de
    4User8@xyz.deUser8@xyz.deUser8@xyz.deUser8@xyz.deUser8@xyz.deUser8@xyz.deUser8@xyz.deUser8@xyz.de
    5User13@xyz.deUser13@xyz.deUser13@xyz.deUser13@xyz.deUser13@xyz.deUser13@xyz.deUser13@xyz.deUser13@xyz.de
    6User16@xyz.deUser16@xyz.deUser16@xyz.deUser16@xyz.deUser16@xyz.deUser16@xyz.deUser16@xyz.deUser16@xyz.de
    7User18@xyz.deUser18@xyz.deUser18@xyz.deUser18@xyz.deUser18@xyz.deUser18@xyz.deUser18@xyz.deUser18@xyz.de
    8User22@xyz.deUser22@xyz.deUser22@xyz.deUser22@xyz.deUser22@xyz.deUser22@xyz.deUser22@xyz.deUser22@xyz.de
    9User23@xyz.deUser23@xyz.deUser23@xyz.deUser23@xyz.deUser23@xyz.deUser23@xyz.deUser23@xyz.deUser23@xyz.de
    10User24@xyz.deUser24@xyz.deUser24@xyz.deUser24@xyz.deUser24@xyz.deUser24@xyz.deUser24@xyz.deUser24@xyz.de
    11User26@xyz.deUser26@xyz.deUser26@xyz.deUser26@xyz.deUser26@xyz.deUser26@xyz.deUser26@xyz.deUser26@xyz.de
    12xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    13I2[:I11]:=WENNFEHLER(INDEX(Tab!G:G;AGGREGAT(15;6;ZEILE(A$1:A$99)/(INDEX(Tab!$B$1:$F$99;;VERGLEICH("x";Tab!$B$1:$F$1;))="ja"); ZEILE(A1))); "")
    14J2[:J11]: {=WENNFEHLER(INDEX(Tab!G:G;KKLEINSTE(WENNFEHLER(ZEILE(A$1:A$99)/(INDEX(Tab!$B$1:$F$99;;VERGLEICH("x";Tab!$B$1:$F$1;))="ja");999);ZEILE(A1))); "")}
    15K2[:K11]: {=WENNFEHLER(INDEX(Tab!G:G;AggregateXk(15;6;ZEILE(A$1:A$99)/(INDEX(Tab!$B$1:$F$99;;VERGLEICH("x";Tab!$B$1:$F$1;))="ja");ZEILE(A1)));"")}
    16L2:L11: {=WENNFEHLER(INDEX(Tab!G:G;AggregateXk(15;6;ZEILE(A$1:A$99)/(INDEX(Tab!$B$1:$F$99;;VERGLEICH("x";Tab!$B$1:$F$1;))="ja");ZEILE(A1:A10)));"")}
    17M2:M11: {=WENNFEHLER(INDEX(Tab!G:G;AGGREGAT(15;6;ZEILE(A$1:A$99)/(INDEX(Tab!$B$1:$F$99;;VERGLEICH("x";Tab!$B$1:$F$1;))="ja"); ZEILE(A1:A10))); "")}
    18N2[:N11]:=WENNFEHLER(INDEX(Tab!G:G;KKLEINSTE(DFeldoF;ZEILE(A1))); "")DFeldoF⇒WENNFEHLER(DFeld;999)
    19O2[:O11]:=WENNFEHLER(INDEX(Tab!G:G;AggregateXk(15;6;DFeld;ZEILE(A1)));"")DFeld⇒ZEILE($A$1:$A$99)/(INDEX($B$1:$F$99;;VERGLEICH("x";$B$1:$F$1;))="ja")
    20P2[:P11]:=WENNFEHLER(INDEX(Tab!G:G;AggregateXk(-15;6;ZEILE(A$1:A$99)/(INDEX(Tab!$B$1:$F$99;;VERGLEICH("x";Tab!$B$1:$F$1;))="ja");ZEILE(A1)));"")* intern evaluiert

    Die neue Version der UDF sieht dann so aus:
    Rem Aggregat f.1 Datenfeld aus Ausdruck (eXpression)
    '   als Arg3 u.ggf eines als Arg4 f.Arg1>13; Umwandl
    '   1es Bereichs in DatFeld; nur Input-FWert-Ignorg!
    '   Arg1: <0 Evaluierg, 0 nur Arg3-Wiedergabe, sonst
    '   wie b.Aggregate; Arg2: 0/1/4/5 oWirk, 2/3/6-9 F-
    '   Wert-Auslass->0|"" bzw -Ersatz durch ""/1 (8/9);
    '   Arg3: ZBer/Ausdr->DFeld; Arg4: ohne/Kl<-Arg1>13.
    '   Achtung! Neg Arg1 vhindrt ext FmlText-Evaluierg!
    '   Vs1.2 -LSr -cd:20160120 -1pub:20160120herber -lupd:20160122n
    Function AggregateXk(ByVal Funktion As Integer, ByVal Optionen As Integer, _
    ByVal DatenfeldAusdruck, Optional ByVal k)
    Const myName$ = "aggregatexk("
    Dim p As Long, sx As Long, sz As Long, zx As Long, zz As Long, _
    q(1) As Long, FTxt As String, erg, kw, xw, zwErg As Variant
    On Error GoTo fx
    If Funktion < 0 Then
    FTxt = "(-" & Split(LCase(Application.ThisCell.Formula), myName)(1)
    For p = 1 To Len(FTxt)
    q(0) = q(0) - CInt(Mid(FTxt, p, 1) = "(")
    q(1) = q(1) - CInt(Mid(FTxt, p, 1) = ")")
    If q(1) = q(0) Then Exit For
    Next p
    FTxt = myName & Mid(FTxt, 2, p - 1 + CInt(p > Len(FTxt)))
    AggregateXk = ActiveSheet.Evaluate(FTxt): Exit Function
    End If
    With WorksheetFunction
    If TypeName(DatenfeldAusdruck) = "Range" Then
    If DatenfeldAusdruck.Cells.Count > 1 Then
    DatenfeldAusdruck = .Transpose(.Transpose(DatenfeldAusdruck))
    Else: DatenfeldAusdruck = Array(DatenfeldAusdruck)
    End If
    End If
    If Not IsMissing(k) Then
    If TypeName(k) = "Range" Then
    If k.Cells.Count > 1 Then k = .Transpose(.Transpose(k))
    End If
    End If
    End With
    On Error Resume Next
    sz = UBound(DatenfeldAusdruck, 2) + 1 - LBound(DatenfeldAusdruck, 2)
    zz = UBound(DatenfeldAusdruck, 1) + 1 - LBound(DatenfeldAusdruck, 1)
    On Error GoTo fx: ReDim zwErg(zz - 1, sz - 1)
    Select Case Optionen
    Case 0, 1, 4, 5                     'entfällt hier f.DFeld!
    zwErg = DatenfeldAusdruck
    Case 2, 3, 6, 7, 8, 9               'dito, nur FWertErsatz!
    For Each xw In DatenfeldAusdruck
    If Not IsError(xw) Then
    zwErg(zx, sx) = xw
    ElseIf Optionen > 7 Then
    zwErg(zx, sx) = Array("", 1)(Optionen - 8)
    End If
    zx = (zx + 1) Mod zz: sx = sx - CInt(zx = 0)
    Next xw
    Case Else: Err.Raise xlErrNA
    End Select
    With Application
    If Funktion > 13 And IsArray(k) Then
    On Error Resume Next
    sz = UBound(k, 2) + 1 - LBound(k, 2)
    zz = UBound(k, 1) + 1 - LBound(k, 1)
    On Error GoTo fx
    kw = k: zx = 0: sx = 0: ReDim erg(zz - 1, sz - 1)
    For Each k In kw
    On Error Resume Next: GoSub kf: On Error GoTo fx
    erg(zx, sx) = AggregateXk: AggregateXk = Empty
    zx = (zx + 1) Mod zz: sx = sx - CInt(zx = 0)
    Next k
    AggregateXk = erg: Exit Function
    End If
    kf:     Select Case Funktion
    Case 0:  AggregateXk = zwErg
    Case 1:  AggregateXk = .Average(zwErg)
    Case 2:  AggregateXk = .Count(zwErg)
    Case 3:  AggregateXk = .CountA(zwErg)
    Case 4:  AggregateXk = .Max(zwErg)
    Case 5:  AggregateXk = .Min(zwErg)
    Case 6:  AggregateXk = .Product(zwErg)
    Case 7:  AggregateXk = .StDev_S(zwErg)
    Case 8:  AggregateXk = .StDev_P(zwErg)
    Case 9:  AggregateXk = .Sum(zwErg)
    Case 10: AggregateXk = .Var_S(zwErg)
    Case 11: AggregateXk = .Var_P(zwErg)
    Case 12: AggregateXk = .Median(zwErg)
    Case 13: AggregateXk = .Mode_Sngl(zwErg)
    Case 14: AggregateXk = .Large(zwErg, k)
    Case 15: AggregateXk = .Small(zwErg, k)
    Case 16: AggregateXk = .Percentile_Inc(zwErg, k)
    Case 17: AggregateXk = .Quartile_Inc(zwErg, k)
    Case 18: AggregateXk = .Percentile_Exc(zwErg, k)
    Case 19: AggregateXk = .Quartile_Exc(zwErg, k)
    Case Else: Err.Raise xlErrNA
    End Select
    If Not IsEmpty(kw) Then Return
    End With
    fx: If CBool(Err.Number) Then AggregateXk = CVErr(Err.Number)
    End Function
    Um das zu erreichen, muss Arg1 negativ angegeben wdn, denn ich wollte das aus dem o.g. Grund nicht generell vornehmen, son­dern zur Wahl stellen ohne dabei wesentlich von der ArgumenteZahl und -Form von AGGREGAT abzuweichen. Außerdem habe ich noch die Funktion 0 spendiert, bei deren Angabe nur Arg3 in aufbereiteter Form wiedergegeben wird, und außerdem die zusätzli­chen Optionen 8 und 9. 2/3/6/7 tragen nichts in das aufbereitete Datenfeld ein, wenn im Original ein F-Wert steht. Dadurch wird hier idR eine 0 erscheinen, bei reinen TextDatenfeldern ggf ein "". Mit Option 8 wird dann ein LeerText eingetragen, mit 9 eine 1.
    Gruß, Luc :-?

    Bild

    Betrifft: Für Nachnutzer bzw -leser, nicht f.Nichtsnutze!
    von: Luc:-?

    Geschrieben am: 25.01.2016 01:27:49
    Hier geht's dann noch etwas weiter.
    Luc :-?

    Bild

    Betrifft: Nachtrag bzgl 'matrixfähig'
    von: Luc:-?

    Geschrieben am: 21.01.2016 04:54:30
    Ich hatte nie verstanden, was zB mit AGGREGAT ist erst ab 14 „matrixfähig“ gemeint war/ist und das mit Matrix­Fmln und Matrix­Fml­Fähigkeit in Zusammen­hang gebracht, denn eine Matrix kann von einem Zell­Bereich oder einem Daten­feld aufge­spannt wdn. Beides kann auch als Array (MS meint hier wohl eher Ersteren) bezeichnet wdn. In VBA ist ein Array aber stets ein Daten­feld, das in Xl-Fmln aus einem Zell­Bereich bspw schon durch eine einfache Manipu­lation wie Negati­vierung (voran­gestelltes -) oder Positivie­rung (dito --) bzw Trans­formation erzeugt wdn kann. Dadurch geht der Zell­Bezug verloren und bis auf Igno­rierung (hier dann besser Erset­zung) von Fehler­werten sind die AGGREGAT-Optionen (Arg2) hin­fällig (auch Option 4 ist nicht möglich, da es LeerZellen in Daten­feldern nicht geben kann, diese wdn bekanntlich zu 0 oder müssen als Leer­Text "" ange­geben wdn). Schon deshalb dürfte es sich bei dieser auf AGGREGAT bezogenen „Fähig­keit“ ggf nur um einen Pgmmier­Lapsus handeln und die evtl bessere Verwend­barkeit in Bedingt­Format­Regeln (wozu eigentl?) wird durch den Wegfall der Annahme­Verwei­gerung von Fmln mit Daten­feldern als Argument erreicht. Dadurch wird aber erst der Versuch provoziert (bzw entsteht die V~ung), das auszu­nutzen, um evtl noch ein kleines Bisschen an Fml­Länge zu sparen. Das ist sicher nicht „im Sinne des Erfinders“ und deshalb genauso änderungs­gefährdet wie manches Andere. Aller­dings sind MS-seitige nach­träg­liche Eingriffe in einen bestehenden Fkts­Apparat eher unwahr­scheinlich; idR wdn höchstens zusätzliche Dot-Varianten geschaffen, die wohl die betroffenen Fktt transparenter für einen immer weniger deutungs­befähigten Kunden­kreis machen sollen… ;-]
    Wer also partout Datenfelder (die o.g. ominösen Matrizen) mit AGGREGAT benutzen will, sollte auf (mein) AggregateXk (viell gibt's ja auch noch mal ein AggregateXp - zu Variante2!) oder doch gleich die Original-Fktt (ganz ohne AGGREGAT) ausweichen!
    Luc :-?

    Bild

    Betrifft: AW: zu Deine letzten Teilaussagesatz: Nein! owT
    von: ... neopa C
    Geschrieben am: 21.01.2016 10:12:07
    Gruß Werner
    .. , - ...

    Bild

    Betrifft: Siehe oben! owT
    von: Luc:-?
    Geschrieben am: 21.01.2016 14:20:18
    :-?

     Bild