Problem mit dem Tester im visuellen Modus.
Da hilft nur visuell testen anhand realer Ticks!!
Geh mal davon aus, dass der TestModus OHCL nicht für den visuellen Test geeignet, sonder für die Optimierung auf Geschwindigkeit optimiert ist!
Da hilft nur visuell testen anhand realer Ticks!!
Geh mal davon aus, dass der TestModus OHCL nicht für den visuellen Test geeignet, sonder für die Optimierung auf Geschwindigkeit optimiert ist!
Anscheinend versteht mich auch hier niemand und keiner macht sich die Mühe das nachzuprüfen.
Der Testmodus ist EGAL. Die Ereignisabarbeitung im visuellen Tester ist einfach FALSCH.
Optimierung mit Geschwindigkeit wird doch nicht im visuellen Mode durchgeführt!Anscheinend versteht mich auch hier niemand und keiner macht sich die Mühe das nachzuprüfen.
Der Testmodus ist EGAL. Die Ereignisabarbeitung im visuellen Tester ist einfach FALSCH.
Optimierung mit Geschwindigkeit wird doch nicht im visuellen Mode durchgeführt!Ich verstehe Dich schon! Ich hatte das auch erlebt, aber das war dann besser bei visuellem Test mit realen Daten!
Wie ich schon sagte: "Geh mal davon aus, dass der TestModus OHCL nicht für den visuellen Test geeignet, ..." und verwende das einfach nicht, wenn Du die Probleme vermeiden willst!
Ich verstehe Dich schon! Ich hatte das auch erlebt, aber das war dann besser bei visuellem Test mit realen Daten!
Wie ich schon sagte: "Geh mal davon aus, dass der TestModus OHCL nicht für den visuellen Test geeignet, ..." und verwende das einfach nicht, wenn Du die Probleme vermeiden willst!
Sag, was ist los, das ist ein Test mit 'every tick based on real ticks'.
Es hat ja schon einmal den Fall gegeben, wo die Indikatoren wie wild herumgehüpft sind.
Hier ist es noch schlimmer:
Das ist alles sehr aufwändig zu dokumentieren. Aber wahrscheinlich ist es für die Katz.
Also hier stimmen doch Kauf und Verkauf mit den Kursen (Ticks) überein!
Es ist wohl so, dass die Darstellung auf dem Chart - der visuelle Teil ist offenbar der langsamste Teil des Terminals - dem rein rechnerischen Teil hinterherläuft. Bzw. wie die CPUs macht das Terminal, im Vergleich zu Darstellung, eine Art, "speculative execution". Es berechnet etwas, was auf dem Chart erst später 'gebraucht' bzw. gezeichnet wird. Und Du kannst auch die Priorität erkennen: Die "Wandmalereien" der Kerzen und der Indikatoren kommen zuletzt.
Anders ausgedrückt sind das wohl zwei Threads die wechselweise 'drankommen'.
Hast Du mal erlebt, wie stark bei einem Indikator, der, wenn prev_calculated == 0 ist, bei jeder Bar einen Comment("") schreibt, seine Berechnung verlangsamt wird, bis er dann endlich bei der letzten, aktuellen Bar angekommen ist?
Ich muss Dir sagen, ich finde diese Priorisierung eigentlich nicht schlecht, denn am Ende geht es bei einem EA ja nicht um den visuellen Backtest oder dem Malen der Kerzen und Indikatoren, sondern um die Positionen, die kommen wohl zuerst und dann wird gemalt.
Mit diesem Problem kämpfe ich seit Monaten, habe bisher keine Lösung gefunden.Ein EA, der in einer OnTick() Schleife läuft, meint das
OnTick() auch wirklich so: d.h. erst nach einem neuen Tick Ereignis vom Server wird auch ein ChartRedraw ausgeführt. Damit ist m.E.
die Beobachtung auf den Zeitversatz zwischen Ereignis und Chart Darstellung genau um diesen Tick versetzt. Im Realmodus kann man
das durch ein Click im Chart per Maus abfangen. Im Strategy Tester hingegen sehe ich in der debug Toolbox bereits was passiert ist,
im Chart aber erst ein Tick später. Das ist ärgerlich und wo möglich habe ich ein kleines workaround gefunden: Ich stoppe die interne
weitere Verarbeitung in der OnTick() Schleife durch ein simples "return;". Das ist in einer void OnTick() Schleife quick but dirty, hilft aber
im debug Modus die Darstellung im Chart und Wertentwicklung in der Toolbox zu synchronisieren.
Mit diesem Problem kämpfe ich seit Monaten, habe bisher keine Lösung gefunden.
Hallo Andreas, endlich jemand, dem dieses Problem auch aufgefallen ist.
#property tester_everytick_calculateist leider auch unwirksam.
Der Versatz von rechnerischem und grafischem Zustand hängt stark von der eingestellten Geschwindigkeit im Tester ab.
Je schneller, desto verzögerter der Chart.
Eine option wie
#property tester_everytick_chartredraw gibt es leider nicht, sollte aber eingebaut werden.
Ich erwarte aber nicht, daß die Russen das verstehen und einbauen.
Meine derzeitigen workarounds:
tickindex++;
if(NewBar(inp_wFrame))
barsindex++;
if(waitflag)
waitflag=false; // hier den Breakpoint setzen
Zähler für ticks, bars, datetime um den tester so schnell als möglich zu dem zu untersuchenden Punkt hinlaufen zu lassen.
Dort mit einem Breakpoint anhalten, manuell auf langsam stellen, und dann langsam weiterlaufen lassen.
Alles sehr mühsam. Und der OHLC mode ist so wie so für die Katz.
Hallo Andreas, endlich jemand, dem dieses Problem auch aufgefallen ist.
ist leider auch unwirksam.
Der Versatz von rechnerischem und grafischem Zustand hängt stark von der eingestellten Geschwindigkeit im Tester ab.
Je schneller, desto verzögerter der Chart.
Eine option wie
gibt es leider nicht, sollte aber eingebaut werden.
Ich erwarte aber nicht, daß die Russen das verstehen und einbauen.
Meine derzeitigen workarounds:
Zähler für ticks, bars, datetime um den tester so schnell als möglich zu dem zu untersuchenden Punkt hinlaufen zu lassen.
Dort mit einem Breakpoint anhalten, manuell auf langsam stellen, und dann langsam weiterlaufen lassen.
Alles sehr mühsam. Und der OHLC mode ist so wie so für die Katz.
Versucht doch mal Backtest mit historischen Daten und den entspr. Einstellungen..
Hallo Otto,
Richtig, Nachteil ist auch das der Speed Slider im Strategy Tester eigentlich erst auf den letzten Zentimeter wirkt, die Einstellung ist irgendwie
logarhytmisch. Mein WorkAround Ansatzt dazu ist ebenso wie Deiner, nur ohne Breakpoint, weil dann ja trotzdem manuell in die Geschwindigkeitsein-
stellung eingegriffen werden muß. Meine Lösung (im Geltungsbereich meiner EA) ist eine EREIGNISORIENTIERTE Verzögerung, einfach über eine
while Konstruktion. Wenn in meiner EA keine Position offen ist, kann der Strategy Tester unverzögert "heizen", sobald jedoch ein Trade geöffnet wird,
wirkt diese Konstruktion optisch verlangsamend und umgeht die Einstellung des Speedbars im Strategie Tester. So kann ich im eingestellten Zeitraum
meine EA Reaktionen viel schneller erkennen. Der Traderaum eines Jahres ist so in ca. 1,5 Minuten durchlaufen, ohne Unterbrechungen! Denn: Wichtig ist
das Langzeitverhalten. Ich kann jede Situation eines Tages optmieren, die Erfahrung sagt aber, das der gestern erfolgreiche Algorhythmus heute ein totaler
Ausfall sein kann. Deshalb "mittle" ich meine Algorhythmen über einen laaangen Testraum. Steht alles mit 55:45 im Gewinn, lasse ich es gut sein, Gier frißt Hirn
ist auch hier fehl am Platz. Aber das ist meine Haltung... Hier mein Vorschlag nur als Rumpf Beispiel:
OnInit()
{
if(!QLInfoInteger(MQL_TESTER)) // Abfrage auf Real- oder Test Tades
{
g_strategyTest = true; // Flag für Strategy Test lesen, g_strategyTest muß vorher global definiert sein
......
}
void OnTick()
... do something
... count Tick+1
if(allIsFlat && g_strategyTest) // keine Position offen (allIsFlat) UND StrategyTest = ein
{
return; // den Rest des EAs umgehen, gleich auf den nächsten Tick warten
}
else // ein Position ist offen -> While Konstruktion ansteuern
Delay(5000); // mit 5000 Einheiten (Beispiel!) Verzögerung den SpeedBar im StrategyTester "ausbremsen", um optisch nachvollziehbar den Trade zu verfolgen
....
... EA Trade Funktionen abarbeiten
} // Ende der OnTick Schleife
void Delay(ulong delayTicks)
{
string tickTime = NULL;
while(delayTicks >0) // delayTicks ab 1000 Einheiten entspr. ca 0,1 sek (abh. vom PC Takt)
{
tickTime =TimeToString(TimeCurrent()); // nur was machen, was Zeit kostet, die ticktime ist uninteressant, weil hier unverändert
delayTicks--;
}
} // zurück
Ich hoffe, die Idee dahinter ist verständlich. Was ich noch mache: Über die zu testende Tradestrecke lasse ich ein ScreenShot Programm (hier SNAGIT) laufen
und alles aufzeichnen. Die Snippets schaue ich dann danach in Slomo in Ruhe an und muß nicht 100 mal dieselbe Situation aufrufen.
Viel Erfolg,
Andreas
Nachtrag, weil Fehler in der OnInit(): Richtig muß es heißen:
if(QLInfoInteger(MQL_TESTER)) // Abfrage auf Real- oder Test Tades
{
g_strategyTest = true; // Flag für Strategy Test lesen, g_strategyTest muß vorher global definiert sein
...
}
Andreas
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Der Tester aktualisiert den Bildschirm zu spät, bzw. die OnTick wird zu früh aufgerufen.
Dadurch wird ein langsames, genaues, visuelles debuggen fast unmöglich.
Screenshot direkt nach 'Trade.Buy()':
Der Pfeil wird ins 'nichts' gezeichnet. Dorthin wo in der OnTick() der Preis bereits ist.
Erst beim Wiedereintritt in die OnTick(), also dem nächsten Aufruf, wird der Screen aktualisiert.
Jetzt erst ist die Grafik dort wo sie sein soll.
Ein Workaround derzeit: in den Testerchart clicken und Bild nach links schieben. Dann sieht es so aus:
Jetzt stimmt zumindest die Kerze, die Preislinien sind aber immer noch falsch.
Ist das noch niemandem aufgefallen ?
ChartRedraw() nützt da auch nichts.
Es ist ein altes Problem, und ich habe es dem alten Service Desk und auch dem Renat gemeldet, doch die haben es nicht verstanden oder einfach ignoriert.
Doch ich finde dies extrem lästig.
@Calli: falls du das nachvollziehen kannst poste das bitte bei den Russen, mir hören die nicht zu.