Formelalternative(n) gesucht ...

Moderator: ModerationP

Re: Formelalternative(n) gesucht ...

Beitragvon neopa » 15. Sep 2017, 08:06

Hallo Luc,

ich hab Dir im Herber Forum geantwortet.

hallo Lupo,

wie Du selbst schreibst, ist Dein Beispiel etwas unreal. Es gibt dagegen Beispiele wo durch den Einsatz von benannten Formeln die phys. (nichts anderes hatte ich geschrieben und gemeint) Dateigröße sich gegenüber den Einsatz von Hilfszellen reduziert.
Gruß Werner
.. , - ...
neopa
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 9999
Registriert: 03. Mai 2008, 15:57
Wohnort: zu Hause in C

Re: Formelalternative(n) gesucht ...

Beitragvon lupo1 » 15. Sep 2017, 08:18

Dann her damit. :-)

Das probiere ich in .XLSX und .XLS aus und bestätige es dann gern (wie gesagt, für .XLSX halte ich es aufgrund des Zippens durchaus für möglich). Außerdem ist der Unterschied Größe a) "auf Platte" (das meinst Du vermutlich mit physisch) und b) "im RAM" (das wäre aber viel wichtiger!) zu beachten. Also 4 Vergleiche zu normalen Formeln.

Unreal war nicht mein Parade-Beispiel, sondern meine Verwendung der Funktionen (Name und Reihenfolge), um die Formel ein wenig optisch zu entschlacken. Unreal ist auch nicht das Konzept, da es ja durch Longré umgesetzt wurde (ob funktionierend oder nicht, sei mal dahingestellt).
lupo1
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 9271
Registriert: 25. Okt 2012, 13:38

Re: Formelalternative(n) gesucht ...

Beitragvon neopa » 15. Sep 2017, 19:29

Hallo Lupo,

natürlich meinte ich die externe Speichergröße. Ich hab es jetzt mal mit den Daten aus diesem thread getestet, wobei ich dafür bewusst nur meine eingestellten Formeln genutzt habe.

Eine Datei mit Formeln nur in E3:E99 mit meinen benannten Formeln ist als xlsx-Datei ca. 3,5 KB und als xls-Datei sogar ca. 60 KB kleiner als ohne benannte Formeln. Alles andere wäre ja auch völlig unlogisch. Wenn Du möchtest kann ich diese natürlich hier einstellen.

Natürlich weiß ich, dass es entscheidender ist, welcher jeweiliger Speicherbedarf im RAM dafür benötigt wird und wie die Auswertungszeiten sich zueinander verhalten. Diesbzgl. hatte und habe ich aber keine Aussage getätigt, ganz einfach deshalb, weil ich dafür keine Wissensbasis besitze.

Mein ursprüngliche Zielstellung dieses threads habe ich durch die Bereitstellung der Formel von Sepp erreicht. Wenn durch mich auch nicht wirklich eindeutig messbar, ist seine die von mir angestrebte optimale Lösung. Und wenn ich seine Hilfszellen durch benannte Formeln ersetze sind auch meine Bedingungsvorgaben voll erfüllt.
Gruß Werner
.. , - ...
neopa
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 9999
Registriert: 03. Mai 2008, 15:57
Wohnort: zu Hause in C

Re: Formelalternative(n) gesucht ...

Beitragvon lupo1 » 16. Sep 2017, 03:49

In der 2x2-Matrix

XLS RAM
XLS HD
XLSX RAM
XLSX HD

kann ich eine (leichte) Reduktion im letzten Falle bestätigen ... ZIP macht es möglich.

Für die ersten 3 Fälle gibt es keine Ersparnis. Das ist mein Wissensstand seit etwa 20 Jahren. Die Benennung einer Formel ist ALLEIN ein "Anstrich" (wenn auch ein "stabilisierender"), aber kein "Intelligenzgewinn". Bei einem Intelligenzgewinn (wie bei Hilfszellen oder bei VBA-Functions bzw. -Subs) wäre das Modell außerdem nicht nur kleiner, sondern auch schneller (je nach konkretem Fall bei Hilfszellen anders, als bei VBA).
lupo1
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 9271
Registriert: 25. Okt 2012, 13:38

Re: Formelalternative(n) gesucht ...

Beitragvon neopa » 16. Sep 2017, 20:36

Hallo Lupo,

