sverweis verschachtelt

Beiträge zum Forumthread

Beiträge zu diesem Forumthread

Betreff

Datum

Anwender

…benannte Fml hat, Werner,
denn der erfüllt ja schon den HptGrund, warum du AGGREGAT-14/15 einsetzt → 1zellige NormalFmln ganz ohne {}! Allerdings dürfte dabei der „Effekt“ fehlen, dass dieser Teil der AGGREGAT-Fml in jeder Zelle aufs Neue berechnet wdn muss. Meine Auffassung ist, dass benannte Fmln 1malig bei DateiÖffnung bzw BlattAktivierung berechnet wdn und ansonsten nur bei Änderung an ihren Input-Primärdaten (wie die meisten anderen Fmln ja auch). Mit der zugehörigen ZellFml wdn die bereits berechneten Ergebniswerte nur noch abgebildet. Sind die genannten Primärdaten adressfixiert (absolut bzw durch Wegbewegung der EinzelZellFml unbeeinflussbar), können diese ErgebnisPräsentationsZellFmln auch in unzusammenhängenden Zellen notiert wdn, sind also genauso flexibel wie gleichartige AGGREGAT-Fmln. Und diese Möglichkeit bietet Xl schon seit vielen Jahren, wenn nicht gar schon immer! Es besteht also gar kein ernsthafter Grund, AGGREGAT dafür einzusetzen! Nur, weil das geht, muss man es doch nicht machen! Die Gründe, die dagegen sprechen, kann man doch nicht einfach ignorieren, sei die AGGREGAT-Begeisterung auch noch so groß!
Höchstwahrscheinlich wird dieses AGGREGAT-„Fenster“ nicht einmal ernsthaft für die Fktt lt Nrn 16-19 benötigt, zumal ja bei einem Datenfeld als Arg3 allein das Ausfiltern von FehlerWerten als besondere neue Option (Arg2) verbleibt. Dafür gibt's jetzt aber schon WENNFEHLER, das hier völlig ausreicht.
Was deine Meinung zu mehrzelligen MatrixFmln betrifft, hat ja Daniel bereits (dankenswerterweise) ein Pro-Argument (→ vgl nächsten Absatz!) genannt, das bisher kaum thematisiert wurde. Ich hätte mir auch schon etliche Fmln „zerschossen“, wenn sich diese nicht so konsistent verhalten würden. Dem kann man ja mit entsprd TabAufbau rechnung tragen. Es muss ja auch kein Nachteil sein, dass innerhalb des von ihnen aufgespannten Arrays keine Zeilen/Spalten eingefügt wdn können. Soviel Mehrarbeit bedeutet eine gelegentliche Aktualisierung ja nun auch nicht. Wer allerdings dauernd daran ändern muss, muss sich auch fragen lassen, warum es so ist und ob er das nicht mit einem sinnvolleren TabAufbau vermeiden könnte!
Was die Auswahl des aktuellen Arrays betrifft, ist es aber nun leider so, dass nur ausgewählt wird, was bereits vorhanden ist, niemals die tatsächlich mögliche Größe. Und das ist ja genau das, was dir missfällt, Werner. Mir hat das schon vor Jahren missfallen (man muss ja immer abschätzen u/o ausprobieren, wieviel Zellen in ggf beide Richtungen es wdn) und ich hatte deshalb in den letzten ca 8 Jahren 2× versucht, dieses Problem auf unterschiedliche Weise zu lösen:

Zuerst 2008/9 mit der UDF FlexArr, die, unterstützt durch eine automatisch anlegbare EreignisProzedur und ein von ihr aufgerufenes Pgm, die von ihr umschlossene MatrixFml auf die MaximalGröße oder einen argumentierbaren Ausschnitt ausdehnt; man muss nur 2 Zellen auswählen, die die Richtung eines Vektors bzw der Reihe einer rechteckigen Matrix mit den meisten Elementen vorgeben. Außerdem sind noch einige andere Features eingebaut wie u.a. Wiederholung von Werten, ZwangsTransponierung und Übernahme des Formats der 1.Zelle (nebst angepasstem Übertrag von ZellRahmen) in alle unformatierten FolgeZellen (vgl unten!).

Jahre später, aber ebenfalls schon vor Jahren, im Zusammenhang mit in VerbundZellen verborgenen MatrixFmln, wobei ggf nur 1 Zelle verwendet wdn muss, die Anzeige dieser verborgenen Zellen mit allen aus einer evtl darin enthaltenen MatrixFml resultierenden Ergebnissen — quasi ein PlatzsparModell der TabKryptisierung.

Unter mehrfachem Einsatz von FlexArr hatte ich damals zB eine Fml entwickelt, mit der man das Kronecker-TensorProdukt darstellen (natürlich als mehrzellige MatrixFml!) und so auf eine spezielle Fkt nur dafür verzichten kann. Das kannst du (bzw wer will) ja mal mit StandardFmln versuchen, viell sogar mit 1zellig normalen und ggf AGGREGAT…! ;-]
Da das auch als Extra-Bsp in der Hilfe zu (m)einem AddIn enthalten ist, könnte ich das bei Interesse auch hier zeigen, nur nicht die UDF und ihre HilfsPgmm, auch, weil das zu umfangreich wdn würde.
Gruß, Luc :-?

