Live-Forum - Die aktuellen Beiträge
Datum
Titel
28.03.2024 21:12:36
28.03.2024 18:31:49
Anzeige
Archiv - Navigation
1416to1420
Aktuelles Verzeichnis
Verzeichnis Index
Übersicht Verzeichnisse
Vorheriger Thread
Rückwärts Blättern
Nächster Thread
Vorwärts blättern
Anzeige
HERBERS
Excel-Forum (Archiv)
20+ Jahre Excel-Kompetenz: Von Anwendern, für Anwender
Inhaltsverzeichnis

Frage zur Summenprodukt Formel

Frage zur Summenprodukt Formel
08.04.2015 21:22:37
Christian
Hallo an alle,
habe ein Problem mit der Summenprodukt Formel
hänge einfach mal eine Datei an, was muss ich mit der Formel in Spalte L machen, damit sie dasselbe Ausgibt wie die RANG Formel in Spalte M?
Bislang gibt sie dasselbe aus wie die Formeln in J und K.
Kann mir da jemand helfen?
Viele Grüße
Chris
https://www.herber.de/bbs/user/96956.xlsm

14
Beiträge zum Forumthread
Beiträge zu diesem Forumthread

Betreff
Datum
Anwender
Anzeige
AW: Frage zur Summenprodukt Formel
09.04.2015 06:56:57
Hajo_Zi
Hallo Chris,
warum nicht einfach =M1, warum 2 Spalten mit dem gleichen Ergebnis?

AW: Frage zur Summenprodukt Formel
09.04.2015 08:56:25
Christian
Hallo Hajo,
die Rang Formel ist nur dafür da zu verdeutlichen was passieren soll, die Rang Formel gibt nur dieses Ergebnis aus, wenn die Tabelle sortiert ist, wie sie jetzt ist, der Summenproduktformel ist die Sortierung egal.
Mit anderen Worten wenn ich die Summenprodukt-Formel nutze muss ich wenn ich neue Zeilen hinzufüge nicht erst sortieren um den Rang zu sehen.
Viele Grüße
Christian

Anzeige
noch offen
09.04.2015 10:15:36
Christian
noch offen

ist ganz einfach ...
09.04.2015 10:42:37
der
Hallo Christian,
... in der Formel in I2 (ja I2) mußt Du "" durch 0 ersetzen und diese nach unten kopieren. Dann hast Du in Spalte L kein Problem mehr.
Gruß Werner
.. , - ...

AW: ist ganz einfach ...
09.04.2015 10:57:20
Christian
Hallo Werner,
das klappt soweit, danke, um ehrlich zu sein da wäre ich im Leben nicht drauf gekommen,
darf man mal rein interessehalber noch etwas fragen? gibt es auch eineFormel, die das berechnet, ohne die Hilfsspalte I?
Wär für mich aber nur von Interesse, wenn es aufgrund der Datenmenge und Berechnungszeit ohne Matrixformel geht.
Danke und Gruß
Christian

