WOGO

Es gibt dazu auch einen guten Artikel auf MQL4.com. Den hab ich gestern sogar schon angefangen zu lesen, dann aber wieder abgebrochen bevor ich an die Stelle kam, wo das Problem beschrieben wird.

Da hilft nur eins, DURCHMACHEN

Oh ja! Die haut in den 2 Stunden mehr Hammer-Zitate raus, wie bei unseren Famous Quotes innerhalb einer Woche durchlaufen.

Hi Rainworm, hab in der Hektik dein Post total übersehen . Ja, genau das war's. Bei deinem Beispiel funktioniert es SUPER! Rainworm, Finger, ich seid echt spitze! Vielen Dank Nein, das kann ich auch umgehen.

So, bin jetzt doch noch ein Stück weiter gekommen. Ich hab mal einwenig rumgespielt, ab wieviel Digits die Abfrage klappt/nicht klappt. Bei EURJPY ist ein Punkt ja 0.01 (4-Digit-Broker) also hab ich mit den Nachkommastellen gespielt. if(Open>=Close[i+1]+0.009999999999999) funktioniert noch, d.h. der Pfeil wird bei einem Punkt Abstand Open/Close gezeichnet if(Open>=Close[i+1]+0.0099999999999999) geht nicht Dann hab ich Open Close nochmal genauer untersucht. Es gibt in der stdlib die Funktion DoubleToStrMorePrecision(), die mehr Nachkommastellen als DoubleToStr ausgibt. Label="Text_"+Time[i]+"b"; PutTextLabel(Label,-1.3, Time[i], DoubleToStrMorePrecision(Close[i+1],15), 6, "Arial", DarkGreen); Label="Text_"+Time[i]+"c"; PutTextLabel(Label,-1.6, Time[i], DoubleToStrMorePrecision(Open[i],15), 6, "Arial", DarkGreen); Das gibt mir dann für Close[i+1] (oben) und Open (unten) folgendes aus: Also Zahlen, die bei der 15. Nachkommastelle schwanken. Bei EURUSD bekomm ich an der 18. Nachkommastelle sowas: 1.3625000000000001 Damit schein die Abfrage aber noch zu funktionieren. Ok, komischer Effekt ... was dann aber noch dazu kommt: Wenn ich NormalizeDouble() mache, funktioniert die Abfrage für EURJPY trotzdem nicht. Ächtz

Der eigentliche Code soll mal inetwa so aussehen: if(Open[i]>=Close[i+1]+Param*Point) ... D.h. bei einer bestimmten Gap-Größe soll ein Signal gegeben werden. Die Größe in Punkten wird über den Parameter eingestellt.

Danke, ja! Das funktioniert schon. Der Code, den ich hier gepostet habe ist aber sozusagen nur der Kern des Problems. Real ist die if-Abfrage etwas komplexer, funktioniert per BarShift über einen anderen Zeitrahmen und die Differenz zwischen Open und Close ist auch nicht nur 1 Punkt, sondern flexibel. Der reine Vergleich Open>Close[i+1] ist somit leider nicht umsetztbar. Mir ist halt total schleierhaft, warum diese Abfrage if(Open>=Close[i+1]+ Point) die ja eigentlich sowas von trivial ist, nicht funktioniert.

Leider nicht!

Danke! Hab ich auch schon versucht. Geht genau sowenig, UFF!

Ja, ich hab das Point, das ja den Wert von 0.01 haben sollte mal durch 0.01 ersetzt. Das funktioniert genau so wenig. Irgendwo kann da was mit der Rundung nicht funktionieren. Wenn ich mach if(Open[i]-0.999999999*Point >= Close[i+1]) dann geht's. Aber warum nicht bei 1*Point???

Bitte diesen Mist wieder vergessen! Die Nachkommastellen kamen nur durch das Überlappen der Textlabels zustande. Hab wohl noch nicht richtig aus den Augen rausgesehen... Bei meinem Problem bin ich somit immer noch nicht weiter gekommen

