Wer will eine Strategie? Lose und kostenlos) - Seite 63

Neuer Kommentar
 

Ja, die Mail ist korrekt.

Ich habe Ihnen vor einer Minute eine private Nachricht geschickt.

 

Oh, ich hatte die private Leitung ganz vergessen :))))))

Dort stapelt es sich bereits :). Leute - entschuldigt, wenn ich nicht rechtzeitig geantwortet habe, aber ich schalte normalerweise persönliche Nachrichten in Foren aus und habe hier aus Gewohnheit nicht einmal darauf geachtet :)...


Miroslav - dann werde ich jetzt eine Nachricht (Antwort) vorbereiten und per Post schicken ...

 

**Erinnern Sie sich, Bar Opening und Bar Closing - Point of the Position sind nicht die einzigen Probleme, die Werte der gemeinsamen Indikatoren können dort verwendet werden. So kann eine Position "in der Mitte" eines Balkens eröffnet werden (einfach!). (sozusagen über die Berechnung der Indikatorwerte NUR am Schnittpunkt der Balken... wie gesagt - diese Bedingung ist "nicht immer" erfüllbar ;))**


Wenn ich Sie richtig verstehe, denken Sie, dass wir einen Indikator bei jedem Tick neu berechnen müssen, wenn der Einstiegspunkt in der Mitte des Balkens liegt (z. B. bei einem MA). Ich werde es mir leisten, nicht mit Ihnen übereinzustimmen.


Für einen zuverlässigen Backtest (mit MT, FSB oder einem anderen Tester) müssen alle Indikatoren einschließlich der Einstiegs- und Ausstiegspunkte festgelegt werden. Das schränkt einen EA nicht ein, den Markteintritt während des Balkens zu nutzen.

Beispiele:


1) Einstieg bei gleitendem Durchschnitt (21, Schlusskurs):

In diesem Fall können wir den aktuellen MA nicht verwenden, da er sich nach oben/unten bewegt, bis der Schlusskurs des Balkens feststeht. Wir müssen also den MA des vorherigen Balkens verwenden. Auf diese Weise ist es nicht notwendig, sie bei jedem Tick neu zu berechnen.


2 Einstieg bei gleitendem Durchschnitt (21, offen):

Hier können wir den aktuellen MA verwenden. Er ist festgelegt, weil der MA-Basispreis - Bar Opening - bereits festgelegt ist. Wir müssen sie auch nicht bei jedem Tick neu berechnen.


--------

Bearbeiten:

Natürlich ist dies meine persönliche Meinung.

Ich habe nicht die Absicht, Sie auf diese Weise zum Backtesting zu zwingen.

Grüß Gott!


Bearbeiten2:

Falls ich etwas übersehen habe, zeigen Sie mir bitte ein Beispiel für eine mit FSB vorbereitete Strategie, bei der ein Indikator bei jedem Tick neu berechnet werden muss.

 

Mmm, Miroslav, ich verstehe die Idee (die übrigens schon lange zurückliegt)!

Ich war nur verwirrt von den Konstruktionen im Indikatorcode, die ich oben angegeben habe:

                    case "The position opens above the MA value":
                        component[0]. PosPriceDependence = PositionPriceDependence. BuyHigherSellLower;
                        component[0]. UsePreviousBar     = iPrvs;
                        component[1]. DataType           = IndComponentType. Other;
                        component[1]. ShowInDynInfo      = false;
                        component[2]. DataType           = IndComponentType. Other;
                        component[2]. ShowInDynInfo      = false;
                        break;

nämlich: Komponente[0].PosPriceDependence = PositionPriceDependence.KaufenHöherVerkaufenNiedriger;

Das ist aber nicht der Fall, oder? Es ist wichtig zu verstehen, dass ich nicht über die Berechnung des Indikators an sich spreche. Deren Wert ist ja innerhalb eines Balkens stationär. Aber was ist mit der Tatsache, dass wir in diesem Fall (den ich oben zitiert habe) den letzten Preiswert mit ihm vergleichen müssen? Um eine Entscheidung zur Eröffnung einer Position zu treffen. Bei der FSB geschieht dies durch interne Verfahren (wenn ich es richtig verstanden habe). Aber weil sie "uns nicht bekannt sind" (und wozu eigentlich?) - habe ich vorgeschlagen, den Indikator in solchen Fällen bei jedem Tick neu zu berechnen, um ein eindeutiges JA/NEIN zur logischen Bedingung zu erhalten. Mit anderen Worten: Lassen Sie den Indikator selbst diese Schlussfolgerung ziehen, nicht den Code, der außerhalb des Indikators liegt. Ich habe es ernst gemeint!

