Funktionsrückgabewerte im Strategietester - Seite 2
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Dabei fällt es mir ja auf; hierbei sehe ich ja, dass die Bedingung korrekt auf true springt, wenn die Kerze den MA durchbricht, aber das entsprechende Signal nicht returned wird. Da müsste ich eine Haube aufschrauben, wo ich nichtmal weiß, wo die Schrauben sind.
Das liegt wohl an Deinen Bedingungen, die zum jew. Signal führen. Vergiss nicht, dass während einer Bar, eine ganze Menge Ticks eintreffen.
.Außerdem ist PriceInfo[0].close nicht das Close der Bar[0] sondern der letzte, aktuelle Preis (Bid-Preis), der sich ständig ändert! => also mal true mal false
Das liegt wohl an Deinen Bedingungen, die zum jew. Signal führen. Vergiss nicht, dass während einer Bar, eine ganze Menge Ticks eintreffen.
.Außerdem ist PriceInfo[0].close nicht das Close der Bar[0] sondern der letzte, aktuelle Preis (Bid-Preis), der sich ständig ändert! => also mal true mal false
Ja, ist klar, dass während eines Bars eine Menge Ticks eintreffen; wenn aber die Bedingung pro Tick true ist, sollte auch das return value jedesmal das entsprechende sein.
Die simple Testbedingung hier ist, dass sobald die Kerze in die entgegengesetzte Richtung den MA durchbricht als die davor schloss, haben wir das Signal. Ich sehe ja im Chart des Strategietesters mit F5 pro Tick, dass die Bedingung true ist; der Wert für die Bedingung bleibt ja pro F5 entsprechend true, aber der return value springt von SIG_SELL oder BUY auf NONE? Das riecht mir irgendwie nach einem Bug..
Ja, ist klar, dass während eines Bars eine Menge Ticks eintreffen; wenn aber die Bedingung pro Tick true ist, sollte auch das return value jedesmal das entsprechende sein.
Die simple Testbedingung hier ist, dass sobald die Kerze in die entgegengesetzte Richtung den MA durchbricht als die davor schloss, haben wir das Signal. Ich sehe ja im Chart des Strategietesters mit F5 pro Tick, dass die Bedingung true ist; der Wert für die Bedingung bleibt ja pro F5 entsprechend true, aber der return value springt von SIG_SELL oder BUY auf NONE? Das riecht mir irgendwie nach einem Bug..
Wenn dann nur in Deinem Code.
Mach dort, wo das Signal zugewiesen wird ein Breakpoint (F9, links gibt's dann den blauen Punkt) und überprüf alle Werte :
PriceInfo[1].close, bufferSMA[1], .. Du kannst auch das if eingeben: PriceInfo[1].close < bufferSMA[1].
Wenn dann nur in Deinem Code.
Mach dort, wo das Signal zugewiesen wird ein Breakpoint (F9, links gibt's dann den blauen Punkt) und überprüf alle Werte :
PriceInfo[1].close, bufferSMA[1], .. Du kannst auch das if eingeben: PriceInfo[1].close < bufferSMA[1].
Ich habe Dir mal aufgenommen, was ich sehe und meine: http://linden-it-net.de/share/nosignal.mp4
Ich habe Dir mal aufgenommen, was ich sehe und meine: http://linden-it-net.de/share/nosignal.mp4
Du hast einen Denkfehler mit dem Debugger.
Wenn der Debugger in einem Scope (Teil der Funktion in der Klammer) hält sind andere Scopes nicht auswertbar.
Anscheinend ist das noch ein BUG im Debugger. Der er müsste da eigentlich "Unknown identifyer" zeigen, da er aber den Ausdruck auswerten kann siehst Du falsche Werte.
Bedeutet in Deinem Fall, wenn der Debugger an SIGNAL Signal() hält, steht er am Anfang der Funktion und dann sind die Werte der Funktion noch gar nicht gültig.
Er zeigt Dir dann die Werte vom letzten Durchlauf der Funktion an.
Du musst den Debugger eine Zeile tiefer halten lassen
Füge mal PrintFormat(signalnow); ein und lass ihn da halten.
Ich habe Dir mal aufgenommen, was ich sehe und meine: http://linden-it-net.de/share/nosignal.mp4
Im Prinzip reicht es zu wissen, dass er im Return gehalten hat, dann ist die Bedingung, wenn sie denn richtig programmiert definitiv wahr .
Ist auch ein Grund warum ich es hasse, wenn Leute riesige Return Anweisungen Konstruieren, die dann nicht debuggbar sind.
Ich habe Dir mal aufgenommen, was ich sehe und meine: http://linden-it-net.de/share/nosignal.mp4
Der Debugger hält an, bevor die Zeile/Aweisung ausgeführt wurde!
Mach einfach ein ; in der Zeile da drunter und setz den Breakpoint auf das ;
Du hast einen Denkfehler mit dem Debugger.
Wenn der Debugger in einem Scope (Teil der Funktion in der Klammer) hält sind andere Scopes nicht auswertbar.
Anscheinend ist das noch ein BUG im Debugger. Der er müsste da eigentlich "Unknown identifyer" zeigen, da er aber den Ausdruck auswerten kann siehst Du falsche Werte.
Bedeutet in Deinem Fall, wenn der Debugger an SIGNAL Signal() hält, steht er am Anfang der Funktion
>> Das ist klar; wenn er dort aber zum zweiten Mal steht, sollte ich noch die Werte vom ersten Durchlauf sehen, oder nicht?
und dann sind die Werte der Funktion noch gar nicht gültig.
Er zeigt Dir dann die Werte vom letzten Durchlauf der Funktion an.
Du hast einen Denkfehler mit dem Debugger.
Wenn der Debugger in einem Scope (Teil der Funktion in der Klammer) hält sind andere Scopes nicht auswertbar.
Anscheinend ist das noch ein BUG im Debugger. Der er müsste da eigentlich "Unknown identifyer" zeigen, da er aber den Ausdruck auswerten kann siehst Du falsche Werte.
Bedeutet in Deinem Fall, wenn der Debugger an SIGNAL Signal() hält, steht er am Anfang der Funktion und dann sind die Werte der Funktion noch gar nicht gültig.
Er zeigt Dir dann die Werte vom letzten Durchlauf der Funktion an.
Du musst den Debugger eine Zeile tiefer halten lassen
Füge mal PrintFormat(signalnow); ein und lass ihn da halten.
Du musst den Debugger eine Zeile tiefer halten lassen
Füge mal PrintFormat(signalnow); ein und lass ihn da halten.
PrintFormat(signalnow) ist korrekt!
Macht Sinn, dass signalnow aus der Funktion heraus nur "unknown identifier" liefert kann und sollte.
Danke!
Im Prinzip reicht es zu wissen, dass er im Return gehalten hat, dann ist die Bedingung, wenn sie denn richtig programmiert definitiv wahr .
Ist auch ein Grund warum ich es hasse, wenn Leute riesige Return Anweisungen Konstruieren, die dann nicht debuggbar sind.
Also das Return-Value lässt sich nicht direkt einsehen; für mich unverständlich, aber das wird schon seinen Grund haben.
Der Debugger hält an, bevor die Zeile/Aweisung ausgeführt wurde!
Mach einfach ein ; in der Zeile da drunter und setz den Breakpoint auf das ;
Ja, habe mir gedacht, dass der vor der Anweisung anhält, daher habe ich immer den Wert auf den Durchlauf vorher bezogen.
Einen Breakpoint kann man weder bei ";" allein noch bei einer Print("xxx"); Anweisung setzen, das lässt der Debugger nicht zu.
Viele Dank und schön langes Wochenende!