Was ist das denn? Wenn ich mir über Textlabels Point, Open und Close[i+i] ausgeben lasse, so bekomme ich an Bars, wo folgende Kurse auftraten Open= 111.69 Close[i+1]= 111.68 folgendes Ergebnis: Point= 0.01 Open= 111.6900000037 Close[i+i]=111.6800000065 Wo kommen denn die Werte an 9. und 10. Stelle hinter dem Komma her??? Die Berechnung stimmt somit, aber die Daten sind mir überhaupt nicht klar.

Ganz schön abenteuerliche These...

Ich trau mich die Frage garnicht stellen, weil die Lösung vermutlich richtig peinlich für mich wird, aber ich komm selber einfach nicht drauf. Folgendes Problem: if(Open[i]-Point>=Close[i+1]) { UpArrow[i]=0; PutTextLabel(-1, Time[i], DoubleToStr(Open[i]-Point,Digits), 6, "Arial", DarkGreen); } else { UpArrow[i]=EMPTY_VALUE; PutTextLabel(-1, Time[i], DoubleToStr(Open[i]-Point,Digits), 6, "Arial", DarkGreen); } Im Klartext: Wenn der aktuelle Eröffnungskurs mindestens einen Punkt über dem vorherigen Schlußkurs liegt, dann setze UpArrow auf 0, ansonsten auf EMPTY_VALUE. Das PutTextLabel ist nur zum Debuggen. Jetzt siehts so aus. Bei EURUSD funktioniert das immer, soweit so gut. Probier ich das aber mit EURJPY (also ein 2-Digit-Wert), dann kommt es immer wieder mal vor, dass das UpArrow leer bleibt, obwohl mein Eröffnungskurs einen Punkt überhalb des Schlusskurses liegt. Dies wird mir auch bei der Debugausgabe angezeigt. Ich hab schon an allen möglichen Stellen "NormalizeDouble" versucht aber kein Erfolg. Mir ist komplett schleierhaft, warum das nicht geht Irgendwer eine Idee?

Damit kann ich was anfangen. Danke! Werd mir die Demo bei Gelegenheit mal anschaun. Was sind denn die Einschränkungen im Vergleich zur Vollversion?

Uneingeschränkt kann ich da nicht zustimmen. Sicher, je mehr Stellschrauben ein System hat, desto leichter kann man durch Rückwärtsoptimierung und teilweise sinnlose Parameter, viele Verlierer-Trades wegfiltern. Wenn aber eine Strategie von Haus aus nichts taugt, dann hilft dir das auch nicht weiter. Aber dein Grundgedanke ist schon richtig. Eine Parameteroptimierung kann, wenn man diese ohne den richtigen Sinn für die Realität macht, ganz schnell nach Hinten losgehen.

Wow, Danke für die schnelle Antwort! Im Buch wurde erwähnt, dass das System nach Fertigstellung zum Verkauf angeboten wird. Es spricht ja nichts dagegen ein profitables System zu verkaufen, es sah für mich halt etwas wie product placement aus. Hm, wenn die Erklärung schon alles ist, was hinter MC-Simulation steckt, dann hab ich vielleicht etwas zu Komplexes dahinter vermutet. D.h. also, die Berechnung des Tools läuft inetwa so, wie in dem gezeigten Excel-Beispiel? Bitte nicht falsch verstehen. Ich finde die Beschreibung der Methode im Buch wirklich gut. Es kommt sehr gut rüber, dass ein einzelner Backtest oft maßlos überschätzt wird und die Erklärung, wie man seine Testabdeckung wesentlich verbessern kann ist wirklich hilfreich. Es wirkt auf mich aber halt - wie soll ich sagen - etwas wenig Stoff für ein ganzes Buch... Schade! Nein, Schmarrn! Hätt ich jetzt auch nicht erwartet. Viele Unklarheiten hast du ja schon geklärt. Was mich halt noch etwas detaillierter interessieren würde, wären die groben Methoden, mit denen du die synthetischen Kursdaten erzeugst. Ich verstehe natürlich auch, wenn du das nicht preisgeben willst. Ist ja schließlich dein know-how. Ich finde es auf alle Fälle super, wie schnell und sachlich du auf meine Kritik reagiert hast. Glaub ich kaufe in Zukunft nur noch Bücher, die TN-Members geschrieben haben. (Also Vola, häng dich rein! ) Also nichts für Ungut! Wogo