Deine letzten Darlegungen sind für mich teilweise nicht eindeutig. Was genau reduziert sich und was nicht? Wenn Du mit HD den Speicherbedarf auf Harddisk meinst, so hatte ich diesbzgl. doch threadbezogen eine andere Feststellung aufgezeigt, die sich dann nicht mit Deiner Aussage in Einklang bringen lässt. Es sei denn Du meinst was anderes.

Teilweise sind Deine Aussagen von mir in diesem threads bisher auch gar nicht thematisiert (weder VBA noch Hilfszellen). Mich interessiert im thread lediglich der Vergleich zwischen Formeln ohne jegliche Hilfszellen und ohne VBA mit Ergebnisgleichen Formeln, die aus vorgenannten Formeln mittels benannten Formeln strukturiert worden sind.

Unabhängig davon, dass es bis jetzt meinerseits nicht thematisiert war, erschließt sich mir auch Deine Aussage nicht, wonach Hilfszellen im Vergleich zu benannten Formeln (mit gleichem Ergebnis wie vorgenannte) ein "Intelligenzgewinn" darstellen sollen.
Gruß Werner
.. , - ...
neopa
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 9999
Registriert: 03. Mai 2008, 15:57
Wohnort: zu Hause in C

Re: Formelalternative(n) gesucht ...

Beitragvon lupo1 » 17. Sep 2017, 14:00

Mit Reduktion meine ich Speicher-Inanspruchnahme. Und ich habe Deine Aussage bestätigt. Nur halt nicht für die ersten drei Kombinationen (Excel-Dateiformat vs. Speicherart). Du gibst Dich vermutlich nicht mehr mit .XLS ab. Ich schon noch.

Hilfszellen sind - wie Variablen - ein "Intelligenzgewinn", da Zwischenschritte gespeichert werden. Dies ist bei benannten Formeln nie so. Aber wirklich nie! Alles muss erneut gerechnet werden, auch bei mehrfacher Verwendung des gleichen Namens an gleicher Stelle.

Vergleich aus dem Leben: Hilfszellen sind "normales Denken mit daraus Lernen", benannte Formel ist schlichtweg "Alzheimer in Endstufe". Genauso, wie die ganzen AGGREGAT-Formeln, wenn sie den Anspruch haben, an einer Stelle ohne Hilfszellen rechnen zu müssen.

Trotzdem gibt es berechtigte oder unumgängliche Anwendungen für benF, aber das hatten wir schon.
lupo1
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 9271
Registriert: 25. Okt 2012, 13:38

Re: Formelalternative(n) gesucht ...

Beitragvon neopa » 17. Sep 2017, 14:29

Hallo Lupo,

was Du bzgl. des Einsatzes von Hilfszellen beschreibst, ist für mich kein "Intelligenzgewinn" sondern "Zeitgewinn" infolge effektiver Ressourcennutzung den ich auch nicht bestreite.

Aber wie ich schon mehrfach geschrieben habe, ging und geht es mir in diesem thread nicht um einen Vergleich des Einsatz benannter Formeln anstelle von Hilfszellen sondern um einen Vergleich zwischen Formeln ohne Hilfszellen und Formeln mit benannten Formeln. Dein Vergleich mit AGGREGAT()-Formeln ist hier deswegen ebenso unangebracht.

Bzgl. Deiner Aussage zu xls-Dateien kann ich auch nur noch mal auf mein konkreten Aussagen in meinem Beitrag vom 15. Sep 2017, 20:29 verweisen wonach die xls-Datei mit gleichem Inhalt aber mit benannten Formeln 60KB weniger (HD)-Speicher in Anspruch nimmt als die mit Formeln "ohne alles".
Gruß Werner
.. , - ...
neopa
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 9999
Registriert: 03. Mai 2008, 15:57
Wohnort: zu Hause in C

Re: Formelalternative(n) gesucht ...

Beitragvon lupo1 » 17. Sep 2017, 15:20

neopa hat geschrieben:[...] die xls-Datei [...]

Welche? Die zu dem Thema dieses Threads? Das würde mich überraschen. Allerdings konnte auch .xls schon Wiederholungen im Tabellenaufbau erkennen ... bin gespannt.

Worum es Dir geht, war mir schon in meiner ersten Antwort egal, da das andere bearbeitet haben. Ich habe nur OT etwas zu benannten Formeln geschrieben.
lupo1
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 9271
Registriert: 25. Okt 2012, 13:38

