Anzeige
Anzeige
HERBERS
Excel-Forum (Archiv)
20+ Jahre Excel-Kompetenz: Von Anwendern, für Anwender
Vorheriger Thread
Vorheriger Thread
Rückwärts Blättern
1520to1524
1520to1524
Aktuelles Verzeichnis
Verzeichnis Übersicht
Verzeichnis Übersicht
Übersicht Verzeichnisse
Nächster Thread
Nächster Thread
Vorwärts blättern
Inhaltsverzeichnis

Versalien formatieren

Forumthread: Versalien formatieren

Versalien formatieren
20.10.2016 15:13:57
hammsi
Liebe Ex(cel)perten!
Wisst ihr wie ich in einer Spalte jene Wörter markieren kann, die rein in Versalien geschrieben sind? Bin leider trotz längerer Webrecherche gescheitert ...
Vielen Dank und LG,
Hammsi
Anzeige

43
Beiträge zum Forumthread
Beiträge zu diesem Forumthread

Betreff
Datum
Anwender
Anzeige
AW: Versalien formatieren
20.10.2016 15:26:16
Michael
Hallo Hammsi!
in einer Spalte jene Wörter markieren kann, die rein in Versalien geschrieben sind
Die Frage ist halt, wie das in Deinem Fall aussieht? Was steht da in den Zellen, was davon in Großschrift und was soll dann wie markiert werden?
Userbild
Was davon entspricht Deinen Gegebenheiten? Was davon sollte dann markiert werden?
Fragen über Fragen...
LG
Michael
Anzeige
AW: Nachfrage..
20.10.2016 15:26:38
UweD
Sind es Einzelwörter oder mehrere Wörter je Zelle
Beispieldatei?
AW: bed. Formatierung
20.10.2016 15:30:27
CitizenX
Hi,
markieren deine Zellen und füge eine neue bedingte Formatierung ein, mit der Formel:
=IDENTISCH(A7;GROSS(A7))
Adressen natürlich anpassen.
VG
Steffen
AW: bed. Formatierung
20.10.2016 16:37:26
hammsi
Danke Steffen, das rockt!!!
Anzeige
AW: Versalien formatieren
20.10.2016 16:06:03
EtoPHG
Hallo Hammsi,
Wieso willst du die WÖRTER noch zusätzlich markieren, sie heben sich ja schon durch die Tatsache hervor, dass sie in Verbalien geschrieben sind? Wie soll denn die Markierung aussehen?
Gruess Hansueli
GUTER Punkt Hansueli ;-), lg und owT
20.10.2016 16:09:12
Michael
AW: GUTER Punkt Hansueli ;-), lg und owT
20.10.2016 16:27:54
hammsi
Hallo zusammen - und danke für die rege Beteiligung.
Ja, schande über mich, ich hab das zu wenig präzisiert. Markieren will ich's deswegen, weil ich ne Liste mit über 500.000 Zellen hab und sich gewisse Zellen in Textspalten mit farblicher Kennzeichnung odgl. zusätzlich zur Großschreibung (so kommen Sie aus einer Datenbank) besser abheben würden. Wie in diesem vereinfachten Beispiel hier würde ich also gerne A1 und A7 hervorheben: https://www.herber.de/bbs/user/108923.xlsx
Manchmal stehen in Zellen mit Großschreibung mehrere Worte, manchmal nur eines. Fakt ist, dass alle Versalien-Worte markiert werden müssten.
Vielen Dank und lg,
Hammsi
Anzeige
AW: GUTER Punkt Hansueli ;-), lg und owT
20.10.2016 17:25:02
Daniel
Hi
so wie ich deine Beispieldatei lese, möchtest die Zellen markieren, in denen alle Buchstaben Grossbuchstaben sind.
Das geht relatvi einfach mit der Formel:
 =WENN(A1"";IDENTISCH(A1;GROSS(A1)))

die Formel kannst du dann als Regel in einer Bedingten Formatierung für die Spalte A einsetzen.
Gruß Daniel
Anzeige
2 Std nach CitizenX nochmal dasselbe, obwohl ...
20.10.2016 17:56:12
Luc:-?
…der schon BedingtFormatierung im Betreff zu stehen hatte! Und dann noch weniger an die Form einer BedFmtRegel angepasst! Tolle Leistung — Isi lässt grüßen…! :->
Luc :-?
AW: 2 Std nach CitizenX nochmal dasselbe, obwohl ...
20.10.2016 18:01:13
hammsi
Doppelt hält immer besser ;)
Schönen Abend!
AW: nicht das selbe, sondern verbessert
20.10.2016 18:11:18
Daniel
weil es wahrscheinlich nicht im Sinne von Hammsi ist, Leerzellen farblich zu markieren, so wie es die Formel von CitizenX macht.
ausserdem wählte er eine relativ nichtsagende Betreffzeile, welchen keinen Rückschluss auf die den Thread, auf den er sich beziehet zulässt, und somit war in der Beitragsliste dies nicht erkennbar.
und warum die meine Formel weniger an die Form einer Bedingten Formatierung angepasst ist, müsstest du mal genauer erläutern.
Gruß Daniel
Anzeige
Na, gut, Leerzellen! Aber WENN liefert nicht ...
21.10.2016 05:22:18
Luc:-?
…immer direkt Wahrheitswerte wie hier, Daniel,
und nur die benötigt ja die BedingtFormatierung, andere müssten erst (automatisch) umgewandelt wdn. Deshalb wird WENN auch kaum mal in einer Regel benötigt. Hier könnte man es auch durch UND ersetzen.
Warum du dich so permanent auf die Beitragsliste versteifst, ist mir unklar, aber wahrscheinlich hat das den gleichen Grund wie die häufigen TippFehler → Handy-Surfing. Da musst du ja nur noch am Tippen sein, bei deinen vielen Postings in mind 2 Foren und den häufig langen Texten… Wahnsinn! :-]
Gruß, Luc :-?
Anzeige
AW: Na, gut, Leerzellen! Aber WENN liefert nicht ...
21.10.2016 08:29:34
Daniel
Wenn liefert die Werte, die ich vorgebe, und wenn ich so wie hier Wahrheitswerte vorgebe, dann liefert Wenn auch Wahrheitswerte, so dass nichts umgewandelt werden muss.
Der Vorteil der Verwendung von Wenn gegenüber Und ist, dass bei Und immer alle Zellen mit Gross umgewandelt und mit Identsich verglichen werden, während bei Wenn nur diejenigen Zellen so berechnet werden, die auch einen Wert enthalten.
Somit reduziert die Verwendung von Wenn zur Kombination von zwei Bediungsprüfungen die Rechenlast, weil nicht mehr beide Prüfungen immer durchgeführt werden, sondern nur eine immer und die zweite (oder weitere) nur dann wenn es auch erforderlich ist.
was die verschiedenen Listen angeht Luc, so ist es so, dass ich, wenn ich sehen will ob irgendwo neue Beiträge hereingekommen sind, die Forumsliste vollständig durchsuchen müsste, während ich sie in der Beitragsliste sofort auf einen Blick sehe.
Und wie du schon festgestellt hast, ich verwende meine Zeit lieber, um Beiträge zu schreiben als sie mit Suchen nach Beiträgen zu verschwenden.
Gruß Daniel
Anzeige
Aha, dafür ist eigentlich NOCH OFFEN gedacht, ...
23.10.2016 01:46:09
Luc:-?
…aber Vielschreibern wie dir, Daniel,
ist offensichtlich egal, was da reinkommt, Hptsache neu und du kannst dich wieder mit etwas beschäftigen. Hast du eigentlich sonst nichts zu tun…?! :->
Mein Browser markiert übrigens alles, was ich schon gelesen hatte und völlig Neues steht ohnehin immer ganz oben. Insofern muss es wohl doch an deinem Zugangs- und Arbeitsmittel (kleiner Screen) liegen.
Luc :-?
Anzeige
Und dass dein WENN-Konstrukt Wahrheitswerte ...
23.10.2016 02:05:20
Luc:-?
…liefert, Daniel,
hatte ich bereits erwähnt, musstest du also nicht wiederholen. Außerdem bezweifle ich, dass GROSS versucht, irgendwelche SonderZeichen umzuwandeln. Das dürfte sich allein auf Buchstaben (auch anderer Alfabete und Sonderformen) beschränken. Kannste ja mal bspw mit Griechisch testen → klappt!
Userbild
Luc :-?
Anzeige
AW: Und dass dein WENN-Konstrukt Wahrheitswerte ...
23.10.2016 04:17:25
Daniel
Luc, du hast nicht verstanden, was ich sagen wollte.
Wenn(Bedingung1;Bediungung2) ist effizienter als Und(Bedingung1;Bediungung2), weil bei UND die Bedingung2 immer berechnet wird, während sie bei Wenn nur dann berechnet wird, wenn die Bedinung1 erfüllt ist, also wahrscheinlich weniger oft.
Über Sonderzeichen schrieb ich nichts. hier gings ja auch um Leerzellen.
Gruß Daniel
Anzeige
Da hast du insofern recht, da ich an Leerzeichen,…
24.10.2016 04:13:40
Luc:-?
…nicht -zelle, dabei dachte, Daniel,
aber "" ist ja auch ein Zeichen, nämlich Chr(0). Und WENN hat hier genausoviel Argumente wie UND, nämlich 2. Ich habe mal gelernt, dass ein Vgl durch mehr interne Operationen realisiert wdn muss als eine einfache arithmetische Berechnung. In deiner WENN-Fml wdn (1?-)2 durchgeführt, in einer analogen UND-Fml wdn es wahrscheinlich immer 2 sein, weil UND in Xl eine Fkt ist, deren Argumente hier aus Ausdrücken (TeilFmln) bestehen, die zuerst berechnet wdn, falls Xl das nicht (wie von MS allgemein für alle Fmln behauptet) irgendwie optimiert. Dann würde bei einem logischen And erst das 1.Argument berechnet wdn und, falls das schon FALSCH ist, nicht noch das 2. Aber damit kann man wohl nicht unbedingt rechnen. Allerdings sind BedingtFormat-Regeln auch keine ganz normalen Fmln, sondern unterliegen Einschränkungen.
Aber WENN ist auch eine Fkt und unterliegt der gleichen Xl-Optimierung. Insofern kann genausogut auch angenommen wdn, dass hier ebenfalls immer beide Argumente berechnet wdn, also auch stets 2 Vgle durchgeführt wdn! Bei der vbVariante IIf (auch eine Fkt!) ist das jedenfalls so. Nur eines ist bei der WENN-Variante wirklich sicher → das fehlende 3.Argument wird nicht berechnet, sondern nur gesetzt — hier FALSCH, bei angegebenem ; als 0.
Gruß, Luc :-?
Anzeige
AW:Optimierungen in Berechnungsformeln
24.10.2016 10:10:47
Daniel
Hi Luc
warum viel vermuten, was man einfach ausprobieren kann?
Du erstellst ja sonst auch gerne deine Formelvergleiche.
Hier musst du nur überprüfen, welche dieser Formelvarianten den DIV/0-Fehler als Ergebnis haben und welche einen Wahrheitswert ausgeben, wenn die Zelle A1 leer oder 0 ist.
Dann siehst du, ob in der Formel beide Bedinungen berechnet werden oder nur die erste.
=Wenn(A1>0;B1/A1>0)
=Und(A1>0;B1/A1>0)