Ähm, jetzt hat's doch funktioniert. Vielleicht hätt ich bei der Fehlermeldung mal nach unten scrollen sollen. Da stand dann nähmlich, dass Dezimalzahlen erwartet werden. Meine ursprüngliche Eingabe war XXXX Mit XXXX.0 hat es dann geklappt. War das hier schon irgenwo mal beschrieben, dass man .0 eingeben muß? Ich kann mich irgendwie dunkel an etwas erinnern...

Ich geb dir in allen Punkten recht. Die Methodik stellt auf alle Fälle einen Mehrwert für jeden Systementwickler dar. Sie ist aber auch auf wenigen Seiten zu erklären. Vielleicht hab ich mir das Buch mit der falschen Erwartunghaltung gekauft. Ich dachte mir halt, wo Monte Carlo Analyse draufsteht wird auch erklärt, wie diese funktioniert...

Irgendwie wird IGM immer weniger interessant. Auf das Profi-Chart Modul kann man seit einiger Zeit auch nichtmehr kostenlos zugreifen...

Ich drücke auf deinen Link von Post #3, dann "Prognose einstellen" gebe meinen Tip ein und dann kommt das da:

Systemmitteilung Qualitätssicherung... Darf ich auch mitmachen?

Da ich mich ja auch mit Daten- und Systemsimulation beschäftige und mehr zum Thema Mote-Carlo Simulation erfahren wollte, hab ich mir besagtes Buch von Volker Butzlaff alias Zentrader gekauft. Auch wenn Zentrader hier aktives Mitglied im Forum ist, hier eine kritische Betrachtung des Buchs. Das Buch hat 156 Seiten und kostet 30€. Gepackte Information also - dachte ich. Beim ersten Durchblättern merkte ich dann, dass die Infos sehr kompakt sein müssen, da der Anhang schon auf Seite 133 startet... Der Inhalt glieder sich so, dass zunächst beschrieben wird, was ein mechanisches Handelssystem ist, wie es entwickelt wird und das in der Regel die Systemsimulation zu kurz kommt. Dann wird anhand eines einfachen Systems auf den DAX und eines professionellen Systems - das es praktischerweise auf der Homepage des Autor zu erwerben gibt - gezeigt, wie mit Hilfe von Monte-Carlo-Simulation die Kenngrößen eines Backtests Aufschluß über Qualität und zu erwartende Performance geben können. Dies wird anhand der Zen Monte Carlo Simulator SW gezeigt. Hauptkritikpunkt hier: Zur MC-Analyse wird nur erklärt, wie deren Name zustande kam, aber nicht, wie sie mathematisch abläuft. Im Folgenden wird dann noch gezeigt, wie die oben genannte SW die Eingangskursdaten abändern kann, so dass neue Kursreihen entstehen, die zum weiteren Testen des Systems verwendet werden können. Die Darstellung der Methodik ist ganz nett, aber auch hier wird wieder nicht erklärt, nach welchem mathematischen Prinzip die Daten generiert werden. Dann bekommt man noch gezeigt, wie die beiden analysierten Systeme mit den synthetischen Daten performen und das war's im Großen und Ganzen. Geschmückt ist das Buch noch mit vielen Tabellen und Bildern und hat einen ziemlich großen Zeilenabstand, so dass ich zum Lesen keine 2h benötigt habe. Nicht falsch verstehen! Die gezeigte Methodik ist durchaus wertvoll und auch sinnvoll. Meiner Meinung nach war aber Zentrader beim Schreiben dieses Buches in der Zwickmühle: Für wen ist das Buch gedacht? => Für Entwickler von Handelssystemen Was können Entwickler von Handelssystemen? => Programmieren Was also, wenn man genau erklärt, wie die Datenanalyse und Generierung funktioniert ==>> RICHTIG, dann programmiert sich der Programmierer das selbst und kauft keinen Zen Monte Carlo Simulator Das ist zumindest mein Eindruck von dem Buch. Nichts desto trotz finde ich die genannte SW recht interessant (auf www.zentrader.de gibt's auch ein Filmchen dazu). Das Buch hätte es aber nicht gebraucht.

... und kein etoro. Dabei geben die sich doch immer soviel Mühe ...

N-E-I-N