von Luc$:-? » 21. Sep 2017, 05:14
...Werner:
Vorbemerkung: So wie Dir wird's wahrscheinlich sehr vielen NormalNutzern bzgl meiner Ausführungen gehen, weshalb evtl eine Quintessenz erforderlich wäre... ;-)
Zu Deinen PktBezügen:
2. Lupo war ja bereits 'zurückgerudert'; hier sollte auch nur festgestellt wdn, dass es sinnvoller ist, eine .xlsx- mit einer .xlsb-Datei zu vgln. Fehlen in letzterer jedwede VBA-Pgmm und XLM-Fktt, wird sie idR kleiner als die erstere sein, wenn beide keine oder die gleichen HistorienInfos enthalten (was für Letzteres eher unwahrscheinlich ist, aber man kann diese ja auch löschen!). Zip hin oder her, es kommen bei .xlsm-Dateien noch diverse XML-Infos dazu und außerdem soll das Ganze dann ja auch universell mit anderen Systemen austauschbar sein. Das sollte den größeren Umfang erklären (was durch zippen eingespart wird, wird durch die Universalität wieder reingeholt und meist noch übertroffen).
4. Ja, das ist so und hat mit dem NamensKonzept zu tun. Das unterscheidet sich vom TabBlatt-Konzept in einem wesentlichen Pkt: Namen, in deren Bezug relative Adressen verwendet wdn, beziehen sich auch in der Wiedergabe im TabBlatt immer auf genau diesen Standort ihrer Notation dort. Folglich wird eine benannte Fml diesbzgl an den Standort der ihren Namen verwendenden Fml angepasst. Demzufolge wäre eine Abänderung solcher Bezüge im Prinzip unnötig, denn eine diesen Namen verwendende Fml im TabBlatt liefert nur in einer exakt korrespondierenden Zelle, Zeile bzw Spalte den richtigen Wert. Wird zB in A1:J10 eines Blattes eine Tabelle notiert und dafür eine SummenFml als benannte Fml mit relativer Adressierung angelegt, also =SUMME(Tab1!A1:J10), kann keine Fml, die ihren Namen verwendet, in einer Zelle auf dem gleichen Blatt angelegt wdn. Ihr Ergebnis wäre immer falsch! Auf einem anderen Blatt müsste diese Fml dann aber auch genau in A1 stehen, wenn diese Summe herauskommen soll. Mit jeder FolgeZelle verschiebt sich der summierte Bereich um eine Zeile u/o Spalte! Die ursprüngliche Bereichsangabe für A1 entspräche dann quasi nur Unter- und Obergrenzen des SummierungsBereichs, denn darüber hinaus würde eine solche Fml nur noch 0 liefern. Dass diese Grenzen nun nicht automatisch geändert wdn, wenn auf dem Daten- bzw AuswertungsBlatt Zeilen oder Spalten gelöscht oder hinzugefügt wdn, kann/muss Absicht sein, denn der Nutzer, der so etwas anwendet, sollte auch das Konzept dahinter kennen! Tut er so etwas also, muss das ebenfalls von ihm beabsichtigt sein, davon gingen die Erfinder wohl aus! Will man eine automatische Adress(-Teil-)Anpassung erreichen, muss man folglich (teil-)absolute Adressierung verwenden!
Auf diese Weise kann man bei Beachtung dieses Konzepts und entsprd angelegter MappenStruktur mit strikter Trennung von Daten- und AuswertungsTeil und intelligent gewählten Bezügen in der benannten Fml und ebenso gewählten Standorten im Berechnungsblatt leicht umgekehrte Kumulationen erzeugen, d.h., die Endsumme, zB Dezember, müsste ganz oben stehen, und die erste Einheit (Januar) ganz unten. Das fktt aber natürlich nur, wenn auf dem DatenBlatt auch nur die dafür benötigten Zeilen und Spalten genutzt wdn! Kommen nun DatenZeilen u/o -Spalten hinzu, wdn die derart sortiert ältesten nicht mehr einbezogen; umgekehrt (Löschung) können andere, neue Daten einbezogen wdn. Das sieht mir aber doch sehr nach Absicht aus! Unbedarfte Eingriffe könnten hierbei aber natürlich das ganze schöne Konzept aushebeln. Insofern ist das also nur etwas für Leute, die genau wissen, was sie tun, und hat mit Fmln (oder ihren Teilen) vor den Nutzern verstecken herzlich wenig zu tun!
Damit wäre auch eine Normierung aller NamensBezüge auf A1 nicht unbedingt erforderlich, es sei denn zu DokuZwecken (mit dem Xl-Tool).
Übrigens, in meiner auf das ursprüngl Problem bezogenen Datei hat eine Verschiebung von W1 keinerlei Auswirkungen, weil die benannten BZRanf- und -end-Fmln (voll-)absolut adressiert wurden, sich also dem anpassen! ;-]
Hier gilt also eher, soviel (teil-)absolut adressieren wie möglich, nicht wie nötig wie im TabBlatt!
7. Jein, nicht ganz! INDEX wird zwar im HptArgument eine ganze Matrix (als Datenfeld!) übergeben, die nachfolgd Argumente verlangen aber Einzelwerte, skalar oder als 1elementiges Datenfeld wie es bspw von ZEILE() und SPALTE() geliefert wird. Gibt man dort ebenfalls ein Feld an, variiert die Xl-Steuerung die über ihren Rahmen (und bei voll-relativer Adressierung wg der AutoAnpassung auch darüber hinaus; logisch ist hierbei, dass, wenn man ZEILE(1:$9) schreibt, ab Zeile10 die Zeile 9 wiederholt wird, und andersherum bzw voll-absolut adressiert, es immer Zeile1 ist). Insofern besitzt INDEX nur eine bedingte MatrixFktionalität, nämlich dann, wenn man Zeilen- u/o SpaltenArgument 0 setzt (das klappt aber schon beim 4., dem BereichsArgument nicht mehr, was aber der DarstellungsProblematik geschuldet sein wird bzw kann). Wendet man INDEX auf das jetzt hier genannte Bsp an, also auf die benannte SummenFml, fktt es nur mit diesen 0-Argumenten, wohl weil in diesem Fall kein Datenfeld wie beim MultiplikationsBsp aufgebaut wird, sondern sich nur die Grenzen verschieben, was man genauso auch mit dieser SummenFml (ohne INDEX) in einer ZellFml erreichen könnte (ebenfalls mit Wiederholung der GesamtSumme in allen datenhaltigen Spalten von FolgeZeilen und von 0 in darüber hinaus gehenden Spalten, was auf die Xl-übliche Bevorzugung buchhaltungsgerechter vertikaler SummenBildung hinzuweisen scheint, weshalb ja auch TEILERGEBNIS und AGGREGAT nur auf das Ausblenden von Zeilen entsprd reagieren!). Auch unter Einbeziehung von INDEX wäre das Verhalten genau gleich und eine plurale MatrixFml würde in beiden Fällen stets nur die GesamtSumme liefern.
Im vorherigen Bsp wird aber eine ganze DatenfeldMatrix (im Namensraum) gebildet, für die deshalb sehr wahrscheinlich ein ganzer ZugriffsVektor angelegt wird. Die Elemente, auf die er verweist, können und müssen dann auch mit INDEX einzeln abgerufen wdn, anderenfalls erhielte man stets den 1.Wert der ganzen Matrix. Das ist bei der ZellFml zwar formal alles genauso, inkl Verhalten als plurale MatrixFml, aber ich bezweifle ja, dass Xl die Fml-Optimierung auch über Zellgrenzen hinaus betreibt, falls die jeweilige Fml normal oder eine singulare MatrixFml ist. In benannten Fmln ist diese Unterscheidung aber irrelevant. Hier wird immer alles berechnet. Die Auswahl der wiederzugebenden Ergebnisse erfolgt dann über die FmlEintragung im TabBlatt. D.h., gibt man in diesem Fall nur den Namen pro Zelle oder für alle Zellen als plurale MxFml an, hat Xl keine Info darüber, welcher Wert wiedergegeben wdn soll, und verwendet deshalb den ersten. Mit INDEX kann aber ein bestimmter Wert ausgewählt wdn. Im ZellFml-Fall gehe ich demggüber davon aus, dass Xl in jeder Zelle den gesamten Vektor berechnet, der INDEX zu übergeben ist, und erst dann einen Wert auswählt. Es könnte aber auch sein, dass INDEX erst die Werte auswählt und dann berechnet (in Analogie zu WENN & WAHL, aber das ist eher nicht miteinander vglbar). Aber das glaube ich nicht, da es dem Konzept des Fml-Interpreters widersprechen würde, der das HptArgument ja hier erst mal zur Berechnung übergeben müsste (das könnte eher bei reinen BereichsBezügen der Fall sein!) und erst danach auswählen könnte. Alles andere wäre ungleich komplexer (und WENN und WAHL machen das bei Datenfeldern als Auswahl-Argument ja auch nicht!). In einer pluralen MxFml sähe das natürlich anders aus, denn das HptArgument würde sicher nur 1x berechnet und dann alle diese Werte auch per Auswahl=0 zellenweise zurückgegeben.
Genau das scheint auch Lupo mit seinem, zugegebenermaßen leicht hinkenden*, Zug-Vgl (und der Alzheimer-Bemerkung) zu meinen, denn das entspräche einer geschlossenen AblaufLogik, die auch von speziellen Fktt nicht oW durchbrochen wdn kann (mit einer UDF übrigens auch nur nachträglich, was der Nutzer sicher nicht bemerken würde, aber Xl berechnet vorher trotzdem alles und dann nochmal den Teil, also quasi das 1.Mal umsonst!). (Beachte, FmlTexte müssen erst erkannt, dann interpretiert und in der Fml vorhandenen Fktt mundgerecht serviert wdn, bevor ein EndErgebnis berechnet wdn kann!)
* Besser wäre es wohl, das mit der jedesmaligen Anfertigung einer ganzen ProduktPalette zu vgln, obwohl nur Bestellungen für bestimmte Produkte vorliegen!
Deshalb halte ich plurale MatrixFmln, zumindest bei größeren Datenmengen, für performanter als ihre künstliche Aufsplittung in EinzelWerte. Aber genau in diesen Fällen ist der EinzelWert flexibler, weshalb dann auf benannte Fmln zurückgegriffen wdn sollte. INDEX erhält dann jedesmal ein nur 1x berechnetes, fertiges Datenfeld und muss aus diesem nur noch auswählen.
Es sollte mich doch sehr wundern, wenn die Xl-Macher hier anders vorgegangen wären, denn das würde doch irgendwie an Mystik erinnern und die ist in der EDV (noch!) weder üblich noch möglich. (Mit echter KI mag's einstens anders aussehen...)
Deshalb ist auch nur der primäre Zugriff auf Zellen und ihre Bereiche 100%ig eindeutig und durchschaubar, weshalb der auch die Grundlage meines FAN-Konzepts bildet (ZwischenErgebnisse für andere Berechnungen müssen deshalb immer in ZellBereichen - oder viell auch mal benannten Konstanten bzw internen Variablen - abgelegt wdn).
Morrn, Luc :-?