Ich meine, ähm, noch einmal - ich stimme der These zu, dass der Indikator einmal auf "kreuzenden" Balken berechnet werden sollte. Aber in den Fällen, in denen der Indikator Signale über die Positionseröffnung gibt, sollten wir uns in der Anwendung auf die Arbeit zukünftiger EA(s) in MT - nur auf diese Werte (JA/NEIN) verlassen und nicht auf den Vergleich der aktuellen Preise mit den Indikatorpreisen (die statisch sind). Dies soll der Indikator selbst für uns vergleichen. Und wir werden nur sein JA/NEIN berücksichtigen. Das war's... :)


Oder übersehe ich irgendwo etwas? :D? ("hat ein bisschen was von einer Mammy...")

 

Daraus ergibt sich die Schlussfolgerung, dass ich diese Berechnungen überarbeiten muss (ich habe gerade darüber nachgedacht), um Close[iBar] mit dem aktuellen oder vorherigen Wert des Indikators (welcher von ihnen statisch ist) korrekt zu vergleichen (iPrvs sollte berücksichtigt werden). Aber ich glaube, ich liege mit meiner Idee nicht falsch...?!



(worüber diskutieren wir überhaupt :))?! Indikatoren werden weiterhin für die Arbeit mit IndicatorCounted() ANYWHERE berücksichtigt!!! Ich würde es einfach nicht anders machen :). Sie können nicht nur von EA-Autoren verwendet werden, sondern auch von Benutzern, die einen visuellen Teil (und Echtzeitwerte) benötigen. Der ursprüngliche Code ändert sich kein bisschen! In der Regel fügt man einfach ein Bit am Anfang ein, das die "ursprünglichen" Werte der selbst referenzierten Variablen initialisiert. Nicht mehr als das... Manchmal wird dies als "wenig Blut" bezeichnet. Manchmal auch nicht so sehr (wie im Beispiel Hourly High Low). Aber auf jeden Fall ist der körperliche Aufwand (noch?) minimal :))


Oder handelt es sich um einen globalen Aspekt? Dann gibt es nichts zu diskutieren - iPrvs ist großartig!:) Schluss damit! Aber niemand widerspricht dem :)!


(Ich habe eine E-Mail geschickt... ich werde versuchen, sie hier persönlich zu beantworten)

  
case "Die Position öffnet oberhalb des MA-Wertes":
 component[0].PosPriceDependence = PositionPriceDependence.BuyHigherSellLower;


 Diese Logik kann nicht über den Indikator selbst verwaltet werden, da die Signale vom Entry Point Indikator abhängen.

 Diese Logik gibt keine Kauf-/Verkaufssignale (1 , 0) wie die anderen. 

 FSB geht wie folgt vor:

(1) Dieser Indikator wird bei der Entscheidung für den Handel zunächst ignoriert;
 Wenn alle anderen logischen Regeln erfüllt sind und die FSB den Eintrittspunkt kennt, prüft sie diesen Indikator, um den Eintritt kurz vor der eigentlichen Ausführung zu erlauben oder zu verbieten.

 Dies ist im Backtester enthalten.

 Es gibt drei Optionen für die Bewerbung in einem EA:

 1. zuerst die Einstiegspunkte zu berechnen (in einem Array). Danach wird dieses Array an den Indikator gesendet, um die Kauf-/Verkaufssignale zu berechnen.

 2. eine Basismethode EntryPrice(int iBar) zu haben, die den Eröffnungskurs der Position zurückgibt. 
 Die Position wird oberhalb des MA-Wertes eröffnet:
 for(int iBar ... )
{
 SignalLong[iBar] = EntryPrice(iBar) > MA[iBar] ? 1 : 0;
 SignalShort[iBar] = EntryPrice(iBar) < MA[iBar] ? 1 : 0;
}

 3. diesen Indikator vor der eigentlichen Eingabe aufzurufen:
 double EntryPrice = ....;
 If(Einstiegskurs > fsb_MA(...))
 OrderSend(...);


----

 Es gibt mehrere Indikatoren, die keine 1:0-Signale setzen:
- Alle Indikatoren mit der Logik "Position öffnet über / unter ..."
- Zeit"-Indikatoren: Eintrittszeit, Eintrittsstunde, Wochentag;
- Konto Percent Stop
- ATR-Stopp
- Stop Grenze
- Verluststopp
- Gewinnmitnahme
- Nachlaufender Stopp
- Nachlaufender Stopp Limit
- Losbegrenzer

 Diese "Indikatoren" erlauben den Ein- und Ausstieg zum Zeitpunkt des Handels;










 

Miroslav - ich hab's! Nicht in dem Sinne, dass ich endlich etwas verstanden habe :) (die Idee, FSB mit Indikatorlogik zu manipulieren,

Ich habe es schon vor langer Zeit verstanden (ich berücksichtige Stop Limit und andere Dinge nicht, ich habe sie noch nicht gesehen).

Endlich erinnere ich mich an etwas, sagen wir einfach :)


WIR sprechen nur im gleichen Kontext über verschiedene Anwendungen (d.h. sowohl die Anwendungen selbst (FSB und MT) als auch "in Anwendung auf").

Der wichtigste Punkt ist die einmaligeBerechnung der FSB-Indikatoren vor dem eigentlichen Backtesting-Verfahren.

FSB kann für solche Bedingungen ("Position öffnet oberhalb / unterhalb ...") vor dem eigentlichen Test nicht eindeutig 1/0 berechnen!

Es ist also genau die richtige Logik:

1. Er ignoriert diesen Indikator zunächst, wenn er eine Handelsentscheidung trifft;
 2. Wenn alle anderen Logikregeln erfüllt sind und FSB den Einstiegspunkt kennt, prüft er diesen Indikator, um den Einstieg kurz vor der eigentlichen Ausführung zu erlauben oder zu verbieten.
In unserem Fall (RealTime) ist dies jedoch nicht zwingend erforderlich. Oder besser gesagt - die Berechnung von Indikatoren "ständig und im Vorbeigehen" - wir haben zu jedem beliebigen Zeitpunkt
Zu jedem Zeitpunkt haben wir eine eindeutige Antwort 1/0 für diese logische Bedingung.
Wir "können" immer noch keine Position zum letzten verfügbaren Kurs (Close[0]) eröffnen. Warum also nicht den Indikator damit vergleichen?
Und warum nicht wie in anderen Fällen eine logische 1/0 ausgeben (sorry, die Formatierung ist "off", ich will nicht in HTML schauen (es hat keinen Sinn, "auszuflippen"):
 Fall MA_POS_OPENS_ABOVE:
for (iBar = iFirstBar; iBar >= 0; iBar--) {
 LPIndBuffer[iBar] = Close[iBar] > adMA[iBar];
 SPIndBuffer[iBar] = Close[iBar] < adMA[iBar];
}
break;

// Was offensichtlich korrekter ist, wenn man es mit Blick auf iPrvs umschreibt (es ist mir heute erst "gedämmert", wie man dieses Problem generell umgehen kann)

case MA_POS_OPENS_ABOVE:
For (iBar = iFirstBar; iBar >= 0; iBar--) {
 LPIndBuffer[iBar] = Close[iBar] > adMA[iBar + iPrvs];
 SPIndBuffer[iBar] = Close[iBar] < adMA[iBar + iPrvs];
}
break;

// In Anbetracht der Tatsache, dass die Werte aller Balken außer [0] (Echtzeit) "nicht ganz richtig" sein werden (oder besser gesagt, für Close[iBar] festgelegt sind), können wir den Code wie folgt ändern

Fall MA_POS_OPENS_ABOVE:
for (iBar = iFirstBar + 1; iBar >= 0; iBar--) {
if (iBar > 0) {
 LPIndBuffer[iBar] = 0.0;
 SPIndBuffer[iBar] = 0.0;
} else {
 LPIndBuffer[iBar] = Close[iBar] > adMA[iBar + iPrvs];
 SPIndBuffer[iBar] = Close[iBar] < adMA[iBar + iPrvs];
}
}
break;

// T.D.h. für alle Balken, außer [0], zeigt der Indikator an, dass diese Bedingung nicht erfüllt ist (war) - eine Frage der Ästhetik sozusagen... nichts mehr.

 

(off: Ich versuche, den Code wieder einzufügen, als separaten Kommentar - "die Steinblume kommt nicht heraus" :), dann ein leerer Kommentar, dann geht es einfach zur ersten Seite... Vielleicht gibt es einige Elemente im Text - "nicht verdaulich"... im Allgemeinen - so lesen (wie oben) :))

 

