Das weiß ich, Werner, aber das zwingt mich ...
16.04.2015 18:06:31
Luc:-?
…auch zu stärkerer Systematisierung! ;-)
Aber bevor ich auf deine neuerlichen Argumente eingehe, hier erst mal die Nachlieferung meiner MxFml-Kategorisierung, die neben der Zelligkeit noch eine Stufigkeit der Berechnung postuliert. Beide wdn dann nach ein- und mehr- unterschieden:
1. 1zellig/1stufig ⇒ Anwendung problemlos möglich; es werden stets alle Quellwerte in nur 1 Ergebniswert einbezogen.
2. mehrzellig/1stufig ⇒ Anwendung ebenfalls problemlos möglich; die (unterschiedlichen) Ergebniswerte werden nur in den markierten Zellen angezeigt und nur diese können dann sekundär weiterverarbeitet werden.
3. 1zellig/mehrstufig ⇒ Anwendung ist so nicht möglich; es müssen stets mindestens 2 Zellen angegeben werden, um alle Ergebniswerte unterer Stufen einzubeziehen; es wird trotzdem nur 1 (in allen markierten Zellen stets gleicher) Ergebniswert geliefert. So verhalten sich bspw oft Matrixformelsummen komplexer, Datenfelder liefernder Ausdrücke.
4. mehrzellig/mehrstufig ⇒ Anwendung ebenfalls problemlos möglich; es werden stets alle Ergebniswerte unterer Stufen einbezogen, aber nur in den markierten Zellen angezeigt.
Die XlFktt ZEILE und SPALTE liefern bspw stets Felder (auch aus nur einem Wert), nicht nur, wenn sie im Argument einen mehrzelligen Bereichsbezug enthalten u/o als Matrixformel abgeschlossen werden.
Und genau das scheint bei der Pgmmierung von SUMMENPRODUKT berücksichtigt worden zu sein. Dabei ist natürlich zu bedenken, dass die Pgmmierg sicher nicht in VBA erfolgt ist, das gab's damals wohl noch nicht, und der Pgmmierer Zugriff auf Xl-Schnittstellen hatte, den ein externer Pgmierer nicht hat, so dass es ihm eher möglich war als mir, die Argumente einer Fkt auch als Ausdruck, nicht nur als Wert, zu isolieren. Um das mit VBA halbwegs exakt zu simulieren, ist ein ziemlicher Aufwand erforderlich. Ich habe es trotzdem versucht. Dabei ist Folgendes herausgekommen:
| | A | B | C | D | E |
| 11 | 15 | 15 | 15 | 15 | 15 |
| 12 | 9 | 9 | 9 | 9 | 9 |
| 13 | 9 | 9 | 9 | 9 | 9 |
| 14 | A11:=PSumme1(ZEILE(1:5)) |
| 15 | A12:=PSumme1(ZEILE(1:5)*REST(ZEILE(1:5);2)) |
| 16 | A13:=PSumme1(WENN(REST(ZEILE(1:5);2)=0;0;ZEILE(1:5))) |
| 17 | B11:=PSumme2(ZEILE(1:5)) |
| 18 | B12:=PSumme2(ZEILE(1:5)*REST(ZEILE(1:5);2)) |
| 19 | B13:=PSumme2(WENN(REST(ZEILE(1:5);2)=0;0;ZEILE(1:5))) |
| 20 | C11:=SUMMENPRODUKT(ZEILE(1:5)) |
| 21 | C12:=SUMMENPRODUKT(ZEILE(1:5)*REST(ZEILE(1:5);2)) |
| 22 | C13: {=SUMMENPRODUKT(WENN(REST(ZEILE(1:5);2)=0;0;ZEILE(1:5)))} |
| 23 | D11: {=SUMME(ZEILE(1:5))} |
| 24 | D12: {=SUMME(ZEILE(1:5)*REST(ZEILE(1:5);2))} |
| 25 | D13: {=SUMME(WENN(REST(ZEILE(1:5);2)=0;0;ZEILE(1:5)))} |
| 26 | E11:=TransFor("SUM(ROW(1:5))") |
| 27 | E12:=TransFor("SUM(ROW(1:5)*MOD(ROW(1:5),2))") |
| 28 | E13:=TransFor("SUM(IF(MOD(ROW(1:5),2)=0,0,ROW(1:5)))") |
| 29 | keine MxFml - Auswertung auf SUM-Basis |
| 30 | keine MxFml - teilweise Auswertung |
| 31 | keine MxFml - teilw Auswertung unter Hinzufügung von SUM |
| 32 | keine MxFml - Original |
| 33 | MxFml - Original |
Dass du UDF-Bspp generell für unglücklich gewählt hältst, war zu erwarten. Aber dass eine Fml mitunter auch durch eine andere ersetzt wdn kann, ändert doch nichts an der Tatsache, dass eine x-beliebige Fml so fktioniert wie sie eben fktioniert. Das wäre mir zu zweckpraktisch gedacht — wahre Wissenschaft muss die Dinge erklären wie sie sind und nicht, falls eine Tatsache nicht ins Bild passt, einfach etwas Anderes dahernehmen (ob wohl das mitunter auch anzutreffen ist, besonders in den nichtexakten Wissenschaften → in der Archäologie hat sich das deutlich verbessert, obwohl immer noch scheinbar festgefügte Lehrmeinungen großen Einfluss ausüben, in der Ökonomie liegt's noch sehr im Argen, Wunschvorstellungen dominieren den neoliberalen Mainstream), alles Andere wäre unwissenschaftliche Scharlatanerie (naja, das Mittelalter feiert gerade wieder „fröhliche Urständ“, und das leider nicht nur auf MA-Spektakeln und -Märkten).
Und damit du auch (fast) alle Bspp nachvollziehen kannst, hier noch die Pgmm der beiden UDFs PSumme1&2:
Function PSumme1(ParamArray Bezug())
Const myName$ = "PSumme1("
Dim klAnz As Long, pos(1) As Long, fml$
If UBound(Bezug) 0 Then
fml = Replace(fml, ",", Chr(0)): fml = Split(fml, Chr(0))
On Abs(UBound(fml) UBound(Bezug)) GoTo nz
Else: fml = Array(fml)
End If
ReDim avParm(UBound(Bezug))
For Each x In fml
isRoCoX = False
While x Like "*ROW(*#:*#)*"
pos = InStr(x, "ROW(")
pFml = Mid(x, pos, InStr(pos, x, ")") - pos + 1)
aFml = "{" & Join(wf.Transpose(Evaluate(pFml)), ";") & "}"
x = Replace(x, pFml, aFml): isRoCoX = True
Wend
While x Like "*COLUMN([A-Z]*:[A-Z]*)*"
pos = InStr(LCase(fml), "row(")
pFml = Mid(fml, pos, InStr(pos, fml, ")") - pos + 1)
aFml = "{" & Join(wf.Transpose(Evaluate(pFml)), ",") & "}"
x = Replace(x, pFml, aFml): isRoCoX = True
Wend
If isRoCoX Then
avParm(ix) = Evaluate(x)
If Not IsArray(avParm(ix)) Then avParm(ix) = "sum(" & x & ")"
End If
ix = ix + 1
Next x
End If
nz: For ix = LBound(Bezug) To UBound(Bezug)
If IsArray(Bezug(ix)) Then
For Each x In Bezug(ix)
If IsNumeric(x) Then PSumme2 = PSumme2 + x
Next x
ElseIf Not IsEmpty(avParm(ix)) Then
If IsArray(avParm(ix)) Then
For Each x In avParm(ix)
If IsNumeric(x) Then PSumme2 = PSumme2 + x
Next x
ElseIf Not IsNumeric(avParm(ix)) Then
If Left(avParm(ix), 4) = "sum(" Then
avParm(ix) = Evaluate(avParm(ix))
If IsNumeric(avParm(ix)) Then PSumme2 = PSumme2 + avParm(ix)
End If
ElseIf IsNumeric(avParm(ix)) Then
PSumme2 = PSumme2 + avParm(ix)
End If
ElseIf IsNumeric(Bezug(ix)) Then
PSumme2 = PSumme2 + Bezug(ix)
End If
Next ix
fx: If CBool(Err.Number) Then PSumme2 = CVErr(Err.Number)
Set wf = Nothing
End Function
Ich bitte evtl andere Interessenten zu beachten, dass diese Fktt allein der Simulation des DiskussionsGgstandes im dargestellten Umfang dienen und keinen Anspruch auf universelle Einsetzbarkeit erheben!
Wie man sehen kann, erhält in diesem Fall auch SUMME alle Werte. Durch die Eingabe als MxFml wird der Fkt nur mitgeteilt, welche es auch verwenden soll. Gibt man die Fml nicht als MxFml ein, verwendet sie nur den ersten der von ZEILE gelieferten. SUMMENPRODUKT hingg verwendet alle, sofern diese nicht über eine mehrstufige Operation erst zusammengesetzt wdn (müssen). Deshalb habe ich auch den Begriff der Stufigkeit (von RechenOperationen) eingeführt. Eine einfache Multiplikation von Vektoren (auch als Ergebnis einer auf einer relativ einfachen RechenOperation basierenden Fkt) fällt nicht darunter. Interessanterweise ließ sich gerade das (Ergebnisse der 2.Zeile) nicht so einfach mit PSumme2 simulieren. Ich musste dem intern die XlFkt Sum[me] hinzufügen, sonst wäre ebenfalls eine MxFml vonnöten gewesen.
Bei einer quasi (PSumme1, 1.Spalte) bzw real (letzte Spalte) GesamtAuswertung der Fml ist nie eine Eingabe als MxFml erforderlich, was meine gerade zuvor getroffene Aussage bestätigt.
Gruß, Luc :-?