Re: Formelalternative(n) gesucht ...

Beitragvon neopa » 17. Sep 2017, 17:43

Hallo Lupo,

Beitragvon neopa » 15. Sep 2017, 20:29
Eine Datei mit Formeln nur in E3:E99 mit meinen benannten Formeln ist als xlsx-Datei ca. 3,5 KB und als xls-Datei sogar ca. 60 KB kleiner als ohne benannte Formeln. Alles andere wäre ja auch völlig unlogisch. Wenn Du möchtest kann ich diese natürlich hier einstellen.

darauf hattest Du gestern nicht reagiert. Ich füge die beiden xls-Dateien nun bei.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Gruß Werner
.. , - ...
neopa
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 9999
Registriert: 03. Mai 2008, 15:57
Wohnort: zu Hause in C

Re: Formelalternative(n) gesucht ...

Beitragvon lupo1 » 18. Sep 2017, 06:42

Mein Verständnis über benannte Formeln wankt - es scheint tatsächlich zu stimmen, und zwar in beachtlichem Umfang!

"Nr" in E3: =MAX(MMULT((ABS(ZeitRaum*2-MTRANS(!C$3:C3)-MTRANS(!B$3:B3))<=MTRANS(!C$3:C3)-MTRANS(!B$3:B3))*(ABS(ZeitRaum*2-!C3-!B3)<=!C3-!B3)*MTRANS(!A$3:A3=!A3);ZEILE(!B$1:B1)^0))

bringt jedoch (abseits von benannten Formeln) noch eine kleine Altdateiformat-Schrumpfung von 9% (angehängt), da "Zeitraum" mittels Intervallnormierung nur 2mal verwendet werden muss. Im RAM wird es hier aufgrund der inhaltlichen Formeloptimierung auch eine Verkleinerung geben. Einen Schnelligkeitsgewinn um ca. 10%-30% kannst Du evtl. mit den Realdaten messen.

"Anf" und "End" sind strenggenommen überflüssig, da
1. sie nur einmal verwendet werden
2. die Benennung "Zeitraum" weit unter 256 Zeichen beträgt, so dass die beiden Formeln unbenannt noch gut mit reinpassen:

"Zeitraum" in E3: =ZEILE(INDEX(!A$1:A$65536;MAX(MIN(!B$3:B$100);!W$1-TAG(!W$1)+1)):INDEX(!A$1:A$65536;MIN(MAX(!C$3:C$100);!W$1-TAG(!W$1)+300-TAG(!W$1-TAG(!W$1)+300))))

Man kann sie aber auch beibehalten, da sie andererseits auch keinen zusätzlichen Platz benötigen (bei .xls; bei .xlsx hingegen bringt ihr Wegfall im Bytebereich ein wenig, nämlich nochmal 112 Byte), und somit als Benefit mehr Übersicht und Klarheit herrschen.

Ohne Verwendung von Namen: Die unbenannte Formel

E3: {=MAX(MMULT(
(ABS(ZEILE(INDEX(A:A;MAX(MIN(B$3:B$100);W$1-TAG(W$1)+1)):INDEX(A:A;MIN(MAX(C$3:C$100);W$1-TAG(W$1)+300-TAG(W$1-TAG(W$1)+300))))*2
-MTRANS(C$3:C3)-MTRANS(B$3:B3))<=MTRANS(C$3:C3)-MTRANS(B$3:B3))*
(ABS(ZEILE(INDEX(A:A;MAX(MIN(B$3:B$100);W$1-TAG(W$1)+1)):INDEX(A:A;MIN(MAX(C$3:C$100);W$1-TAG(W$1)+300-TAG(W$1-TAG(W$1)+300))))*2
-C3-B3)<=C3-B3)*MTRANS(A$3:A3=A3);ZEILE(B$1:B1)^0))
}

erreicht jetzt mit 384 (statt 586) Zeichen nur noch knapp 2/3 Umfang, falls das noch von Interesse ist. Also endlich mal eine - jetzt wohl jeden überzeugende - Verwendung der 0058.


Die Nomenklatur von !A1 ("globaler Name") ist grundsätzlich gefährlich, da instabil. Eines konnte ich jedenfalls im Namensmanager feststellen: Die Koordinaten werden situationsabhängig mal richtig, mal falsch gezeigt, obwohl ich immer nur in E3 stand. Und zwar unterschiedlich in der Einfach-Auswahl und der Doppelklick-Auswahl eines definierten Namens.