Anzeige
wie meinst Du das nun genau ...
09.04.2015 12:33:28
der
Hallo Christian,
... die SUMMENPRODUKT()-Formel ist bereits in sich eine Matrixformel (bedarf halt nur nicht des möglicherweise von Dir gemeinten spez. {}-Formeleingabeabschlusses. Wie groß (wieviel Datensätze) ist denn Dein auszuwertender Datenbestand?
Gruß Werner
.. , - ...

AW: wie meinst Du das nun genau ...
09.04.2015 12:41:26
Christian
Hallo Werner, bislang noch ca. 500 aber wenn du dir die Formeln ansiehst rechne ich mit 10000 wenns fertig ist.
Wenns sowieso nicht anders geht, dann ist das auch egal ob die Formel ohne Hilfssapalte Matrix ist oder nicht.
VG
Christian

AW: wie meinst Du das nun genau ...
09.04.2015 13:39:34
Christian
Hallo Werner, bislang noch ca. 500 aber wenn du dir die Formeln ansiehst rechne ich mit 10000 wenns fertig ist.
Wenns sowieso nicht anders geht, dann ist das auch egal ob die Formel ohne Hilfssapalte Matrix ist oder nicht.
VG
Christian

Anzeige
Zwischenbemerkung zur Präzisierung
10.04.2015 05:21:57
Luc:-?
Morrn, Christian & Werner;
es geht mir hier doch etwas durcheinander mit der Bezeichnung MatrixFormel. Üblicherweise wird darunter eine Fml verstanden, die eine Matrix (bzw einen Vektor), also mehrere Werte ergibt und in den ausgewählten Bereich einträgt. Da es auch MatrixFmln gibt, die nur ein Ergebnis haben, kann man diese im Ggsatz zu den letztgenannten 1zelligen auch als mehrzellig bezeichnen. Dabei wdn natürlich stets nur soviel Werte dargestellt wie Zellen ausgewählt wurden. Sind das zuviele Zellen, enthalten die überzähligen #NV, sind es zuwenig, fehlen Werte. Diese mehrzelligen Fmln erfordern immer die Eingabe als MatrixFml.
Bei den 1zelligen* MatrixFmln kommt es darauf an, wie die Fml zusammengesetzt ist, d.h., ob und welche Funktionen sie enthält. Hier besteht nämlich ein Unterschied. Die meisten XlFktt können nämlich ganze Bereiche, viele sogar Datenfelder (→ aus TeilBerechnungen stammend und nicht mehr an Zellen gekoppelt) verarbeiten (meist nur im HptArgument). Mitunter ist das von der Pgmierung direkt vorgesehen, wie bspw bei SUMMENPRODUKT, das nur derartige Argumente verlangt, anderenfalls besorgt den WerteWechsel die Xl-Automatik in Abhängigkeit von der Position innerhalb der (Ergebnis-)Matrix. Was direkt pgmiert ist und was die Xl-Automatik besorgt, erkennt man im Fml-Assi an der Darstellungsweise des jeweiligen Arguments: Wdn seine Werte in Form einer sog MatrixKonstante angezeigt, sind Bereiche und ggf Datenfelder vorgesehen, wird ein Einzelwert angezeigt, obwohl ein ganzer/s Bereich/Datenfeld angegeben wurde, besorgt die Xl-Automatik den WerteWechsel wie o.g.
Xl-Fktt, die ganze Bereiche/Datenfelder verarbeiten können, nennt man MatrixFunktionen. Tritt eine solche Fkt in einer Fml allein ohne irgendwelche externen Zusätze auf, folgt die ganze Fml ihrer VerarbeitungsLogik. Deshalb wird die Fml nun aber nicht plötzlich zur MatrixFml, denn diese ist stets durch die automatisch (bei entsprd EingabeAbschluss) gesetzten {} gekennzeichnet und kann sowohl nur einen als ggf auch mehrere Werte* liefern (deshalb haben hierfür diverse KalkulationsPgmm auch unterschiedl Lösungen entwickelt!). Fehlen die {}, handelt es sich auch nicht um eine MatrixFormel, sondern höchstens um eine Fml, die eine MatrixFunktion verwendet! Das ist ein nicht unbeträcht­licher Unterschied!
* Manche MatrixFmln, die nur ein Ergebnis liefern soll(t)en, benötigen einen Auslöser der Xl-Matrix-Automatik, um ein richtiges Ergebnis zu ermitteln. Sie sind also quasi 1zellig, benötigen aber mind 2 Zellen, die dann das gleiche richtige Ergebnis zeigen. Nicht alle dieser Fmln lassen sich durch andere ersetzen, höchstens unter Einsatz von Hilfszellen.
Gruß, Luc :-?

Anzeige
habe allerdings eine andere Sicht ...
14.04.2015 19:35:20
der
Hallo Luc,
... als Deine hier dargestellte.
Mir mangelt es aber momentan u.a. auch an Zeit um meine präzise darzulegen und zu begründen. Ich versuch nun nur mal auf die Schnelle mal meine unwissenschaftliche Sicht darzulegen:
Für mich gibt es in Excel "Normal-"Funktionen wie z.B. SUMME() u.a.m., die zunächst im einfachsten Fall Bereichsangaben auswerten. Genaugenommen wird aber bereits da schon eine Matrix (von Zellenwerten) ausgewertet. Aber nur wenige werden deswegen diese Funktionen gleich als MATRIXFunktionen bezeichnen, wie das z.B. für SUMMENPRODUKT() der Fall ist.
Für mich zeichnet sich eine (gute) Excel-Matrixfunktionen dadurch aus, dass sie ohne zusätzliche Sonderbehandlung in der Lage ist, nicht nur Bereichsangaben auszuwerten. Sondern eine solche Funktion kann auch solche Matrizen auswerten, die durch die Funktion erst vor der Endauswertung generiert werden (wenn die Funktion in der Formel mit entsprechend Argumente gefüttert wurde). Und wenn das dann der Fall ist, ist die damit erstellte Formel für mich eine Matrixformel (eine "{}-freie-"). Es gibt nun aber eine Reihe von "Bedürfnissen", die mit Hilfe von einigen Matrixfunktionen in einer Formel nicht "befriedigt" werden können. Für diesen Fall gibt es nun eben eine zusätzliche Excel-Funktionalität, Formeln mit "normalen" Bereichsfunktionen (manchmal auch mit Matrixfunktionen) zu einer erweiterten Matrixauswertungsfunktionalität zu verhelfen. Diese wird nur dann aktiviert, wenn eine Formeleingabe eben mittels dem klassischen "Fingerbrecher" abgeschlossen wird. Diese Formelart gibt es sowohl in der "einzelligen" wie auch für die mehrzellige Ausführung (allerdings betrachte ich persönlich letztere eher als einen "Sonderling", weil diese mE in viel zu seltenen Fällen wirklich sinnvoll einsetzbar ist und in der Praxisanwendung auch zu starr ist).
Es gibt nun Formeln die werden mit der {} Eingabe abgeschlossen, obwohl es dessen gar nicht bedarf und es gibt Formeln die ohne diese Funktionalität fast immer etwas falsches oder ungewolltes ermitteln. Es gibt aber andererseits auch viele {}-Formeln die (auch ohne Hilfszellen) alternativ ohne {} konstruiert werden können und einen gleichen/ähnlichen "Auswertungsmechanismus" unterliegen.
Ich werde jedenfalls immer bei bestimmten Formelkonstrukten von Matrixformel reden, egal ob mit oder ohne {}. Deswegen schreibe ich (auch schon sehr lange) einerseits von {}- oder anderseits von {}-freien Matrixformeln.
Ein Argument was noch für meine Sicht spricht, sind spez. {}-freie Formelkonstrukte, wie sie beispielhaft auf bestimmte INDEX()- und oder VERWEIS(9;1/(...)) bzw. auch AGGREGAT()-Formeln zutreffen. Bei den vorgenannten, handelt es sich auch meist um Formeln, in denen Funktionskombinationen eingesetzt werden. Das sind und bleiben für mich MATRIXFormeln, solange ich nicht überzeugendere Gegenargumente finde.
Ich betrachte Deine Sicht nicht als falsch, aber ich wollte, nein musste schon auch meine Sichtweise hier zumindest ergänzend einbringen.
Gruß Werner
.. , - ...

Anzeige
Deine Sicht in Ehren, ...
14.04.2015 21:32:38
Luc:-?
…Werner,
aber die Grundlage der Arbeitsweise einer Fkt ist deren Pgmmierung, die Grundlage der Arbeitsweise von Fmln, die Pgmmierung von Xl. Eine andere Kalkulationssoftware kann das auch anders lösen als Xl (ganz ohne {}, die sind nur ein optisches Kennzeichen). In OO/LO bspw muss man ein Kästchen im FmlAssi anhaken; in einer Linux-GNU-KalkSoftware wird der Fml automatisch eine Bereichsangabe in eckigen Klammern hinzugefügt. Alle so gekennzeichneten Fmln sind MatrixFmln, d.h., die ZellEigenschaft .FormulaArray enthält einen wirksam werdenden Fml-Eintrag. Allerdings ist das Entscheidende wahrscheinlich ein interner Vermerk, der in Xl mit dem ZellFml-Abschluss angelegt wird. In benannten Fmln entfällt dieser bekanntlich, so dass Xl immer alle Werte berechnet und letztlich bei der Beurteilung, ob MxFml oder nicht, von der ZellFml ausgeht, in der der Name verwendet wird, was ggf zu Problemen führen könnte, wenn das keine ZellFml ist. Kommt es zu keinen Problemen, hat diese Fml auch alle Werte auf 1× oder nacheinander pro Anwendungszelle erhalten.
MS unterscheidet bei seiner SprachRegelung zwischen MatrixFmln und MxFktt, wobei diese Kategorie nicht die höchste Priorität hat (steht ein anderer KategorieAspekt im Vordergrund, wird die Fkt dort zugeordnet). Somit gelten in 1.Linie auswählende Fktt als MxFktt, u.a. INDEX, INDIREKT, S/W/VERWEIS, VERGLEICH, WAHL. Allen diesen Fktt ist gemeinsam, dass sie eine Wahl aus einem Vektor bzw einer Matrix (bzw einer Liste) von Werten treffen. Das machen SUMME und SUMMENPRODUKT nicht, sie nehmen stets die ganze Matrix, wobei der Unterschied zwischen beiden darin besteht, dass SUMME einfach alle Werte seiner Argument-Bereiche bzw -Datenfelder addiert, SUMMENPRODUKT aber erst alle seine Argument-Bereiche/-Datenfelder elementweise miteinander multipliziert und erst diese Ergebnisse addiert, also eine ProduktSumme bildet. Dabei wird intern entweder ein Werte-Datenfeld als ZwischenErgebnis erzeugt oder die Produkte wdn flfd addiert. Prinzipiell besteht also kein programmatischer Unterschied zu SUMME, nur in der mathematischen Grundlage, die ein komplexeres Pgm zur Folge hat. Das gilt dann übrigens auch für einige andere spezielle ProduktSummen, von denen aber noch niemand behauptet hat, sie wären MxFmln oder würden deren Fktionalität einschließen, was ihrer eher seltenen Verwendung geschuldet sein mag.
Ich bezeichne diejenigen meiner UDFs, die so etwas können, ja auch nicht als MxFktt oder gar -Fmln! ;-]
Es ist also ganz normal, dass eine (Xl-)Fkt ganze Bereiche oder DFelder verarbeiten kann. Zu etwas Besonderem wird es dann, wenn ein FktsArgument skalar vorgesehen ist, aber in einer MxFml auch mit einem Bereich bzw Datenfeld fktioniert. Dann aber idR nur mehrzellig!
Auch, wenn du mehrzelligen MxFmln quasi die ExistenzBerechtigung absprichst, gibt es sie doch! Und sie haben nicht nur ihre Berechtigung, sondern stellen sogar den Prototyp der MxFml dar! Anders könnte man nämlich niemals mehrere ErgebnisWerte, für die es unterschiedliche (auch mathematische!) Gründe geben kann, mit einer Fml bzw Fkt ausgeben. Auch lässt sich nicht alles über Hilfszellen regeln, sonst gäbe es vermutlich gar keine MxFmln (in Xl)!
Jetzt alles umzukehren und die 1zellige MxFml zum Prototyp machen zu wollen, wirkt auf mich wie „das Pferd beim Schwanze aufzuzäumen“. Die 1zellige MxFml ist der Sonderfall (die 2zellig-1zellige viell sogar weniger) und nicht umgekehrt!
Gruß, Luc :-?

Anzeige
Aber worum's dir wohl geht, was dich (und ...
15.04.2015 03:09:18
Luc:-?
…andere Nur-Fml-Freaks) auf diese Idee bringt, Werner,
ist vermutlich die unkonventionelle Anwendungs­möglichkeit von SUMMENPRODUKT mit nur einem Argument, das selbst aus einer TeilFml (einem sog Ausdruck) besteht und deshalb zuerst berechnet wird. Das ist aber auch nichts Besonderes, denn das passiert bei anderen Fktt, die Daten­felder verar­beiten können, auch; =SUMME({1;2;3}*{4;5;6}) benötigt auch keine MxFml-Form, {=SUMME(ZEILE(1:3)*ZEILE(4:6))} schon, aber das liegt an der Fkt ZEILE und daran, dass SUMME die automa­tische Variation der Ergebnisse von ZEILE nicht übernimmt! Dagg rechnete der Pgmierer von SUMMENPRODUKT von vorn­herein mit Daten­feldern (was bei SUMME nicht zwingend erfor­derlich ist) und hat wohl deshalb dafür Sorge getragen, dass auch in nur einer Zelle alle Werte eines Daten­feldes verwendet wdn, also die Werte-Variation intern nachvoll­zogen wird, so dass …
=SUMMENPRODUKT(ZEILE(1:3)*ZEILE(4:6))
…auch ohne MxKlammern auskommt. Das ist aber etwas Anderes, da es sich um die normaler­weise von der Xl-Automa­tik besorgte Werte-Variation von Daten­feldern (hier aus ZEILE) anstelle skalarer Werte handelt. Um so etwas mit VBA nachbauen zu können, müsste man auf den kompletten Fml­Text in US-Original-Notation zurück­greifen. Möglicher­weise gehört das mit zu dem, was MS mit Fml-Optimie­rung meint. Aller­dings wurde so etwas eher selten genutzt, obwohl die MS-Pgmierer ja naturgemäß über Schnitt­stellen­Kenntnisse verfügen, die ein externer VBA-Pgmierer normaler­weise nicht hat, und deshalb die Xl-Automatik nur über die vbFkt Evaluate in fml-bezogen vollem Umfang nutzen kann. Als VBA-Container-Fkt ist WorksheetFunction.SumProduct ja auch nur klassisch verwendbar!
Übrigens, schon bei dem von dir geliebten INDEX wird das nicht mehr gemacht. Die Werte-Variation der primär skalaren Argumente ist nahezu allein von der ZellAuswahl abhängig und nur begrenzt für unzu­sammen­hängende Bereiche möglich. Deshalb ist INDEX aber trotzdem eine MxFkt, die in einer mehrzelligen MxFml auch mehrere Ergebnis­Werte liefern kann.
Letztendlich handelt es sich bei dieser Begriffs­vermen­gung um den Vgl von Äpfeln mit Birnen, denn die hier zugrunde­liegende Problematik ist eigentlich eine andere, die aber durchaus mit MxFmln zusammen­hängt.
Übrigens kann man so auch die mal vorhandene, mal fehlende sog MxFktionalität von AGGREGAT erklären!
Luc :-?

Anzeige
Für spätere interessierte Nachleser
15.04.2015 18:23:48
Luc:-?
Hier geht's noch etwas weiter!
Luc :-?

Beliebteste Forumthreads (12 Monate)

Anzeige

Beliebteste Forumthreads (12 Monate)

Anzeige
Anzeige
Anzeige