um zu sehen, ob die Formeln in der Bedingten Formatierung genauso arbeiten, müsste man sie für die Regel noch in IstFehler kapseln, da man in der Bedingten Formatierung nicht erkennen kann, ob die die Regel FALSCH oder einen Fehler als Ergebnis hat.
dass sich VB-Funktionen etwas anders Verhalten als namensgleiche Excelfunktionen, ist ja keine Seltenheit, sondern kommt öfters vor (Runden/Round, Glätten/Trim)
Gruß Daniel
Anzeige
Ich hatte dich tatsächlich nicht verstanden, ...
24.10.2016 19:02:47
Luc:-?
…Daniel,
weil ich mir nicht vorstellen konnte, dass jemand der so oft und gern über Xl-Mechanismen schreibt, so wenig Ahnung von der Fkts­weise von Fmln und Fktt in Xl hat. Deshalb hat mich auch bei meiner letzten AW dein Denkfehler eine zeitlang irritiert, obwohl ich das zum Schluss doch noch gemerkt habe.
Deshalb jetzt nochmal ganz deutlich zu allgemeinem Verständnis:
In einer Fml wdn stets alle ihre Teile berechnet! Das gilt auch für als Argument einer Fkt übergebene TeilFmln, sog Ausdrücke (expressions), die auch Matrix­Konstanten beinhalten! Folglich wdn in beiden FmlVarianten stets beide Argumente berechnet! Das kann man bei einer ZellFml auch ganz leicht per Fml-Assistent überprüfen und dürfte auch in einer Regel-Fml nicht anders sein!
Beide Fktt wurden von MS der Kategorie Logische Fktt zugeordnet, was aber im Falle von WENN nur darauf beruht, dass ihr 1.Argu­ment ein Wahrheitswert sein oder einen solchen ergeben muss. Im Grunde genommen handelt es sich bei dieser Fkt aber um eine Verteiler-, Verzweigungs- bzw Auswahl-Fkt ala PAP-Konstrukten wie P{a=b}, ganz analog der Xl-Fkt WAHL, die der Kategorie Nachschlagen und Verweisen zugeordnet wurde. In VBA entspricht IIf der XlFkt WENN (weshalb es auch keine WorksheetFunction.If gibt) und ist rein formal an If…Else-Konstrukte angelehnt, fktioniert aber als Fkt nicht genauso wie diese; WENN natürlich erst recht nicht, was du aber anzunehmen scheinst. Mit der Xl-Fkt WAHL wäre allenfalls die vbFkt Switch vglbar, die aber eher ein erweitertes IIf ist und somit Select Case-Konstrukten nahe steht, aber als Fkt natürlich nicht genauso fktionieren kann.
Und jetzt noch der von dir vermisste FmlVgl auf Basis der von den Fktt eigentl erwarteten Argument­Werte (WENN erwartet nur das 1.Argument so und WAHL nicht mal das):
 ABCDEF
1
Argument1Argument2UND 2WENN 1+1WENN 2WAHL 2+1FALSCHFALSCHFALSCHFALSCHFALSCHFALSCHWAHRFALSCHFALSCH0FALSCH0FALSCHWAHRFALSCHFALSCHFALSCHWAHRWAHRWAHRWAHR0WAHR0C2[:C5]:=UND(A2;B2)D2[:D5]:=WENN(A2;)E2[:E5]:=WENN(A2;B2)F2[:F5]:=WAHL(A2+1;B2;)
2
3
4
5
6