Disclaimer: Da ich nicht im Thema war und inhaltlich nichts beigesteuert habe, könnte es sein, dass meine Formel falsch rechnet. Bitte prüfen. Nachrichtlich zu der einleitenden (für mich neuen) Erkenntnis: Das Löschen von "Nr" und die Verwendung der Formel direkt als Matrixformel in der Zelle vergrößert das .xls (also das alte Dateiformat) tatsächlich von 30 kb um 50% auf 45 kb (hier nicht angehängt). xl2010 wurde verwendet.

Meinen Vorwurf des "schweren alzheimerartigen EDV-Dilettantismus" aufgrund der "Kalkulationsexplosion" A$3:A3 (100 Verwendungen = 5.000 Vergleiche; 10.000 Verwendungen = 50.000.000 Vergleiche; wird leider auch in vielen Formeln bei excelformeln.de kultiviert) habe ich zu oft angebracht, als dass ich das jetzt hier noch mal tue. Du bist erfahren genug, um die Folgen dieser konsequenten Nichtbeachtung selbst zu verantworten. ;) Denn schlimmer als Hilfszellen sind lange Wartezeiten. Wenn Du mit dem Zug von Köln nach München fährst, tust Du dies als normaler Mensch einmal hin und zurück. Mit A$3:A3 aber fährst Du von Köln nach Bonn und zurück, dann genauso zur auf Bonn folgenden Stadt, dann als vorletztes von Köln nach Ingolstadt und zurück, bis Du am Ende dann nach München und zurück fährst. Völlig unsinnig.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
lupo1
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 9271
Registriert: 25. Okt 2012, 13:38

Re: Formelalternative(n) gesucht ...

Beitragvon neopa » 18. Sep 2017, 13:29

Hallo Lupo,

zunächst vielen Dank für Deine Untersuchungen und Ausführungen.

Deine Formelergebnisse in der von Dir eingestellten Datei und der Formel ohne benannte Formeln ergeben korrekte Werte. Letztere Formel ist zwar kürzer als meine Vergleichsformel, doch die von Sepp eingestellte Formel toppt es noch nicht, für die ich mich mittlerweile schon entschieden hatte. Diese erscheint mir auch infolge des vorangestellten WENN()-Formelteils noch etwas schneller auszuwerten.

Natürlich muss man bei der Definition von benannten Namen einige Regeln beachten. Habe aber bisher die von Dir beschriebene Probleme noch nicht festgestellt. Festgestellt habe ich jedoch anderweitig schon, dass bei ineinander geschachtelten benannten Formeln die Zellbezüge bei Löschungen von Spalten / Zeilen nicht immer korrekt in die "innerste" benannte Formel(n) übernommen werden, wo es bei "normalen" Formeln diese Problem nicht gibt. Hab dies jedoch noch nicht weiter verfolgt, ob dies z.B. global so gilt oder so nur bei bestimmten Funktionen der Fall ist

Hab bisher auch noch keine Probleme ("Instabilitäten") mit globalen benannten Formeln gehabt, wenn diese "sauber" definiert sind. Den Vorteil den solche jedoch bieten, möchte ich nicht mehr missen, wenn man gleiche Berechnungen mit unterschiedlichen Daten in verschiedenen Tabellenblättern (die natürlich gleichen Datenstruktur besitzen) vornehmen will/muss.

Eine nicht ganz uninteressante Detailfeststellung konnte ich auch noch beisteuern. Deine eingestellte Datei vergrößert sich bei mir, wenn ich diese ohne jegliche Bearbeitung nach "Speicherung unter" in meiner Excel 2010er Version als XLS-Datei um etwas über 6KB. Sie ist dann sogar 4KB größer, als meine ebenso aus 2010er Excel abgespeicherte XLS-Datei mit benannten Formeln, die ich hier gestern eingestellt hatte. Was immer das auch heißt oder bedeutet bzw. was der Grund dafür sein mag.
Gruß Werner
.. , - ...
neopa
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 9999
Registriert: 03. Mai 2008, 15:57
Wohnort: zu Hause in C

Hier geht's jetzt um mehrere Dinge gleichzeitig, ...

Beitragvon Luc$:-? » 19. Sep 2017, 00:09

...Folks (spez Werner & Lupo);

1. eine .xlsb ist oftmals < als eine .xlsm, was mit der Feststellung kollidiert Zip macht's möglich (eine .xls ist nicht unbedingt vglbar, weil sie ohnehin nicht alles speichern wird, was eine .xlsb speichert).

2. Xl speichert auch Altstände mit ab, also die Datei-Historie, um ggf Vorversionen wiederherstellen zu können. Das könnte das Bild zusätzlich verzerren.

3. Benannte Fmln, deren Namen in ZellFmln verwendet wdn, helfen ebenso wie Hilfszellen mit diesen Fmln dabei, die jeweilige HptFml übersichtlicher zu machen. Im Ggsatz zu Hilfszellen wdn aber ihre Berechnungsergebnisse nicht mitgespeichert, so dass nur der reine FmlText hier ins Gewicht fällt. Das ist so ähnlich, als ob man auf ein externes Objekt nur verweist, anstatt es komplett mitzuspeichern. Hinzu kommt, dass, ähnlich wie früher bei der Verwendung von TabSpalten-/-ZeilenTiteln und heute bei definierten Tabellen, der Bezug verständlicher wird als nur ein Verweis auf irgendwelche HilfszellenBereiche, es sei denn, diese Bereiche wdn ebenfalls über (sehr schnelle) definierte Bereichsnamen angesprochen.

4. Die Korrektheit von Adressbezügen in benannten Bereichen bzw Fmln dürfte allein in der Verantwortung des Anlegers liegen. Da ja ein Name zumeist für die 1. ihn nutzende ZellFml angelegt wird, kommen so natürlich lauter verschiedene Bezugspktt zustande. Wenn alle AdressAngaben in benannten Fmln auf A1 normiert würden, dürfte es mit Zell-, Zeilen-, SpaltenLöschungen keine Probleme geben (vgl auch dazu die demnächst hochgeladen werdende abgespeckte Demo-Datei im alten Herber-Thread).

5. Beide FmlArten, benannte und in Zellen, sind grdsätzlich erst mal nur Texte, die von Xl als Fmln erkannt (1.Zeichen ist =, +, - oder @ vor einem FktsNamen - Lotus 1-2-3 hatte keinen ZuweisungsOperator, = war nur VglsOperator!) und dann interpretiert wdn müssen, was erst einen ausführbaren Algorithmus erzeugt. Dabei wdn die Fmln optimiert, d.h., jeweils unnötige FmlTeile wdn idR gar nicht erst berechnet (WENN & WAHL, außer bei MatrixFml[-Teile]n) und sich wiederholende -Teile nur 1mal (Vgl dieser Teile). Mit benannten Fmln greift man zT dem vor und macht damit die Interpretation einer ZellFml einfacher und uU auch schneller. Das trifft besonders auf lineare FmlTeile (einfache Operanden-Operator-Verknüpfungen) und Fktt zu, deren ArgumentierungsAbfolge (zumindest teilweise) der Xl-Interpretation unterliegt (eine Ausnahme bilden hier Fktt, die keine solchen Argumente haben, also alles in Eigenregie handhaben, aber auch die wdn im Verbund mit anderen FmlTeilen bei Wiederholung idR wohl nur 1mal berechnet).

6. In falsch verstandener, vorgeblich nutzerfreundlicher Anpassung an schulmathematische Notationsformen von GleichungsAuflösungen (das x vor dem = entspräche in Xl dann der StandortZelle [bzw dem definierten Namen] und muss folglich nicht geschrieben wdn - wäre sonst ja ein Vgl!), hatten sich die ersten Macher von KalkulationsPgmm so entschieden (und alle haben's nachgemacht) und es damit dem Fml-Interpreter unnötig schwer gemacht und im EndEffekt es auch dem Nutzer oftmals nicht leichter. Die Vielzahl von Klammer-Ebenen wäre auch vermeidbar gewesen, hätte man eine durchgehend lineare NotationsForm gewählt (wie sie bspw jede Fkt mit ihrer ArgumenteListe zeigt). Dann wäre der AusgangsPkt jeder Fml stets ein ZellBereich gewesen. So muss jede Fml aber von innen nach außen interpretiert wdn, was diese KlammerungsEbenen generiert, die alle separat und ggf nebeneinander berechnet wdn müssen. Bei dadurch möglichem Klammer-Inferno verlieren eher Nutzer (mehr oder weniger schnell) den Überblick als der Interpreter, der heutzutage natürlich viel mehr Ebenen handhaben kann als in den AltVersionen! Deshalb wäre man gut beraten gewesen, linear formalisierte AlgorithmusDarstellungsMethoden früher EDV-Zeiten auch hier einzuführen (auch in der Mathematik wdn nicht alle NebenBedingungen mit in nur eine Fml gepackt!), denn die Linearität eines ggw FmlTextes ist nur eine scheinbare, in der sich oft wahre Abgründe (an Verschachtelungen) verbergen. Das versuche ich übrigens mal mit meinem FAN-Projekt durchzuexzerzieren.

7. Der Vorteil pluraler MatrixFmln ggüber künstlich erzeugten singularen scheint mit dem ZugVgl angesprochen zu wdn. Dem ist idR zuzustimmen, weil fraglich ist, ob die FmlOptimierung durch den Interpreter auch zellübergreifend fktioniert. Deshalb dürfte man auf Nr sicher gehen, eine solche Fml in den Namensraum auszulagern (Hilfszellen müssten dann ja auch plural sein, was aber gerade vermieden wdn soll!). Dort wird stets alles berechnet und erst in der ZellFml wird die Entscheidung darüber getroffen, welches Ergebnis dargestellt wird (bei dualen MatrixFmln sollte das analog sein, ist aber nicht immer so, weshalb die sich nicht alle dafür eignen). Hierzu ein kleines Bsp:
a) in Spalte A diese Werte anlegen: {1;2;3;4;5;6;7;8;9;10}
b) in B1 zB folgd Fml notieren und bis B10 runterziehen: =(11-A1)^2
Das Ergebnis wäre dann {100;81;64;49;36;25;16;9;4;1} womit die TestMatrix A1:B10 komplett wäre.
c) einen Namen definieren, zB Test und ihm diese Fml zuordnen: =$A$1:$A$10*$B$1:$B$10
d) in C1 folgd Fml notieren und bis C10 runterziehen: =INDEX(Test;A1)
Das Ergebnis wäre dann {100;162;192;196;180;150;112;72;36;10}.
Fazit: In Spalte C wurde keine MatrixFml notiert, weder plural noch singular, und trotzdem ergibt sich ein richtiges, zellenweises Ergebnis aus einem Datenfeld, dessen einzelne Werte per INDEX abrufbar sind. Ohne INDEX würde immer nur der 1.Wert des im Namensraum gebildeten Datenfelds wiedergegeben (evtl auch neu berechnet) wdn, was beweist, dass in jeder Zelle stets das ganze Datenfeld zV steht. Wollte man auf INDEX verzichten, müsste man eine plurale MatrixFml einsetzen.
Natürlich könnte es auch hier sein, dass in jeder Zelle auch die Fml hinter dem Namen neu berechnet wird, das lassen zumindest Berechnungen auf der Basis der ursprünglichen ProblemStellung vermuten, denn hier ergibt sich für jede Zelle eine ganze Matrix (aus der o.g. BspDatei ersichtlich), es sei denn, im Namensraum können auch 3dimensionale Tensoren angelegt wdn, die dann aber nicht auf einen 2dimensionalen ZellBereich (und auch nicht per MatrixKonstante) abgebildet wdn könnten. Das ist aber lt Test, zumindest in diesem Fall, nicht so, so dass wohl von einer Neuberechnung auf jeder (Zell-)Ebene ausgegangen wdn kann (falls der Name nicht mehrere, nur über die jeweilige ZellPosition zugängliche Ergebnisse vorhalten kann, was kaum nachprüfbar wäre; vgl dazu auch Pkt 8). Das würde aber bedeuten, dass im einfachen BspFall nur ein Wert und im komplexen nur ein Vektor pro Zelle vorliegen müsste, was aber offensichtlich nicht so ist. Dem entspricht auch, dass ohne INDEX im obigen Bsp immer nur 100 in den Zellen stehen würde. Das ist also noch nicht ganz eindeutig, aber ich bemühe mich, heraus zu finden, was tatsächlich passiert (dauert aber momentan zu lange).

