Neuland ... Aggregat ... neopa C

Beiträge zum Forumthread

Beiträge zu diesem Forumthread

Betreff

Datum

Anwender

…Werner?
Die AGGREGAT()-Formeln … kommen dafür aber mit weniger Funktionen als Matrixformeln aus.
Schon AGGREGAT an sich würde ja als Fkt gewertet wdn müssen. Hinzu kommen dann die intern aufzurufenden Fktt lt IDNr im 1.Argument, denn AGGREGAT ist keine SuperFkt, die alles intern gurchgängig berechnet, sondern einfach nur eine vorgeschaltete Routine, die das DatenMaterial der Argumente ab dem 3. nach Vorgabe von Argument2 bereinigt und es dann erst intern an die Xl-Fkt lt Argument1 weitergibt.
Das ist auch ein Grund für die Teilung in Normal- und sog Matrix-Version. In den „NormalVarianten“ 1…13 erlauben die entsprd Xl-Fktt mehrere gleichartige Argumente, weshalb das dann auch bei AGGREGAT so ist. In den „MatrixVarianten“ ab 14 sind nur noch 2 (im Prinzip verschiedenartige) Argumente erlaubt, was ebenfalls der Argumentierung der dort repräsentierten Fktt entspricht. In diesen Varianten als HptArgument angegebene komplexe Ausdrücke wdn, wie xl-üblich, zuerst berechnet und dann als komplettes Datenfeld (daher die Bezeichnung als MatrixVersion) an AGGREGAT weitergereicht, das dann diese Daten lt Vorgabe filtert und dann erst an die betreffende Xl-Fkt weiterreicht (das ist übrigens bei TEILERGEBNIS genauso, nur entfallen bestimmte Filterungen).
Da die AGGREGAT-Pgmmierer hier ihren MSO-Interface-Zugang nutzen können, ist das auch sehr schnell, aber wohl kaum schneller als die AGGREGAT-lose Fml, es sei denn, die Optimierung der Fmln der genannten Ausdrücke würde ebenfalls von AGGREGAT übernommen, was ich für kaum wahrscheinlich halte, denn auch der Xl-Fml-Interpreter optimiert nicht alles (und in diese Abläufe müsste dann ja eingegriffen wdn, was evtl möglich wäre, wenn sie's denn hätten tun wollen).
Somit käme auf jede von AGGREGAT aufgerufene Xl-Fkt noch AGGREGAT selbst, von zur Erzeugung eines evtl verwendeten Datenfeldes in der 2.Version benutzten Fktt ganz zu schweigen. Folglich wird AGGREGAT bei einer 1:1-Umsetzung einer singularen MatrixFml wohl niemals weniger Fktt verwenden als diese, sondern immer eine mehr. Das legt nahe, dass sie auch nicht für diesen Zweck geschaffen wurde, sondern ihre HptAufgabe die erweiterte DatenFilterMöglichkeit ist. Wegen aller FilterMöglichkeiten wurde sie primär, ebenso wie TEILERGEBNIS, auch auf ZellBereiche beschränkt, obwohl das für die enthaltenen Fktt nicht erforderlich wäre. Nur im Teil ab FNr 14 hat man diese Bremse (nachträglich u/o bestimmten Zweck/Kundenwunsch?) aufgehoben.
Das manche Xl-Fktt F-Werte tolerieren und andere nicht, mag am mathematischen Hintergrund der jeweiligen Fkt liegen u/o als Warnung vor Unstimmigkeiten gedacht gewesen sein, die besser erst beseitigt wdn sollten. Mit AGGREGAT wird dem Anwender automatisch auch dafür die (fast → rotes Fehler-Dreieck) alleinige Verantwortung übertragen.
Morrn + schöSo, Luc :-?
Besser informiert mit …

…„Pferdefüße“, Werner, ;-]
und die finden sich zT in Deinen Fmln:
1. vergleichst Du letztlich Äpfel mit Birnen, denn die beiden Fmln sind nicht gleichwertig;
2. baust Du zusätzlich eine weitere, nicht jedem gleich ersichtliche Erschwernis ein, um eine von beiden Fmln als 0 gewertete Leerzelle auszuschließen, was ja nun nicht unbedingt nötig gewesen wäre, denn die TextZahl hätte ja auch schon gereicht;
3. bewahrst Du mit der AGGREGAT-Fml diese TextZahl vor dem EntdecktWerden, falls jemand das rote Dreieck nicht beachtet bzw bemerken kann, was in anderen Fmln zu Fehlern führen könnte.
Wollte man beide Fmln gleichwertig gestalten, liefe das …
1. im AGGREGAT-Fall ebenfalls auf eine (singulare) MatrixFml hinaus;
2. käme in beiden Fällen auch das gleiche Ergebnis heraus, je nach Fml mal 12 und mal 13.
Dadurch ist Dein einfaches Bsp eher eine Bestätigung meiner Argumentation bzgl bewusst eingebauter FehlerErzeugung, um die Fml kurz halten zu können; vgl dazu die folgd Fml-Alternativen:
13 ⇐ {=AGGREGAT(15;6;WENN(F2:F9="a";G2:G9);2)}
#DIV/0! ⇐ {=KKLEINSTE(G2:G9/(F2:F9="a");2)}
12 ⇐ {=AGGREGAT(15;6;WAHL((F2:F9="a")*(G2:G9"")+1;"";--G2:G9);2)}
12 ⇐ {=KKLEINSTE(WAHL((F2:F9="a")*(G2:G9"")+1;"";--G2:G9);2)}
12 ⇐ {=KKLEINSTE(WENNFEHLER(G2:G9/(F2:F9="a");"");2)}
13 ⇐ {=KKLEINSTE(WAHL((F2:F9="a")+1;"";G2:G9);2)}
Bei den letzten beiden habe ich auf die AGGREGAT-Alternative verzichtet, denn das wäre im 1.Fall ja idR Quatsch und im 2. analog der WENN-Variante.
Natürlich wird den (Gelegenheits-)Nutzer kaum interessieren, was intern abläuft, den Profi sollte es aber, denn hier kommt ggf die Performance-Frage ins Spiel. Hierüber wurde ja auch schon diskutiert. Und wenn Du die Anzahl eingesetzter Fktt in den Vgl einbeziehst, musst Du bei Verteiler-Fktt auch Interna einbeziehen, denn letztlich wdn die Daten von genau den Fktt lt Arg1 verarbeitet, nicht von AGGREGAT (bzw TEILERGEBNIS). Das ist auch wesentlicher, als nun die durch spezifischen Fml-Abschluss bei MatrixFmln erzeugten {}, denn die sind nur für den Nutzer da, Xl würde der Fml-Abschluss allein schon ausreichen, denn dadurch bekommt die Fml intern ein anderes Etikett. Das kann in anderer Calc-Software auch anders geregelt sein (in LO/OOcalc anhaken im Fml-Assi, in einer Software aus der Linux-Welt formal ähnlich, aber es wird statt {}-Klammerung eine ganze Matrix automatisch nachgestellt). Nur das Problem hat letztlich jede gute Calc-Software, dem Pgm muss gesagt wdn, ob alle EingangsDaten u/o Ergebnisse verwendet wdn sollen, denn berechnet wird (wie in benannten Fmln) idR (bzw sonst) alles.
Dein Vgl von SUMME mit WENN-Konstrukt als Argument mit SUMMENPRODUKT hinkt ebenfalls. Es ist aus heutiger Sicht nicht klar erkennbar, ob Letztere genauso alt ist wie Erstere, aber im Prinzip haben beide Fktt unterschiedl Aufgaben (wie die anderen, idR kaum benutzten SUMME~-Fktt auch). Im 1.Fall handelt es sich um eine einfache Summierung, die man auch auszugsweise gestalten kann, im 2. primär um etwas ganz anderes, nämlich ein sog Skalarprodukt (mitunter auch Produkt[e]summe genannt). Genau das wird auch in der Hilfe dazu erläutert. Dass nun einige Tüftler darauf verfallen könnten, diese Fkt zu zweckentfremden, war nicht vorgesehen, aber möglich (wie man sehen kann). Und natürlich kann man ein Skalarprodukt auch direkt bilden, genauso wie die anderen SUMME~-Fktt auch (demggüber fallen die neueren und neuesten ~WENNs-Fktt in eine ganz andere Kategorie, die nicht der gleichen Logik folgt wie die alten, ursprüngl Xl-Fktt!).
Das, was man AGGREGAT und diversen anderen Xl-Fktt vorwerfen kann, richtet sich eigentlich an das MS-Management, denn das trägt letztlich die Verantwortung für die Entstehung eines Konglomerats aus Fktt, die zT recht unterschiedlichen Logiken folgen und so in ihrer Gesamtheit den Eindruck von Uneinheitlichkeit und mitunter geradezu Willkür erwecken. Das ganze System ist längst nicht mehr aus einem Guss und war es viell auch nie…
Aber nun gut, dem Nutzer bleibt ohnehin nichts anderes übrig, als sich damit zu arrangieren, wollte er nicht auf SelbstGeschriebenes oder gar andere Systeme ausweichen…
Morrn, Luc :-?

Beliebteste Forumthreads (12 Monate)

	A	B	C	D	E	F	G	H
9
10		31	45	64	16	68	93
11		x	y	x	y	x	x
12		y	y	x	y	x	y
13
14		MAX(X/Y)	93
15		MIN(X/Y)	31
16		MAX(X/X)	68
17		MIN(X/X)	64
18		MAX(Y/Y)	45
19		MIN(Y/Y)	16

	F	G	H	I
1	Filter	Werte		12
2	a	15		13
3	b	6
4	a	13
5	a	12
6		3
7	a	9
8	b	17
9	a

/

55 Beiträge zum Forumthread Beiträge zu diesem Forumthread

Beliebteste Forumthreads (12 Monate)

Beliebteste Forumthreads (12 Monate)

55
Beiträge zum Forumthread

Beiträge zu diesem Forumthread