Kostenstellzuordnung per Schlüssel

Beiträge zum Forumthread

Beiträge zu diesem Forumthread

Betreff

Datum

Anwender

Hallo, Werner,
schön, dass Du Dich meldest. ;-)
Zu Deinen Anmerkungen:
&bullet; Die Bspp sollten meinen vorhergehenden Beitrag illustrieren und dabei zeigen, dass …
1. SUMMENPRODUKT nicht immer dem gleich ist, was „draufsteht“, denn man kann es in Xl durchaus unterschiedlich anwenden, kaum aber in VBA;
2. es noch andere Möglichkeiten gibt, Summen von Produkten zu bilden (eine, die letztlich die Kombi-Funktion von SUMMENPRODUKT nachvollzieht, hattest Du ja bereits verwendet);
3. einige dieser anderen Möglichkeiten zu gleichen Resultaten führen, andere aber nicht (und SUMMENPRODUKT nicht immer nicht der MatrixFml-Form bedarf).
Und natürlich ging's mir bei dieser Demonstration nicht um irgendwelche alternativen Berechnungen, die uU gleiche Ergebnisse liefern (Deine Anmerkungen zu d/f), sondern um die Darstellung spezifischer Abläufe, die mit den Alternativen ggf nicht sichtbar würden.
&bullet; Zum Einzelnen:
a) zeigt eine NormalAnwendung von SUMMENPRODUKT, wobei letztlich nur jeweils ein Vektor beider Matrizen berücksichtigt wird (das elementweise Produkt der beiden anderen ergäbe 0en bzw beide wdn ausgefiltert, weil der erste der beiden kein MultiplikationsPartner des anderen sein kann).
b) fktioniert deshalb auch nicht, denn hier wird im Argument von SUMMENPRODUKT vorab das (elementweise) Hadamard-Produkt gebildet, was hier nur über Operatoren in einen Fehler laufen muss.
c) ergibt (in Xl14/2010) den von mir genannten Wert, wenn berücksichtigt wurde, dass die LeerTexte gelöscht wdn sollten (lässt sich per MxKonstantenFml nicht anders darstellen → einzige Alternativen sind anderer Text oder 0, was beides nicht gewollt wäre). Mein Ergebnis ist auch logisch, da ja hier nicht primär eine Produktsumme, sondern nur eine Summe gebildet wird. Die ProduktBildung besorgt nicht die Fkt, sondern der Xl-FmlText-Interpreter und der liefert mangels Multiplikationspartnern auch #NV-Werte, die bei der Mitteilung an Xl, dass es sich um eine MxFml handelte und deshalb alle Werte berücksichtigt wdn sollen, auch #NV-Werte an die Fkt weitergibt, was folglich zum Gesamtergebnis #NV führt. Ohne diese Mitteilung verwendet Xl nur den 1.Wert des transponierten Vektors, was der Fkt dann wenigstens die (nun nur noch erforderliche) Summation erlaubt.
d) zeigt ähnliche Allüren, denn obwohl jedem Element des Vektors eine Kopie der ganzen Matrix als Partner zV steht, wird nur mit dem 1.Element des Vektors gerechnet, was einerseits daran liegt, dass hier die MxFml-Form allein nicht ausreicht und andererseits wohl auch nur ein Durchlauf erfolgt, obwohl einer pro VektorElement erforderlich wäre (ich hatte das in letzten Beiträgen zu meinem „biforumellen“ Tensor-Exkurs - mit Abstecher zur MxFml-Problematik auf OL - alles zumindest absteigend miteinander verlinkt - behandelt). Dazu muss das Ganze noch „entfaltet“ wdn (vgl e/f).
e) zeigt, dass neben der MxFml-Form auch noch die Auswahl von 2 Zellen erforderlich ist, um wenigstens alle (allein) in Xl auch abbildbaren (jeweils 1.) Werte zu ermitteln. Nur diese können ohne „Entfaltung“ des virtuellen 3Tensors (hier Vektor mit Matrizen als Elemente) als Argument (in einem Durchlauf) weitergegeben wdn.
f) realisiert die in e bereits erwähnte „Entfaltung“ des virtuellen 3Tensors derart, dass einer Xl-Fkt wie SUMME alle Werte jeder Matrix des 3Tensor-Vektors nacheinander in mehreren Durchläufen (hier 4) positioniert zV gestellt wdn. Deine AlternativFml mag einfacher sein, bringt aber keinen weitergehenden ErkenntnisGewinn bzgl der Tatsache, dass Xl in der Lage ist, auch solche Tensoren zu berechnen und uU sogar weiter zu verarbeiten (wohl ein Xl-AlleinStellungsMerkmal!). Diese, ob gewollt oder nicht, geniale Universalität der Xl-FmlText-Interpretation wäre so niemals bemerkt worden (ein anderer Aspekt derselben ist die Behandlung von WENN und WAHL und die Bereitstellung von ObjektBezügen durch INDEX, wann immer möglich). Genau das wollte ich hiermit zeigen*!
g) zeigt das Matrizenprodukt (ein Kovektor) und soll hier nur die Grundlage von h/i visualisieren.
h) bildet per MxFml die Summe von g, während …
i) das Gleiche tut, dabei aber zeigt, dass SUMMENPRODUKT hier die MxFml-Form nicht überflüssig macht, übrigens auch nicht INDEX(…;;).
j) bildet ein positionsbezogenes elementweises Produkt eines Vektors mit einer Matrix, die man auch als aus Vektoren (als Elemente eines Kovektors) bestehend auffassen kann, was die Bezeichnung als Hadamard-Produkt rechtfertigen sollte. Dessen Rolle wird allerdings im Ggsatz zu anderen Vektor-/MatrixOperationen als wenig bedeutend charakterisiert (obwohl es als einziges Argument von SUMMENPRODUKT von Xl-Fml-Cracks geradezu inflationär eingesetzt wird — nur zur Bildung der Summe seiner Elemente, was beides zusammen der eigentl Aufgabe von SUMMENPRODUKT entspräche! ;-]).
Das StandardSkalarprodukt als einwertiges Ergebnis {Skalar bzw 0Tensor oder Tensor(0,0)} der Multiplikation 2er Vektoren wird auch als inneres Produkt bezeichnet, dem dann das mehrwertige äußere, Kreuz- bzw VektorProdukt ggübersteht. Das habe ich hier nicht behandelt, weil ich mich damit noch nicht ausgiebig zu Xl-Bedingungen befasst habe. Könnte aber auch recht interessant wdn! ;-)
* Im angekündigten praktischen Bsp wird ebenfalls so etwas enthalten sein - zT ebenfalls einfacher zu ermitteln, weshalb ich noch einen komplizierteren Zusatz eingebaut habe! Lass Dich überraschen! ;-)
Gruß, Luc :-?

12:= SUMME(A1:B2) 109:= {=SUMME(A1:B2*K1:L2)} 12:= {=SUMME(--A1:B2)} 109:= {=SUMME(-A1:B2*-K1:L2)} 12:= {=SUMME(MTRANS(A1:B2))} 107:= {=SUMME(MTRANS(A1:B2)*K1:L2)} 109:= SUMMENPRODUKT(A1:B2;K1:L2) 109:= SUMMENPRODUKT(A1:B2*K1:L2) 109:= SUMMENPRODUKT(--A1:B2;--K1:L2) 109:= SUMMENPRODUKT(-A1:B2*-K1:L2) 107:= {=SUMMENPRODUKT(MTRANS(A1:B2);K1:L2)} 107:= {=SUMMENPRODUKT(MTRANS(A1:B2)*K1:L2)}

…irgendeinen besonderen Nutzen dieser Fml, Werner,
sondern mich hatte diese Entdeckung erstaunt, zumal das in anderer Calc-Software nicht so umgesetzt wird. Da ich mit n-dimensionalen Tensoren beschäftigt hatte, die in VBA ja möglich sind (wohl bis zu n=60), hatte mich interessiert, ob und wie Xl mit 3- bzw 4-Tensoren umgehen kann bzw umgeht. Und siehe da, der FmlText-Interpreter berücksichtigt so etwas!
Da nicht nur Du nach dem Nutzen fragst, den so etwas (für den NormalNutzer) haben kann, hatte ich ein eher ökonomisch orientiertes Bsp dafür vorbereitet (HTML-Tab ist bereits fertig), das ich noch betexten muss und dann als neuen Tensor-FortsetzungsBeitrag einstellen werde.
Der IT-Nutzen sollte eigentlich unstrittig sein - immerhin rechnet Xl (und wohl nur Xl!) auch so -, allerdings entzieht sich das Xl-Bsp weitgehend dem Zugriff per VBA, kann aber über Hilfszellen per UDF mit allen Werten dargestellt wdn (das hatte ich in den erwähnten Tensor-Beiträgen dargestellt). Das dahinter steckende Kronecker-Produkt wird also von Xl tatsächlich als (hier 3-, sonst - bei 2 Matrizen -) 4Tensor gebildet, der durch das äußere INDEX-Konstrukt mehrfach wiederholt wird. Der FmlText-Interpreter wiederholt dann die Berechnung entsprd oft, wobei er jeweils die einer bestimmten ZellPosition entsprd Teil-Matrix auswählt. Dadurch ist es anderen Xl-Fktt möglich, eine ihrer Funktion entsprd Aktion mit dieser Teil-Matrix auszuführen. Eine derartige Fktionalität lässt sich mit VBA nicht direkt nachbilden, zumindest habe ich keinen Weg gefunden, aber eine UDF in einer ZellFml kann ebenso wie eine Xl-Fkt von dieser Vorgehensweise der Xl-Steuerung in Zusammenwirken mit dem FmlText-Interpreter profitieren. Wollte man allerdings alle Werte des Kronecker-Produkts mit nur einem Durchlauf per pluraler MatrixFml in einer naturgemäß größeren Matrix abbilden (was mit INDEX nicht möglich ist), müsste man eine spezielle UDF dafür schreiben (was ich ebenfalls getan habe, hier aber nicht relevant ist, da es die Lösung eher erschweren würde). Die würde dann den eigentlichen Nutzeffekt des Ganzen in der IT demonstrieren — anstelle n-dimensionaler Tensoren (bei sehr vielen kombinierbaren Eigenschaften vieler Objekte) mit ggf aufwändiger ZwischenSpeicherung nur mit großen normalen Matrizen rechnen zu müssen, wenn dabei zwangsläufig auftretende Ungenauigkeiten minimiert wdn können (ich hatte in o.g. Beitragsreihe eine Dissertation verlinkt, die sich damit befasst).
Ja, diese Kürzungsmöglichkeit hatte ich in meinem obigen Beitrag gemeint, Werner… ;-)
Gruß, Luc :-?

Beliebteste Forumthreads (12 Monate)

Kostenstellzuordnung per Schlüssel

36 Beiträge zum Forumthread Beiträge zu diesem Forumthread

VBA Beispiele zu verwandten Themen

Beliebteste Forumthreads (12 Monate)

Beliebteste Forumthreads (12 Monate)

36
Beiträge zum Forumthread

Beiträge zu diesem Forumthread