8. Es dürfte wenig bekannt sein, dass Xl seit vermutlich Xl12/2007 (kann ich zZ nicht testen, aber ab Xl14/2010 ist es definitiv so) verborgene Namen für alle ab dieser Version neuen Fktt anlegt. Aufgefallen sind mir zwar schon früher kryptische FktsNamen in Dateien aus bspw Xl14-Dateien, die unter Xl12 geöffnet wurden, wie bspw _xlfn.AGGREGATE oder aus Xl2013/365 unter Xl10 wie _xlfn.TEXTJOIN, aber die hatte ich bisher nicht mit definierten Namen in Verbindung gebracht. Bei der Erstellung einer defNamensAuflistung für die bereits genannte Datei tauchte aber plötzlich als 1.Name _xlfn.IFERROR auf (auf dieses 'Phänomen' gehe ich in der o.g. Datei näher ein). Möglicherweise deutet das darauf hin, dass sich Xl in den neuen Versionen einer temporären Variable für jede neue Fkt bedient, was einerseits darauf hindeutet, dass sie nicht in den alten FktsKern integriert wurden, sondern ein alternativer Kern geschaffen wurde (was mir durchaus zu bekannten MS-Praktiken zu passen scheint), der höchstwahrscheinlich etwas anders arbeitet, evtl auch einen speziellen neuen Teil des Fml-Interpreters verwendet. Somit besteht natürlich die 'Gefahr', dass, wenn erst alle bisher noch nicht auf der AbschussListe stehenden alten Fktt neu gefasst wurden, in einer zukünftigen Version der alte Kern einfach entfällt. Andererseits könnte damit aber auch das geschaffen worden sein, was Lupo in Bezug auf L.Longre erwähnt hatte. Evtl Ähnliches hatte ich bereits vor Jahren mit diversen UDFs versucht, die hptsächlich der Bewahrung von vorherigen Ergebnissen dienten, so dass sie die Ersetzung von FmlTeilen durch benannte Fmln ersetzen können. Wenn diese neuen verborgenen Namen eine ähnliche Aufgabe haben, dürften sie auch sauber nur pro FmlZelle fktionieren und bei Berechnungsende zurückgesetzt wdn, etwas, was (meine) einschlägige(n) UDFs kaum bzw nur teilweise leisten könnten. Wdn die betreffenden Fmln entfernt, wird auch der zugehörige Name beim Schließen der Datei gelöscht.

Damit wäre ich vorläufig durch. Falls mir auffallen sollte, noch etwas vergessen zu haben, melde ich mich hier nochmal, ansonsten nur auf evtl Reaktionen eurerseits.
Morrn, Luc :-?
Luc$:-?
 

Re: Formelalternative(n) gesucht ...

Beitragvon lupo1 » 19. Sep 2017, 10:54

neopa:
!A1: finde ich auch extrem sexy. Die Warnungen davor sind so alt (und so selten oder versteckt), dass ich sie nur noch im Kopf hatte, aber nicht mehr im Internet gefunden habe. Außerdem betraf es xl2000 ... kann sein, dass die Instabilitäten mit x2010 weg sind.
6 kb: Vielleicht haben wir unterschiedliche Versionsaktualisierungen von xl2010.

Luc:
2. Deswegen schreibe ich ganz gern sogenannte Dateierstellungsmakros ;)
3. Zustimmung
4. habs nicht ganz verstanden, aber ergibt sich vermutlich durch das Thema selbst, da benF für Fortgeschrittene ist
5. Nur-Einmal-Berechnung gleicher Teile wäre eine tolle Folge der Platzminimierung! Die ließe sich per Zeitmessung beweisen. Habe ich jetzt nicht getan.
6. Mein müder Geist kommt hier nicht ganz mit ...
7. Interessant, aber müsste ich mich mit beschäftigen
8. Hui! Das wäre ja was!
lupo1
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 9271
Registriert: 25. Okt 2012, 13:38

Zu Deinen Anmerkungen zu meinen Pktt, ...

Beitragvon Luc$:-? » 19. Sep 2017, 21:15