Dabei sollte beachtet wdn, dass UND als echte Logik-Fkt eine reine (Trivial-)Berechnung, keinen Vgl durchführt, und WENN ebenfalls nicht, aber mit seinem 1.Argument eine Auswahl zwischen den nachfolgenden trifft. Was von Beidem nun schneller ist, kannst du ja mal testen (so'n paar 10Tsd Fmln reichen ggf)… :->
Da die Ausdrücke für die Argumente in den zur Diskussion stehenden Fml-Varianten ansonsten gleich sind (IDENTISCH liefert einen Wahrheitswert als Ergebnis), kann deren Berechnungsdauer vernachlässigt wdn.
Einen Unterschied zwischen WENN als ZellFml und als BedFormat-Regel gibt's aber auf jeden Fall — in einer ZellFml kann man als Argumente auch ganze ZellBereiche bzw Datenfelder angeben, in einer Regel nicht. In beiden Fällen sorgt aber die allgemeine Xl- bzw spezielle BedingtFormat*-Steuerung dafür, dass im Endeffekt auch diese verarbeitet wdn können.
* Diese variiert Argumente ggf über den Geltungsbereich, Xl allgemein über die Vorgabe im Argument, weshalb beides (bei RegelFmln) einander ausschließt.
Luc :-?
Anzeige
Ich hab ja keine Ahnung, aber das ist meine Beobac
24.10.2016 19:30:49
Daniel
Hi Luc
danke für die ausführliche Beschreibung.
trotzdem würde ich dich bitten, mal folgendes zu tun:
1. diesen Code in ein allgemeines Modul: 
Function Test()
MsgBox "Test"
End Function
2. diese Formel in die Zelle A1: 
=Wenn(B1=1;Test())
3. gib mal verschiedene Werte in B1 ein, u.a. 1, aber auch andere.
Wenn du recht hättest und immer alle Formelteile berechnet werden würden, müsste die Messagebox bei jeder Änderung in B1 erscheinen
Wenn ich recht habe und der Wahrteil der Wennfunktion nur dann berechnet wird, wenn die Bedinungsprüfung WAHR ist, dann dürfte die Messagebox nur dann erscheinen, wenn du eine 1 eingibst und in allen anderen Fällen nicht.
bei mir kommt die Messagebox nur dann, wenn ich eine 1 Eingebe, sonst nicht (Excel 2013).
Gruß Daniel
Anzeige
AW:noch ein Irrtum deinerseits, Luc:
25.10.2016 00:49:32
Daniel
du schreibst:
"Mit der Xl-Fkt WAHL wäre allenfalls die vbFkt Switch vglbar,"
ist ist aber falsch, die zu WAHL direkt vergleichbare vbFunktion ist CHOOSE
zu SWITCH gibt es erst in der allerneusten Excelversion (Office365, 2016) ein Excel-Pendant, nämlich WENNS
aber bei allen drei vbFunktionen IIF, SWITCH und CHOOSE gibt MS in der Hilfe deutlich den Hinweis, dass diese immer alle Formelteile auswerten und es zu "unerwünschten Nebeneffekten" führen kann, wenn ein Formelteil einern Fehler hat.
In den Hilfetexten zu den Excelfunktionen WENN, WAHL und WENNS fehlt dieser Hinweis, wahrscheinlich aus gutem Grund.
Es wäre auch fatal, wenn diese Excelfunktionen sich genauso verhalten würden wie die VBA-Funktionen, weil es in Excel nicht möglich ist, eine Alternative zu verwenden.
Gruß Daniel
Anzeige
Ich schrieb ja 'allenfalls', aber natürlich ...
25.10.2016 04:05:08
Luc:-?
…passt die tatsächlich existierende vbFkt Choose besser auf WAHL, Daniel,
entspricht ihr gar weitgehend, obwohl ja beide zusammen mit IIf u.a. in der gleichen VBA-Klasse Interaction zu finden sind. Und dass mit WENNS in den neuesten Versionen nun auch Switch ein Xl-Pendant gefunden hat, lässt ja auf Künftiges hoffen…
Aber das wäre dann ja eher etwas für die Fml-Freaks, während ich immer mehr gewillt bin, mich von der ganzen (Ver-)„Formelei“ zu verabschieden, weil ich das mittlerweile für den falschen Weg halte. Schon heute wdn wohl nur sehr spezielle Fktt in bestimmten Branchen häufiger benutzt, während der gewöhnliche Büro-Alltag idR immer noch mit einem Minimum von Standard-Fktt auskom­men dürfte…
Luc :-?
Anzeige
Gratuliere! Du hast mE als Erster (mir bekannt ...
25.10.2016 03:43:35
Luc:-?
…Gewordener) eindeutig die von MS behauptete Fml-Optimierung nachgewiesen, Daniel!
Das ist aber der Xl-Steuerung geschuldet, die die implementierten Fktt überwacht, denn ich wüsste sonst nicht, wie ein FktsPgm feststellen soll, dass ein als Ausdruck (in Form einer Fml) angegebenes Argument nicht benötigt wird und deshalb gar nicht erst berechnet wdn muss. Dass es aber im Falle von WENN wirklich nicht berechnet wird, habe ich nicht nur per MessageBox, sondern auch mit einem in die verwendete UDF eingebauten Zähler verifiziert. Das kann man mit einer UDF nicht erreichen, denn der steht diese Art externer Optimierung nicht zur Seite. Da müsste man schon eine eigene pgmmieren bzw eine Tarnung ala VW nicht benötigter, aber trotzdem anfallender Berechnungsvorgänge in eine derartige UDF einbauen.
Im Übrigen zeigt das wieder mal, dass der FmlAssi ein eigenständiges Pgm mit eigenen Regeln ist, auf dessen Ergebnis man sich nicht immer verlassen kann. Das war jetzt auch bei der Erweiterung meines Bsps der Fall:
 ABCDEFGHI
1
Argument1Argument2UND 2WENN 1+1WENN 2WAHL 2+1specIf 1+1specIf 1+f⁺¹WENN 1+f⁺¹FALSCHFALSCHFALSCHFALSCHFALSCHFALSCHFALSCHFALSCHFALSCHWAHRFALSCHFALSCH0FALSCH002 Wahr1 WahrFALSCHWAHRFALSCHFALSCHFALSCHWAHRFALSCH00WAHRWAHRWAHR0WAHR004 Wahr2 WahrC2[:C5]:=UND(A2;B2)F2[:F5]:=WAHL(A2+1;B2;)H2[:H3]:=specIf(A2;TestVal(A2))I2[:I3]:=WENN(A2;TestVal(A2))D2[:D5]:=WENN(A2;)E2[:E5]:=WENN(A2;B2)G2[:G5]:=specIf(A2;)H4[:H5]:=specIf(A4;TestVal(A4);)I4[:I5]:=WENN(A4;TestVal(A4);)
2
3
4
5
6
7

Auch das Auswerten des FmlTextes mit der UDF specIf mittels einer Evaluierungs-UDF bringt nichts, da dann der Zähler nicht mehr fktioniert, was ich in anderem Zusammenhang bei Static-Variablen schon früher bemerkt hatte. Das hatte ich dann per Übergabe dieser Variablen gelöst, was ich hier nicht getan habe, da ich nicht erwarte, dass es dann zu anderen Ergebnissen kommt. Interes­santer­weise fktioniert es aber mit WENN, nur nicht wie erwartet. Will das aber nicht als Hinweis auf eine VW-eske Mogelei werten, weil es auch andere Ursachen haben könnte.
Nun noch die verwendeten UDFs, wobei ich mich bemüht habe, mit specIf das Verhalten von WENN, soweit möglich, genau zu simulieren: 
Function TestVal(Bezug As Boolean)
Const StartZeile As Long = 2
Static aktZr As Long
If Application.ThisCell.Row = StartZeile Or _
aktZr >= 4 Then aktZr = 1 Else aktZr = aktZr + 1
TestVal = CStr(aktZr) & " " & CStr(Bezug)
End Function
Function specIf(Wenn, Dann, ParamArray Sonst())
Dim vSonst
If IsMissing(Dann) Then Dann = 0
If UBound(Sonst)
Luc :-?
Anzeige
AW: Gratuliere! Du hast mE als Erster (mir bekannt ...
25.10.2016 17:50:21
Daniel
man braucht eigentlich auch keine UDF oder zig-tausende von Formeln, um nachzuprüfen, ob in einer WENN-Funktion immer Wahr- und Falschteil berechnet werden oder nur der benötigte Teil berechnet wird.
schon eine einzige Formel dieser Art:
=Wenn(a1=1;SummenProdukt(1*(C:Z=0));"x")
dürfte genügend Rechenzeit erzeugen, um dies ohne irgendwelche Hilfsmittel feststellen zu können.
Gruß Daniel
Anzeige
Auch 'ne Möglichkeit, aber nun ist es ja auch ...
25.10.2016 19:24:58
Luc:-?
…ohne lange Rechenzeiten bewiesen, Daniel;
allerdings bringt dein Bsp wieder die Frage aufs Tapet, warum die Angabe ganzer Spalten/Zeilen so unperformant ist, wie vielfach festgestellt wird. Wird diese XlFkt nicht ebenfalls optimiert oder erfolgt diese Art von Optimierung nur in den Pgmm der Fktt wie man das auch bei einer UDF machen müsste? Gehört SUMMENPRODUKT dann evtl entweder zu nach­träglich hinzu­gefügten oder eher von vorn­herein eigen­ständig pgmmierten Fktt?
Ich gehe mal davon aus, dass der ursprüngl FktsStamm von Xl eine gewisse Einheit mit der Calcu­lation Engine (CE) gebildet hatte und gar nicht aus komplexen FktsProzeduren bestand. Folglich wurde (und wird noch) jeder FmlText zuerst analysiert, wobei P{?}-Verteilern wie bspw WENN höchste Prioritäts­Stufen zugeordnet würden. Somit würde WENN tatsächlich eher einem If…Else-Konstrukt als der vbFkt IIf entsprechen, denn nur so ließen sich ganze Teile der kompletten Fml von der Berechnung ausnehmen. Diese Xl-„Fktt“ wären dann womöglich gar keine klassischen Fktt, sondern eher so etwas wie „Entscheidungsrahmen“.
Die Analyse-Vermutung würde auch erklären, warum die Schachtelungs­Tiefe usprünglich so stark eingeschränkt war. Außerdem könnte das auch erklären, warum sich MS bis einschl Xl9/2k weder an die CE noch an die implementierten Fktt heran­gewagt hatte und zusätzliche Fktt wie die im Analyse-Tool oft von externen Auftragnehmern (eigenständig) pgmmieren ließ. Mit Xl10/2002 fing dann der „Dammbruch“ an, der sich mit Xl12/2007 fortsetzte und bis heute anhält. Neue Xl-Fktt scheinen sich nun idR recht gut ein­zufügen, während bei vielen älteren bzw ihren neuen Erweiterungen fraglich ist, ob bzw wie sie dieser Optimierung unter­worfen sind.
Gruß, Luc :-?
Anzeige
Lass die Jungs von MS erstmal aus dem Spiel...
25.10.2016 20:07:41
MS
nun Luc, es ist müßig sich über die Beweggründe von MS Gedanken zu machen. Da wir keinen Einblick in deren Entscheidungsprozesse haben, wird es sowieso nur Spekulation bleiben.
du solltest dir vielleicht eher mal Gedanken darüber machen, warum du vor kurzem noch steif und fest dieses hier behauptet hast:
"In einer Fml wdn stets alle ihre Teile berechnet! Das gilt auch für als Argument einer Fkt übergebene TeilFmln, sog Ausdrücke (expressions), die auch Matrix­Konstanten beinhalten! Folglich wdn in beiden FmlVarianten stets beide Argumente berechnet! "
obwohl es doch so einfach gewesen wäre es zu überprüfen.
was die "Unperformanz" von Summenprodukt angeht, die wird wohl deren Universalität geschuldet sein, nicht nur Excelzellbereiche wie ZählenWenn verarbeiten zu können, sondern eben auch Datenfelder, wie sie von Matrixoperationen bereit gestellt werden.
verarbeitet man einen Zellbereich, kannst man über die Eigenschaften "Usedrange" oder "LastCell" seines Worksheetojektes die Datenmenge ohne Datenverlust auf den tatsächlich genutzten Bereich reduzieren.
Bei einem reinen Datenfeld geht das natürlich nicht, und das Datenfeld muss immer vollständig berechnet werden, so wie es angegeben wurde.
wenn überhaupt, müsste die diesbezügliche Optimierung schon in Matrix-Berechnung, dh bei C:Z=0 erfolgen.
wobei sich dann wieder die Frage stellen würde, wie mit einem Tabelle1!A:A=Tabelle2!B:B umzugehen wäre, wenn die Usedranges auf beiden Blättern unterschiedlich groß sind.
Gruß Daniel
Anzeige
Warum ich das behauptet habe? Nun, weil ...
26.10.2016 01:11:32
Luc:-?
…ich davon überzeugt war und weil das auch das normale Verhalten einer Fkt, der man Argumente übergibt, wäre, Daniel;
dass das nun von einer fml-externen KontrollInstanz optimiert, d.h. geändert wird, war nicht zu vermuten, zumal das bei UDFs nicht so ist. Aber ich habe auch gesagt, dass das bei BedingtFormatRegeln nicht so sein muss, was man mit meinem „Versuchs­aufbau“ ebenfalls herausfinden kann! Dazu unten mehr… :-]
Luc :-?
Anzeige
Das Beispiel entspricht nicht ganz meinem..
24.10.2016 22:29:38
Daniel
... Versuchsaufbau.
ersetze mal WAHR durch einen Fehlerwert, ich hatte ja den DIV/0-Fehler als 2. Argument.
nur mit einem Fehler erkennst du, ob in der Wenn-Funktion der WAHR-Teil berechnet wurde oder nicht, denn Excelfunktionen verwenden in der Regel einen Fehler als Formelergebnis (ausnahme Aggregat mit der entsprechenden Einstellung und die ISTxxx-Funktionen.
ansonsten:
wenn das hier gilt:"in einer ZellFml kann man als Argumente auch ganze ZellBereiche bzw Datenfelder angeben, in einer Regel nicht."
dann dürfte eine Regel wie =Summe(A1:A10)=100 nicht funktionieren.
aber du relativierst diese Aussage ja gleich hiermit
"In beiden Fällen sorgt aber die allgemeine Xl- bzw spezielle BedingtFormat*-Steuerung dafür, dass im Endeffekt auch diese verarbeitet wdn können."
Wie soll ich das jetzt verstehen, erst sagst du, es geht nicht (also Datenfelder als Argument in der Regel) und hinterher sagst du es geht doch, also zwei sich wiedersprechende Aussagen.
falls du Datenfelder gemeint haben solltest, wie sie in Matrixformeln verarbeitet werden, so kannst du sowas auch in Regeln verwenden, das funktioniert in Regeln wie in Zellen sehr änhlich.
In Regeln sogar besser, weil in der Regel eine Matrixformel automatisch erkannt wird, während in einer Zelle hierzu die Eingabe mit STRG+SHIFT+ENTER erforderlich ist.
gruß Daniel
Anzeige
Dazu später mehr! owT
25.10.2016 04:14:08
Luc:-?
:-?
Das mit den Fehlerwerten stimmt so global ...
26.10.2016 02:42:29
Luc:-?
…nicht, Daniel,
und ist deshalb kein zuverlässiges Kriterium, denn von WENN wird ja auf jeden Fall eine Auswahl getroffen! Dass das bei IIf anders ist, läge allein an seiner Pgmmie­rung (bzw der VBA-Syntax), falls man das nicht mit On Error Resume Next umgehen kann. Mit einer UDF könnte man das!
Fehlerwerte (bzw der 1. auftretende) wdn nur von den Xl-Fktt weiter­gereicht, die mit den ihnen über­gebenen Daten rechnen, wenn das nicht fkts­intern abge­fangen wird. Hier mal ein kleines Bsp:
Ergebnisse A10:C12: {#NV.#NV.1;"xxx"."xxx".#NV;#WERT!.99.1}
ZFml A10[:A12]:=WAHL(ZEILE(A1);#NV;"xxx")
ZFml B10:B11: {=WAHL(ZEILE(A1:A2);#NV;"xxx")}
ZFml B12:=SUMME(ChooseIf({#NV;99};ISTZAHL({#NV;99});WAHR))
ZFml C10:=ANZAHL({#NV;99})
ZFml C11:=SUMME({#NV;99})
ZFml C12:=SUMME(NoErrRange(A10:C10))
Die beiden UDFs zeigen, dass man F-Werte durchaus abfangen kann, ChooseIf generell (auch in DFeldern), NoErrRange nur in ZBereichen.
Im nächsten Pkt kritisierst du meine Aussage zu Bereichs­Angaben in BedFormat-Regel­Fmln. Die beruht aber auf einer von Xl gene­rierten Fehler­Meldung (syste­ma­tische Dar­stellung dessen, was die Meldung aussagt, in der BspTab) und ist sicher etwas anders zu verstehen als du und ich u.A. es im 1.Moment verstehen würden. Die SummenFkt in deinem Bsp liefert ja einen einzigen Wert und scheidet somit aus. Aber auch manche Fml(/Fkt), die als Zell­Fml uU ein DFeld liefern würde, scheidet hier ebenso wie eine Bereichs­Angabe außer­halb einer Fkt aus. Die spezielle Bedingt­Format-Regel-Steue­rung scheint der­artige non­kon­forme Angaben zu igno­rieren, im Zusammen­hang mit INDEX kann es hier aber zu Fehl­Inter­preta­tionen kommen, auch, wenn die Regel an sich akzep­tiert wird.
Meine „Relativierung“ der oben gemeinten Aussage beruht einzig und allein auf dem ab Xl12/2007 üblichen internen variieren relativer Zell­Bezüge anhand des Geltungs­bereichs und der Position der regel­tra­genden Zelle im Vgl mit dem Links­Oben dieser Zellen.
Datenfelder als Ergebnis von Ausdrücken ist klar, aber MatrixKonstanten sind tabu! Im Übrigen ist es so, dass jede Fml im Prinzip in Gänze berechnet wird bzw würde, nur muss man im Tab­Blatt der Xl-Steuerung mit­teilen, was man wirk­lich haben will (das Andere wird dann weg-„optimiert“). Mitunter reicht hier die Matrix­Fml­Form nicht mal und es müssen außerdem wenigstens 2 Zellen aus­ge­wählt worden sein.
Im Folgenden komme ich auf den ursprünglichen StreitPkt WENN in BedFmt-RegelFmln zurück. Ich habe das mal mit meinem Arrangement getestet und dabei das Ergebnis erhalten, um das ich meine BspTab (nun schon zum 2.Mal) erweitert habe:
 ABCDEFGHIJKL
1
Argument1Argument2   UND 2     WENN 1+1     WENN 2   WAHL 2+1specIf 1+1specIf 1+f⁺¹WENN 1+f⁺¹Regel als ZFmlBedingtFormatVerbot f.BedingtFormatRegelnFALSCHFALSCHFALSCHFALSCHFALSCHFALSCHFALSCHFALSCHFALSCHFALSCH1Verweisoperatoren:WAHRFALSCHFALSCH0FALSCH002 Wahr1 WahrFALSCH4; Vereinigung (Zn59)FALSCHWAHRFALSCHFALSCHFALSCHWAHRFALSCH00FALSCH3  Schnittmenge (Zn32)WAHRWAHRWAHR0WAHR004 Wahr2 WahrFALSCH2: Bereich (Zn58)C2[:C5]:=UND(A2;B2)F2[:F5]:=WAHL(A2+1;B2;)H2[:H3]:=specIf(A2;TestVal(A2))I2[:I3]:=WENN(A2;TestVal(A2))WAHR5Matrixkonstanten:D2[:D5]:=WENN(A2;)G2[:G5]:=specIf(A2;)H4[:H5]:=specIf(A4;TestVal(A4);)I4[:I5]:=WENN(A4;TestVal(A4);) {.;.} Spalten u.Zeilen (je2)E2[:E5]:=WENN(A2;B2)J2[:J6]:=WENN(K2=KKLEINSTE($K$2:$K$6;ZEILE(K2)-1);--LINKS(TestVal(K2))=3)BedingtFormatRegel in K2:K6: =IF(K2=SMALL($K$2:$K$6,ROW(K2)-1),--LEFT(TestVal(K2))=3)
2
3
4
5
6
7
8

Wie erklärst du dir die Abweichung der Spalten J und K voneinander? Kommt die nicht doch dadurch zustande, dass die spezielle Bedingt­Format-Steuerung anders reagiert als die allgemeine Xl-Steuerung?
Ich habe mit einer meiner UDFs den RegelFml-Text im Original ausgelesen, damit du das ggf auch mit einer Evalu­ierungs-UDF über­prüfen kannst. Dabei müssen natürlich die Adressen angepasst wdn, die sich auf die jeweilige Regel-Standort­Zelle beziehen. Allerdings kann deren Ergebnis in einer ZellFml ggf unter­schiedlich inter­pretiert wdn, was damit zusammen­hängen könnte, dass die Xl-Steuerung zwar bei Zell­Fmln idR ein­greift, aber durch die Evalu­ierung die Optimierung aus­ge­schaltet wird.
Man sieht also, es ist doch nicht alles so klar und eindeutig, weder in der einen noch der anderen Hinsicht… ;-]
Gruß, Luc :-?
Anzeige
AW: Das mit den Fehlerwerten stimmt so global ...
26.10.2016 08:40:53
Daniel
Hi Luc
die Abweichung in den Spalten K und J lässt sich dadurch erklären, dass das Ergebnis von Links(TestVal(...)) durch die Statische Variable aktZr bestimmt wird, welche aber nicht von Zellwerten abängt, sondern einfach nur zählt, wie oft die Funtkion bereits ausgeführt wurde. dh der Wert von K2 hat keinen Einfluss auf das Ergebnis, sondern nur die Anzahl, wie oft die Funktion bereits berechnet wurde. Somit ist eigentlich logisch, dass trotz gleicher Parameter unterschiedliche Ergebnisse herauskommen.
Das kannst du auch einfach überprüfen, in dem du mal in die Formel in der Zeile 4 gehst, das Links(TestVal(K4)) markierst und F9 drückst.
Wenn du dies mehrfach wiederholst, wirst du feststellen, dass sich das Ergebnis immer ändert und somit von K4 unabängi ist.
das was du da konstruiert hast, lässt keine sinnvolle Aussage zu ist einfach nur Unsinn.
deswegen hier nochmal meine Beobachtung, welche auch deutlich einfacher nachzustellen ist und nur mit originären Excelformeln arbeitet:
ich habe für die Zelle A1 eine Bedingte Formatierung mit folgender Regel erstellt:
=Wenn(A1=1;Summenprodukt(1*(C:M=0)))
schreibe ich in die Zelle A1 eine 1, erfolgt die Umfärbung erst nach einer kurzen Wartezeit, schreibe ich in die Zelle A1 einen anderen Wert, erfolgt die Umfärbung sofort.
Das kann eigentlich nur daran liegen, dass der WAHR-Teil der Wenn-Funktion (das zeitaufwendige Summenprodukt) nur dann berechnet wird, wenn die Prüfung ein WAHR ergeben hat, aber nicht wenn die Prüfung FALSCH ergibt.
Anzeige
Was du hier antwortest stimmt nur für ZFmln, ...
26.10.2016 12:35:55
Luc:-?
…nicht aber in BedingtFormatRegeln, Daniel;
dein Versuch mit [F9] ist genausowenig aussagekräftig wie meine Bemühung des FmlAssi, denn beides liefert nur einzelne Moment­Aufnahmen ohne Eingreifen der Xl-Steuerung! Wie willst du denn anders als ich erklären, dass ein ganzer Ausdruck als 2.Argument einer Fkt wie WENN nicht berechnet wird, wenn ihr 1.Argument das 3. als Ergebnis­Ausgabe prädestiniert?!
Die Ergebnisse der BedingtFormatierung habe ich mehrfach überprüft. Bei einem Vgl nicht mit 3, sondern mit 1 wdn der 1. und der letzte Wert markiert (der letzte, weil 5 in der UDF zu 1 wird). Die Werte 2 und 4 kommen gar nicht vor. Folglich wird die UDF jedesmal aufgerufen und zählt deshalb bis 4 durch bevor sie wieder mit 1 beginnt. Ist das nicht offensichtlich?!
Dass Ergebnisse hier schwanken können, hat xl-bedingte Ursachen, die auch auf die der ZellFmln zutreffen. Bei regulärem Ablauf ergibt sich aber das gezeigte Ergebnis. Und eine Einzel­Auswertung der abgebildeten, aber jeweils angepassten Regel per vbFkt Evaluate zeigt auch WAHR in genau gleicher Position. Damit ist deine anfängliche, auf WENN in Bedingt­Format­Regeln bezogene Annahme (oder besser Vermutung) wohl eindeutig widerlegt und damit das, was du über mein Experiment behauptest, einfach selbst nur Unsinn.
Xl-Fmln arbeiten nicht mit irgendwelchen Zaubertricks, die man irgendwie zK nehmen und akzeptieren muss, sondern auf der Grundlage von Pgmm, deren Wirkungsweise man zu erklären versuchen sollte. Sobald man es selbst geschafft hat, ein solches Verhalten pgm-technisch nachzu­vollziehen bzw eine sinnvolle Vorstellung von diesbzgl Abläufen entwickeln kann, hat man auch eine mögliche Erklärung für derartiges Verhalten, die keine reine Spekulation mehr ist, sondern zumindest eine Hypothese, wenn nicht gar Theorie. Eine Hypothese kann veri- oder falsi­fiziert wdn. Trifft Ersteres zu, wird sie zur Theorie, solange es keine besser passende Hypo­these gibt. Da wir ja niemals Einblick in den Quell­Code erhalten wdn, bleiben uns nur die üblichen wissen­schaft­lichen Unter­suchungs­methoden. Folglich müsstest du jetzt mit einer plausib­leren Hypothese aufwarten; Unsinn ist keine, so ist das nunmal…
Luc :-?
Anzeige
AW: meine Beobachtung über das Verhalten von Wenn
26.10.2016 14:25:21
Wenn
nun Luc, meine Beobachtung und die daraus folgene Hypothese habe ich dir doch genant:
1. die Berechnung der Funktion Summenprodukt(1*(C:M=0)) in einer normalen Zelle dauert auf meinem Rechner c.a. 2 Sekunden
2. wenn ich diese Bedingte Formatierung für die Zelle A1 anlege: =Wenn(A1=1;Summenprodukt(1*(C:M=0)))
dann erfolgt das Umfärben der Zelle:
- bei Eingabe von 1 mit einer Verzögerung von 2 Sekunden (also genau die Zeit, die das Summenprodukt benötigt)
- bei Eingabe eines anderen Wertes sofort, ohne Verzögerung.
Ebenso , wenn ich die restliche Tabelle bearbeiten will:
- steht in der Zelle A1 eine 1, wird jede Änderung in eine Zelle nur mit der beschriebenen Verzögerung übernommen
steht in der Zelle A1 ein anderere Wert, dann wird jede Änderung ohne Wartezeit sofort übernommen.
das sind einfach Beobachtungen, die ich gemacht habe.
und die einzige logische Erklärung für dieses Verhalten ist, dass der Wahrteil der Wenn-Funktion eben nur dann berechnet wird, wenn die Prüfung ein WAHR ergibt und der Falschteil nur dann, wenn die Prüfung ein FALSCH ergibt.
würden jedes mal beide Formelteile berechnet werden, müsste die Wartezeit nach einer Eingabe immer auftreten, unabhängig davon, ob die Bedingung erfüllt ist oder nicht.
Da die Wartezeit aber nur dann auftritt, wenn die Bedinung erfüllt ist, kann die Schlussfolgerung nur sein, dass das Summenprodukt nicht berechnet wird, wenn die Bedinung nicht erfüllt ist.
btw halte ich deinen Versuch mit Static nicht geeignet, um zu überprüfen wann was berechnet wird.
Dazu müsste man die Reihenfolge kennen, in welcher die Berechnungen durchgeführt werden.
desweitern ist mir aufgefallen, dass Berechnung der Formel der bedingten Formatierung nicht nur 1x erfolg, sondern ggf auch mehrfach hintereinander, weshalb es auch nicht zuverlässig ist, diesen Zähler so auszuwerten.
wenn du immer noch nicht überzeugt bist, dann teste mal diese Datei.
für die Zelle A1 gibt es eine Bedingte Formatierung mit jeweils einer UDF im Wahr und im Falsch-Teil
diese UDFs zeigen im Direktfenster an, wenn sie ausgeführt werden (incl Uhrzeit)
dh öffne mal parallel zum Excel- das VBA-Fenster mit dem Direktfenster.
gib dann mal in der Zelle A1 1 (Bedingung erfüllt) oder was anderes ein (Bedingung nicht erfüllt)
im Direktfenster kannst du dann sehen, welche Formelteile berechnet werden und welche nicht.
https://www.herber.de/bbs/user/109029.xlsm
die Beobachtungen, die ich dort machen konnte, passen zu den Beobachtungen mit der Wenn-Funktion mit Summenprodukt
Gruß Daniel
Anzeige
Es ist schon eine Crux mit TestDateien, ...
27.10.2016 00:39:23
Luc:-?
…Daniel,
bis man so alle FehlerQuellen ausgeschlossen hat…
Zum 1.Teil deiner Replik kann ich nichts sagen, nur soviel, dass du anscheinend nur eine Zelle mit Bedingt­Formatierung zum Testen benutzt hast, worauf ich im 2.Teil zurückkommen werde. Falls du diese Bedingung auf 2 unter­einander liegende Zellen ausdehnen würdest, könnte es durchaus sein, dass für beide auch kaum mehr Zeit beansprucht würde. Das Gleiche könnte für die Ergänzung des Sonst-Arguments mit gleicher Rechnung gelten, was ich aber zugunsten des Nach­fol­genden nicht getestet habe.
Ansonsten hast du insofern recht, dass die Berechnungs­Reihen­folge, die von links nach rechts und oben nach unten erfolgen sollte, inzwischen (seit Xl10/2002?) nun wohl anders (optimaler) ist, was man an einer entsprd aufgebauten Debug.Print-Ausgabe sehen kann. Folglich ist ein Static-Zähler in einer in einer ZellFml benutzten UDF tat­sächlich nicht sonder­lich zuver­lässig.
Zum 2.Teil: Um derartige FehlerQuellen auszuschließen, habe ich die TestVal-UDF nun ver­drei­facht und entsprd durch­nummeriert. Die in der BedFormat-Regel eingesetzte UDF habe ich erweitert, um eine eindeutige Debug.Print-Ausgabe zu erhalten. Dabei hat sich nach einigen Mühen heraus­ge­stellt, dass auch die Aus­wertung der Regel-Fml per Zell­Fml kein anderes Ergeb­nis bringt als die direkte Ver­wendung der Regel-Fml als ZellFml → die Dann-Argument-Berechnung entfällt ggf, wie nun eigent­lich auch zu erwarten war.
Nicht so bei der Regel selbst! Hier wird in jedem Fall alles berechnet, wie ich nun eindeutig belegen kann: 
Function TestVal(Bezug As Boolean)
Const StartZeile As Long = 2
Static aktZr As Long
Dim aktZl As Long, aktSp As Long
With Application.ThisCell
If .Column  11 And .Column  16 Then Exit Function _
Else aktZl = .Row: aktSp = .Column + 64
End With
If aktZl = StartZeile Or aktZr >= 5 Then _
aktZr = 1 Else aktZr = aktZr + 1
TestVal = CStr(aktZr) & " " & CStr(Bezug)
Debug.Print Chr(aktSp); aktZl, TestVal
End Function
In Spalte 16 (P) steht bei mir die AuswertungsFml für den Regel-Original­Text, die sich aber nicht rührt ([F9]-Problematik), wenn nur direkt die Regel neu berechnet wird. Letzteres liefert dann folgd Text im Direkt­Fenster:
K 2 ......... 1 Wahr
K 2 ......... 1 Wahr
K 3 ......... 2 Wahr
K 4 ......... 3 Wahr
K 5 ......... 4 Wahr
K 6 ......... 5 Wahr
Die Wiederholung der 1.Zeile dürfte auf die UDF zurückzuführen sein. Ich hatte schon früher, beim Testen von UDFs in Zell­Fmln, bemerkt, dass eine UDF am Anfang 2× (das 1.Mal oft leer, was hier den Zähler aber nicht am Erhöhen hindern würde) durch­laufen wird, was auch in deiner Test­Datei der Fall ist. Bei dir zählt der Zähler dann weiter, bei mir bleibt er auf 1, weil das die StartZeile ist. Weitere Durch­läufe der TestVal-UDF erfolgen dann jeweils nur 1× (mit Spalte P getestet!).
Damit sollte nun doch endgültig klar sein, dass die Steuerung der Bedingt­Formatierung WENN & Co anders behandelt als die Tab­Blatt-Steuerung! Es steht sogar zu ver­muten, dass das auch bei benannten Fmln so sein könnte und der Opti­mierungs-Super­visor nur Zell­Fmln „betreut“. Aber das habe ich jetzt nicht auch noch getestet!
Dein WENN-SUMMENPRODUKT-Test wäre damit allerdings noch nicht hinreichend erklärt, aber das kannst du ja mal weiter­gehend testen und dich dann wieder melden. Viell ist alles ja noch viel kom­pli­zierter — oft genug ist Xl ja inzwi­schen auf- und umge­rüstet worden…
Übrigens, die LaufZeiten deines TestAufbaus waren recht unterschiedlich (von 0,17 bis ≥0,68), so dass anzu­nehmen ist, dass hier auch noch andere (externe) Einflüsse (CPU- u/o RAM-Auslastung → Warte­Zeiten!) eine Rolle spielen könnten.
Gruß, Luc :-?
Anzeige
AW: Es ist schon eine Crux mit TestDateien, ...
27.10.2016 09:19:47
Daniel
Hi
die Laufzeitunterschiede kommen daher, dass Excel die Regel zur bedingten Formatierung je nach geändeter Zelle (Zelle für die die Regel gilt, Zelle die von der Regel referenziert wird) unterschiedlich oft berechnet wird, bis zu vier mal. Das kannst du mit der Datei, die ich dir zur verfügung gestellt habe auch überprüfen.
Dabei wird aber immer nur derjenige 2/3 Teil der Wenn-Funktion berechnet, welcher durch den ersten Teil (die Bedingungsprüfung) ermittelt wird.
Gruß Daniel
Anzeige
Nun gut, machen wir die Laufzeitunterschiede ...
27.10.2016 15:20:36
Luc:-?
…mal nur daran fest, Daniel,
dann könnte ein 1maliger Durchlauf 1er UDF 0,17 betragen, 4×, also je 2× 2 UDFs 4×0,17=0,68. Damit wäre dann auch hier bewiesen, dass idR beide UDFs durchlaufen wdn!
Dass eine UDF ggf 2× durchlaufen wird (daran liegt's, nicht an Bedingt­Format-Regeln an sich!), hatte ich bereits geschrieben. Da du dich auf eine Regel für den Geltungsbereich nur einer Zelle beschränkt hast, ist das bei Neustart so und nur bei unmittelbar anschließender Wiederholung wird's weniger. Damit ist dein Test ungeeignet, deine oder meine Hypothese zu veri- oder zu falsifizieren, während meiner nun eindeutige Ergebnisse liefert, zu denen du dich nicht geäußert hast…
Luc :-?
Anzeige
AW: Nun gut, machen wir die Laufzeitunterschiede ...
27.10.2016 22:46:59
Daniel
Hi Luc
sorry, aber du verstehtst anscheinden überhaupt nichts von dem was ich sagen will und redest irgendwas, was dir gerade einfällt.
für die Ermittlung der Laufzeit habe ich keine UDF (Userdefinied Function - Benutzerdefinierte Funktion) eingesetzt, sondern nur Excelstandardfunktionen, nämlich Summenprodukt; "=" und "*", also keine einzige Zeile Makrocode, wie er für eine UDF erforderlich wäre.
es können auch gar nicht beide UDFs (was immer du damit meinst) durchlaufen werden, weil nur der WAHR-Teil überhaupt so etwas wie eine Funktion oder Formel enthält.
Den Falsch-Teil habe ich ganz weg gelassen, dh hier wird gar nichts berechnet, sondern einfach nur der Wert FALSCH als Ergebnis eingesetzt.
es gibt also nur eine Formel, die durchlaufen werden kann, nämlich die des Wahrteils.
Es ist auch so, dass die Regel der Bedingten Formatierung mehrfach durchlaufen wird (und damit auch die in ihr vorhandenen Formelteile)
Aber es ist immer so, dass wenn in der WENN-Funktion die Prüfungsteil ein FALSCH ergibt , der Wahrteil nicht berechnet wird, und wenn der Prüfungteil WAHR ergbit, wird der FalschTeil nicht berechnet.
Deine Prüfungsmethode halte ich immer noch nicht für geeignet.
Ich habs mir auch nicht genauer angeschaut, weil ich denke dass ich wahrscheinlich zu viele Fehler im Aufbau mache, wenn ich versuche die Datei zum Testen selbst zu erstellen und werde das erst tun, wenn du eine entsprechende Beispieldatei hochlädst.
Vielleicht hier nochmal der "final-Proof" für meine Theorie.
ich habe jeweils eine UDF erstellt für den Prüfungsteil der Wenn-Funktion, eine für den Wahr-Teil und eine für den Falsch-Teil.
Wenn diese Funktionen bearbeitet werden, schreiben sie einen entsprechenden Text in eine globale Variable (Protokoll), so dass du, nachdem du die berechnung der bedingten Formatierung ausgelöst hast, in diesem Protokollstring nachlesen kannst, welche Funktionen in welcher Reichenfolge ausgelöst wurden.
https://www.herber.de/bbs/user/109067.xlsm
Gruß Daniel
Anzeige
Ich glaube langsam, ich spinne (oder besser ...
28.10.2016 05:05:54
Luc:-?
…du spinnst), Daniel;
woher willst du wissen, dass ich deine Argumente nicht verstehe — viell verstehst du ja meine nicht! Ich schreibe nicht, was mir „gerade einfällt“, sondern beziehe mich auf deine BspDatei; du auch…?!
Zitat: für die Ermittlung der Laufzeit habe ich keine UDF … eingesetzt, sondern nur Excelstandardfunktionen, nämlich Summenprodukt; "=" und "*", also keine einzige Zeile Makrocode, wie er für eine UDF erforderlich wäre.
Ach nee, und was sind dann deine Fktt xwahr und xfalsch gewesen, eine Fata Morgana? :->
Die allein verursachen höchstwahrscheinlich die zusätzlichen Durchläufe der Bedingt­Formatierungs­Regel, denn das ist in ZellFmln auch so (möglicherweise zu ihrer „Initiierung“ o.ä.)!
Und ein SUMMENPRODUKT kommt dort auch nicht vor! Wer sagt dir denn, dass dein diesbzgl Dummy nicht ohnehin nur 1× durch­laufen wird (immer bei Neu­Initi­ierung der BedFmt­Regel) und sein Ergebnis dann gemerkt wird? Das könnte ein Feature der Bedingt­Format­Steuerung sein, weil die allgemeine Xl-Steuerung hier nicht ange­wendet wdn kann. Bedenke, dass die Bedingt­Formatierung frühestens mit Xl5 bzw Xl95 hinzugefügt wurde, sonst gäbe es dafür sicher auch eine XLM-Fkt! Mit Xl12/2007 wurde sie zwar kom­plett neu ge­staltet, aber ich bezweifle, dass MS soweit gegangen ist, sie mit der allgemeinen Xl-Steuerung eines Tab­Blattes zu verbinden. Sicher war es ein­facher, Ersatz­Konstruk­tionen dafür in eine separate Steuerung einzu­bauen. Folglich beweist auch dein „final proof“ nicht das, was du unbedingt beweisen willst!
Zitat: es können auch gar nicht beide UDFs (was immer du damit meinst) durchlaufen werden, weil nur der WAHR-Teil überhaupt so etwas wie eine Funktion oder Formel enthält.
So, so, was ist dann jetzt das (in der neuen BspDatei): =WENN(prüfung($A$1);wahrteil();falschteil())
In der alten BspDatei bestanden sowohl Arg2 als auch Arg3 ebenfalls aus UDFs mit Dummy-Bereichs­Über­gabe, nämlich xwahr und xfalsch.
Dafür habe ich mich aber an deine ursprüngliche und hier wieder behauptete Vorgabe gehalten und Arg3 entfallen lassen. Aber das überzeugt dich ja nicht und eine Test­Datei nach meinen Vor­gaben auf­bauen kannst bzw willst du ja nach eigenem Bekunden nicht. Vielleicht können das dann Andere, die sich bis hierher durch die zunehmend fruchtlose Dis­kussion gequält haben (wdn)…
Zitat: Deine Prüfungsmethode halte ich immer noch nicht für geeignet → und ich deine nicht! Hilft das nun weiter…?
Was ist an einer Prüfung auszusetzen, die …
• mehrere bedingt formatierte Zellen umfasst (im Ggsatz zu deiner - immernoch - nur einen),
• die Adresse der Zelle ausgibt, deren Regel gerade berechnet wurde und …
• dazu dann noch das Ergebnis dieser Berechnung?
Dein immer so ist nur eine Behauptung, die nur für ZellFmln zu stimmen scheint (benannte Fmln gälte es noch darauf­hin zu unter­suchen!) und die du generell nur kon­statieren, nicht aber (auch nur ansatz­weise) erklären konntest.
Aber was du (nicht) kannst, muss ich mir nun ja auch nicht antun, zumal deine neue TestDatei immer noch nicht den Ansprüchen an eine solche genügt. Folglich kann sie gar nichts beweisen.
Es mag ja nun durchaus sein, dass du wissenschaft­liches Arbeiten nicht gewohnt bist, aber gerade dann solltest du mit deinen Aussagen vorsichtig sein und deine Annahmen nicht gleich zur „Theorie“ erklären, denn noch haben sie (bzgl deines immer) das Niveau einer Hypothese nicht über­schritten! :->
Und damit gedenke ich diese Diskussion zu beenden, denn sie wird wohl kaum weitere Erkennt­nisse bringen. Ein Optimum an denselben scheint vorerst erreicht und mehr nicht möglich zu sein. Und fürs Streiten um des Streitens willen ist mir meine Zeit eigentlich zu schade…
Luc :-?
Anzeige
AW: Ich glaube langsam, ich spinne (oder besser ...
28.10.2016 16:00:13
Daniel
Hi Luc
sorry, ich habe mich vielleicht nicht ganz klar ausgedrückt:
beachte bitte, dass ich zwei unterschiedliche Methoden verwende, um meine Theorie zu belegen.
das eine ist die Laufzeitbestimmung mit dem Summenprodukt im WAHR-Teil des WENN.
Hierbei habe ich Summenprodukt gewählt, weil ich über das Summenprodukt mit einer einzigen Funktion eine Laufzeit generieren kann, die auch ohne Stoppuhr durch direktes Erleben mit genügender Genauigkeit messbar ist.
Im FALSCH-Teil des WENN steht dann die kürztestmögliche Funktion (nämlich keine)
Wenn man jetzt bei erfüllter Bedinung eine signifikant längere Berechnungszeit feststellt als bei nicht erfüllter Bedinung, bedeutet dass, dass nur eine der beiden Teile berechnet wird.
Nur wenn sowohl bei erfüllter wie auch nicht erfüllter Bedingung die Berechnungszeiten gleich sind, würde dies auf eine Berechnung beider Teile hinweisen.
die zweite Methode ist einfach nur eine Protokollfunktion, welche im Direktfenster mitschreibt, welcher Formelteil gerade ausgeführt wird.
Dazu wird die Uhrzeit der Ausführung mitgeschrieben, damit man feststellen kann, wie die Protokollschritte zusammengehören. Diese Methode beinhaltet keine Laufzeitmessung.
Dazu sind die verwendeten Funktionen viel zu kurz und erzeugen keine genügend langen Laufzeiten, die mit den Excelmethoden genügend genau ausgewertet werden könnten.
Desweitern müsste ja eine Laufzeitmessung den Zeitpunkt des Beginns der Berechnung der Gesamtformel und den Zeitpunkt des Endes der Berechnung feststellen, und das ist mit Funktionen, die selbst Bestandteil der Gesamtformel sind, gar nicht möglich.
Dh die zweite Methode mit xWahr und xFalsch beinhaltet keine Zeitmessung, sondern nur ein Protokoll der Reihenfolge der Berechnungsschritte.
diese beiden Methoden dürfen auch nicht miteindander vermischt werden und müssen auch getrennt von einander druchgeführt werden.
Desweitern halte ich es für richtig, meine Untersuchung mit nur einer einzigen WENN-Funktion in der Datei durchzuführen.
Damit vermeide ich unterwünschte Nebeneffekte und ich muss auch keine Vorkehrungen treffen um abzusischern, welche der mehreren WENNS- jetzt die jeweilige UDF ausgelöst hat.
Das Risiko, hier einen Fehler zu machen und so die Beobachtung zu verfälschen, ist mir zu gross.
Bei nur einer WENN-Funktion habe ich das Problem nicht.
und wie gesagt, lade bitte deine Datei mit den Prüfungsmakros hoch, so wie ich es getan habe, dann kann ich mir deine Prüfungsmethode genauer anschauen und dir meine Meinung dazu sagen.
Gruß Daniel
Anzeige
Darauf komme ich ggf in einem separaten ...
29.10.2016 20:04:43
Luc:-?
…Thread zurück, Daniel,
weil es evtl noch mehr Leute interessieren könnte. Hier jetzt nur noch soviel:
• Ich habe jetzt mit meiner Methode auch noch das Verhalten von WENN in benannten Fmln untersucht. Das sieht dann so aus, dass einer­seits diese Fmln generell berech­net wdn, wobei WENN wie eine normale Fkt reagiert, also stets alle Argumente berechnet wdn, und anderer­seits der Eintrag des Namens als Zell­Fml bewirkt, dass noch­mals, aber nun unter „Aufsicht“ der Xl-Tab­Blatt-Steuerung, berechnet wird, die den von dir (nur) hierfür (!) nach­gewie­senen Effekt verur­sacht.
• ZellFmln wdn offensichtlich in einer speziellen, ggf heuri­stischen Reihen­folge berechnet, benannte Fmln wahrscheinlich nicht, ordnen sich aber durch das bzw mit dem Auf­treten ihres Namens in Zell­Fmln in diese Reihen­folge ein. In ihrer Primär­Berechnung zeigen sie in meinem speziellen Wieder­gabe­Ergebnis aber nicht die jeweilige Zell­Adresse, sondern stets A1 und dann auch alle möglichen Werte des Dann-Teils der Fml an. In den an der jeweiligen Zell­Adresse erkenn­baren Sekundär­Berech­nungen treten diese Werte aber nur auf, wenn der Wenn-Teil der benannten Fml WAHR ergibt.
• Dagegen ist die Berechnung der BedingtFormat-Regel stets regulär und alle Ergebnisse von Debug.Print wdn hinter­einander aus­ge­geben und zwar mit allen möglichen Ergeb­nissen des Dann-Teils. Ein Beweis dafür, dass Regel­Fmln nicht der Über­wachung durch die Tab­Blatt-Steuerung unter­liegen, die allein das beob­achtete Ver­halten von WENN in Zell­Fmln ver­ursacht!
• Weil du das ja partout nicht als Beweis meiner Hypothese anerkennen willst, bin ich noch einen Schritt weiter gegangen und habe eine UDF geschrie­ben, die das Ver­halten von WENN in Zell­Fmln simuliert und die dann (sicher­heits­halber) über eine benannte Fml in einer Regel einge­setzt. Und siehe da, das Bedingt­Format hat nun so reagiert, wie du es bereits für WENN erwarten würdest. Folgendes war das Debug.Print-Ergebnis …
 — für WENN:
K2: 1 Wahr
K3: 2 Wahr
K4: 3 Wahr
K5: 4 Wahr
K6: 5 Wahr
 — für simWENN (Name der benannten Fml mit UDF simIf):
K10: 1 Wahr
K12: 2 Wahr
K14: 3 Wahr
Der Bereich K10:K14 zeigt die gleichen Werte wie K2:K6 (in meinem Bsp). Das BedingtFormat färbt oben K4 und unten K14 um, also oben den 3. und unten den 5.Wert.
Das sollte doch nun Beweis genug für meine Hypothese sein…! :-]
Gruß, Luc :-?
Anzeige
AW:Beispieldatei
29.10.2016 21:50:37
Daniel
wie gesagt, ich werde deine Hypothese überprüfen und danach als Beweis anerkennen, wenn du eine entsprechende Datei mit den Codes und den Formeln zur Verfügung stellst.
Gruß Daniel
Für Nach- bzw Mitleser
31.10.2016 22:52:39
Luc:-?
Es geht unter HalloWenn-Grusel weiter.
Luc :-?
Anzeige
AW: Für Nach- bzw Mitleser
31.10.2016 23:38:28
Daniel
dann hoffentlich und endlich auch mit aussagekräftigen Beispieldateinen anstelle von wichtigtuerischem Gerede (wie z.b. der inflationäre Gebrauch von Abkürzungen)
Gruß Daniel
;

Beliebteste Forumthreads (12 Monate)

Jetzt das Excel-Portal bewerten: Deine Stimme zählt!
Anzeige
Anzeige
Anzeige