…Rätsel, Werner; ;-)
A: Ich hatte jetzt 'ne Zwangspause in dieser Diskussion einlegen müssen, weil ich versucht habe, das Ganze auf feste Füße zu stellen. Das ist mir nur zT gelungen. Das HptProblem scheint darin zu bestehen, erst einmal eine geeignete TestMethode für die ab Xl14/2010 möglichen 6 Varianten einer Matrix bzw Vektor ergebenden Fml zu finden. Meine TestMethode hatte sich darauf verlassen, dass das Anklicken einer in eine Fml eingebundenen Zelle bei AutoKalk'Modus auch alle Berechnungen durchführt und man die dabei vergangene Zeit mit Timer in EreignisProzedur …_Calculate messen kann. Das hat zwar geklappt, nur sind die Ergebnisse verwirrend, denn die Unterschiede zwischen 5 Varianten sind relativ marginal und bewegen sich innerhalb der Toleranzen von Minimum nach Maximum, deren Unterschied leicht bis zum doppelten Minimum betragen kann. Das kann nur einerseits der Xl- und andererseits der Win(10)-Steuerung geschuldet sein (je öfter desto schneller!). Meine Prozessoren schienen dafür auch nur mit einem Bruchteil ihrer Kapazität zu arbeiten. Da das sicher immer so ist, kann ich dazu also kein abschließendes Urteil fällen, sondern muss es bei logischen Schlussfolgerungen belassen.
Eines haben meine Tests aber mit Sicherheit erbracht, Xl hat anscheinend ein Problem mit der EinzelwertWiedergabe von Datenfeldern aus benannten Fmln, also der von mir vorgeschlagenen Alternative für deine Art der AGGREGAT-Nutzung. Es sieht so aus, als ob dabei stets auch der Ausdruck neu berechnet wdn würde (was ich nicht ausgeschlossen hatte, aber als wenig wahrscheinlich befand). Das widerspricht eigentlich einer sinnvollen SteuerungsLogik und könnte interne Ursachen haben. Mit Vektoren von 10Tsd Werten, wie ich sie hierbei verwendet hatte, ist diese 6.Variante jedenfalls hoffnungslos überfordert, obwohl es bei 1000 noch so aussah, als ob sie schneller als die entsprd AGGREGAT-Variante wäre und der MxFmlVariante nicht nachstünde, die bei 1000 Werten auch doppelt so schnell wie die AGGREGAT-EinzelwertRückgabe zu sein schien. Es sieht beinahe so aus, als ob die Leistungsfähigkeit dieser speziellen AGGREGAT-Verwendung mit wachsender Datenmenge zunähme und auch noch relativ unabhängig von ihrer AngabeForm, wobei allerdings begründet davon ausgegangen wdn kann, dass die MxFml-Variante von AGGREGAT im Schnitt etwas schneller sein dürfte. Der interne Bereinigungs- und VerteilungsMechanismus scheint hierbei jedenfalls keinen relevanten ZeitFaktor darzustellen.
Das alles schließt natürlich nicht aus, dass man in anderer Hard- und Software-Umgebung bzw bei anderem „Versuchsaufbau“ auch zu etwas anderen Ergebnissen kommen könnte. Deshalb wäre es ggf sinnvoller, festzustellen, wie oft eine benannte Fml tatsächlich neu berechnet wird (bei einer Einzelwert-AGGREGAT-Fml dürfte das von der ZellAnzahl abhängen, falls nicht doch ein zellenübergreifender interner Abgleich erfolgt, der allerdings kaum feststellbar wäre). Bei MatrixFmln jedweder Art erfolgt das jedenfalls nur 1×, wie man schon bei einfachem Ersetzen feststellen kann.
B: Zur Vorabbestimmung des Platzbedarfs einer MatrixFml hatte ich mich ja bereits geäußert. Das kann man nur mit Abschätzen und Probieren erreichen, will man nicht, wie ich es könnte (aber meist nicht tue!), VBA einsetzen (vgl meine Bemerkungen zur UDF FlexArr!).
Warum Xl nun nicht mehr eine Matrix bei Berechnung markiert, wird wohl nur MS beantworten können. Möglicherweise haben sie deshalb dieses weitgehend unbekannte Feature spendiert…!?
C: Zu {SUMMENPRODUKT(…)} kann ich mich erinnern, so etwas in unseren früheren Diskussionen mal gezeigt zu haben, worauf du (viell war's aber auch WF?) geantwortet hattest, das läge ja auch an WENN! Außerdem bin ich mir sehr sicher, in unseren jüngeren Diskussionen zur sog Matrix(formel)funktionalität (viell kurz MFF oder MxFF) erwähnt zu haben, dass die Erkennung und Berechnung eines aus einem Ausdruck als Argument resultierenden Datenfeldes Grenzen hat — er darf nicht zu komplex sein! Es kann nämlich nicht davon ausgegangen wdn, dass der Pgmmierer das so gelöst hat, wie ich mit Vs1.2 von AggregateXk (dann ließe sich die Fkt nicht AUSWERTEN!).
Morrn, Luc :-?

Beliebteste Forumthreads (12 Monate)

	A	B	C	D	E
1	UV	Wert_1	Wert_2	Wert_3
2		01.	01.
3		01.	02.
4

	A	B	C	D	E
1	Kn	Wert_1	Wert_2	Wert_3
2	UV	01.	01.
3	W	01.	01.	01.
4	W	01.	01.	02.
5	.
6	.
7	UV	01.	02.
8	W	01.	02.	01.
9

19 Beiträge zum Forumthread Beiträge zu diesem Forumthread

VBA Beispiele zu verwandten Themen

Beliebteste Forumthreads (12 Monate)

Beliebteste Forumthreads (12 Monate)

19
Beiträge zum Forumthread

Beiträge zu diesem Forumthread