...Lupo;
4. Zumindest das alte Xl-Tool zur NamensDokumentation hat auf die ErstBezugsZelle (die ausgewählt war als der Name erstellt wurde) keine Rücksicht genommen und relative Adressen im FmlText einer benannten Fml an den Standort der DokuZelle angepasst, wobei meist sehr unschöne FmlBilder entstanden sind. In der in den nächsten Tagen auf herber hochzuladenden Datei habe ich dafür eine UDF benutzt, die diese Adressen nach Vorgabe korrigiert (nachdem ich die vor Jahren geschrieben hatte, habe ich das erwähnte Xl-Tool nicht mehr benutzt!). In dieser Datei ist es immer dieselbe - A3. Es müsste also dem Nutzer auch möglich sein, so zu tun, als gölten die Namen auch für A1, wobei dann evtl relative Adressen in der eigentlichen 1.AnwendungsZelle den richtigen Bezug zeigen müssten. Dann würde der sich bei Löschungen und Hinzufügungen von Zeilen/Spalten auch mitverschieben. Alles, was sich nicht verschieben soll, muss natürlich absolut gesetzt wdn.
5. Kann in komplexen Fällen kompliziert wdn.
6. Munter wdn! Hier geht's um die unsägliche Verklammerung. In frühen EDV-Zeiten wurden verschiedene Notationsformen für Algorithmen entwickelt, die sowohl dem Pgmmierer das Notieren als auch dem Compiler das Interpretieren erleichtern sollten, zB die Polnische Notation. Ich hatte mich schon vor Jahrzehnten und dann wieder vor knapp 15 Jahren mit einschlägigen Überlegungen und Pgmmierungen befasst. Voriges Jahr hatte ich das wieder aufgegriffen und erste, pgmbegleitete (UDF, nur zwecks Demo) Gedanken realisiert (vgl auch meinen Hinweis an snb hier vor ein paar Wochen). Ich weiß nicht mehr so genau, ob Du es warst, der mir sagte, dass er sich nicht wieder umgewöhnen wolle, aber das ist ja auch egal, weil das andere auch so sehen mögen, aber für viele gar nicht fml-affinen Nutzer wäre das schon ein Gewinn (neopa kennt meine diesbzgl Darstellungen bei herber übrigens, wir hatten darüber -FAN [Formalisierte AlgorithmusNotation]- diskutiert).
7. Tu das! Ich habe mich nochmal damit befasst und dabei bemerkt, dass offensichtlich ein Vektor (bzw eine Matrix?) für jede Zelle mit eigenem Ergebnis aus der Anwendung der benannten Fml angelegt wird. Das könnte darauf hinweisen, dass anhand dieser Vorbereitung fertige Ergebnisse (nach MappenStart gebildet) aus dem Speicher abgerufen wdn können (anderenfalls wäre das wohl nicht erforderlich). Damit käme beim komplexen Bsp zum hiesigen Problem (o.g. Datei) ein quasi 3dTensor zum Einsatz, der aber eher als 1.2- bzw 2.2-dimensioniert zu betrachten wäre - VBA-Indizes (z)(i,j) bzw (z,1)(i,j) wg VertikalVektor im komplexen Bsp -, allerdings nur theoretisch, denn praktisch erfolgt wohl ein Zugriff je nach konkreter ZellAuswahl auf 2dMatrizen über den vorgeschalteten Vektor (bzw die Matrix?). An diese Inhalte kommt man mit VBA nicht ran und die Evaluierung per SubProz liefert nur diesen Vektor mit FehlerWerten.
8. Ja, aber wie schon unter Pkt 7 erwähnt - man kommt nicht ran, weder an normale NamensErgebnisse noch an diese (falls das überhpt dazu dient und nicht anderen Zwecken)! Allerdings habe ich inzwischen festgestellt, dass diese Namen auch angelegt wdn, wenn man in einer SubProz eine diese Fktt enthaltende Fml evaluiert. Daraus kann wohl wenigstens geschlossen wdn, dass bei Evaluierung auch direkt auf die jeweilige Mappe und nicht nur ihre virtuelle Kopie zugegriffen wird.
Luc :-?
Luc$:-?
 

Re: Formelalternative(n) gesucht ...

Beitragvon neopa » 19. Sep 2017, 22:23

Hallo Lupo,

meine XL-2010-Version ist 14.0.7188.5002

Hallo Luc,

hab Deine Ausführungen gelesen, werde aber wohl frühestens Morgen ein paar Anmerkungen dazu vornehmen.
Gruß Werner
.. , - ...
neopa
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 9999
Registriert: 03. Mai 2008, 15:57
Wohnort: zu Hause in C

VorherigeNächste

Zurück zu Excel Forum (provisorisch)

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste

cron