Meine Herren, Miroslav hat FSB gestern auf Version 2.8.3.6 Beta aktualisiert:

http://forexsb.com/forum/post/2446/#p2446


Die Signallogik wurde vereinheitlicht. Die Änderungen betrafen die große Mehrheit der Indikatoren. Der Code für die Berechnung der Indikatoren wurde nicht geändert!

Die Logiksignale wurden etwas weniger anfällig für "Rauschen". In der Konfigurationsdatei wurden zwei Parameter hinzugefügt:

  <SIGMA_MODE_MAIN_CHART> 1</SIGMA_MODE_MAIN_CHART>
  <SIGMA_MODE_SEPARATED_CHART> 5</SIGMA_MODE_SEPARATED_CHART>

Die Parameter legen den "Schwellenwert" der Signale fest, die von der Preisänderungsebene ausgelöst werden (für Indikatoren im Fenster mit dem Chart und für Indikatoren mit eigenem Fenster).

Die Entsprechungen der MODE-Werte sind hier angegeben:

http://forexsb.com/library/source/Sigma.html


Wir sind der Meinung, dass die "Standard"-Werte (in den meisten Fällen) GENAU richtig sind. Aber... Sie können gerne experimentieren :).


Ich habe absichtlich auf diese Veröffentlichung gewartet, um nicht doppelt arbeiten zu müssen. Ich stelle auch meine eigenen Werke ein. Ich habe im Moment 20 Indikatoren (2 davon würde ich nicht als "nützlich" bezeichnen (Bar Closing / Bar Opening) - sie werden in Zukunft nützlich sein ;)):

-FSB- Accelerator Oscillator.ex4
-FSB- Accumulation Distribution.ex4
-FSB- ADX.ex4
-FSB- Bar Closing.ex4
-FSB- Bar Opening.ex4
-FSB- Bar Range.ex4
-FSB- Bollinger Bands.ex4
-FSB- Donchian Channel.ex4
-FSB- Envelopes.ex4
-FSB- Force Index.ex4
-FSB- Heiken Ashi.ex4
-FSB- Hourly High Low.ex4
-FSB- Ichimoku Kinko Hyo.ex4
-FSB- Keltner Channel.ex4
-FSB- Moving Average.ex4
-FSB- Price Oscillator.ex4
-FSB- RSI MA Oscillator.ex4
-FSB- RSI.ex4
-FSB- Starc Bands.ex4
-FSB- Steady Bands.ex4

Die Berechnungsalgorithmen und die Signallogik sind vollständig FSB-konform (naja... sollten :D)...

EINSCHLIESSLICH DER INDIKATORWERTE!!! (FSB (Anwendung) = -FSB- (Umwandlung) = MT (intern) ) (bis zu einem beliebigen Zeichen).

Die Ausnahme ist "-FSB- Accumulation Distribution.ex4" - Miroslav hat dort einen kniffligen Code, ich bin noch nicht dazu gekommen (stimmt nicht genau mit MT überein, habe es nicht mit FSB überprüft).


Ich fahre in alphabetischer Reihenfolge fort (na ja, fast). Wenn jemand etwas mit höherer Priorität braucht, schreibt... (Person mit Hourly High Low irgendwo verschwunden, habe ich nicht verstanden - hat es geholfen oder nicht :D?!)


Gleichzeitig beginnen wir mit der Entwicklung von EA, die mit diesen Versionen von Indikatoren arbeiten können. Am Ende sollte sich eine Art Garbe befinden:

FSB -> Exportierte Strategiedatei -> EA, basierend auf konvertierten Indikatoren und interner Handelslogik, kompatibel mit FSB...


Viel Glück! Und frohe Feiertage an alle!!!

Ich werde mich Anfang der Woche melden... Bleiben Sie dran...

Dateien:
fsb2mql_20090430.rar  270 kb
 
Stellarator >> :

Meine Herren, Miroslav hat FSB gestern auf die Version 2.8.3.6 Beta aktualisiert:

http://forexsb.com/forum/post/2446/#p2446


Ich lade gerade etwas herunter und das Archiv ist kaputt... :
1...5657585960616263646566
Neuer Kommentar
Grund der Beschwerde: