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
Hehe, ein weiterer glücklicher Kunde :)- wenn wir schon dabei sind, LEHayes Geist geben mir Hilfe bei der Berechnung der Geld-Management in Prozent ohne Aufrunden der Pips. Hier ist, was ich derzeit verwenden, wenn ich 1% meines Kontos Eigenkapital wetten wollen :
double Profit_F=0.00001,Lots=0.1;
Lots=NormalizeDouble((AccountEquity()*Profit_F),1);
wenn (Lots < 0,1) Lots=0,1;
wenn (Lots > 1.0) Lots=1.0;
Dies funktioniert gut für meine Stoploss von 100, wenn ich ein $10,000 zum Beispiel. Als $10,000 X 0.00001 = 0.1 Lot. Aber wenn ich $15.000 habe, ist die Lotgröße jetzt 0,15, aber es wird auf 2,0 gerundet, vielleicht weil mein Broker keine Makro-Lots erlaubt. Wie kann ich erzwingen, dass es bei 0,1 bleibt, bis das Eigenkapital 20.000 $ erreicht? Ich bin schon lange wach, und nachdem ich Ihren Thread gelesen habe, bin ich zu müde zum Suchen und Studieren. Wenn Sie eine andere Gleichung für die Berechnung von mm haben, stellen Sie sie bitte zur Verfügung.
Das macht mich wahnsinnig, ich habe seit Monaten nach einem bestehenden Algorithmus gesucht, der nichts anderes tut, als den Preis pro Pip zu berechnen, unabhängig von dem Paar, auf dem er steht. Ich habe 2 wirklich gute Geld-Management-Strategien, die beide abhängig von diesem Wert als eine Möglichkeit zur Vorausberechnung Handel Größen und Geld-Risiko-Management gefunden, aber ich kann nicht finden, ein einziges Beispiel für eine Berechnung, die Griffe Preis pro Pip.
Ich bin bereit, Ihnen mein Geldmanagementsystem im Austausch dafür in einer Funktion anzubieten. Ich werde Ihnen beide Techniken zur Verfügung stellen, die von den Mentoren, mit denen ich zusammengearbeitet habe, vorgeschlagen wurden.
Zunächst müssen wir erkennen, dass es fünf grundlegende Symboltypen gibt. Dies ist wichtig, wenn es um Fragen wie die Berechnung von tick_value, Leverage usw. geht.
Es gibt keine formale Definition des Symboltyps, aber für ein auf USD lautendes Konto zähle ich die Symboltypen folgendermaßen auf: (dies sind spezifische Beispiele, nicht allumfassend)
Die Relevanz besteht darin, wie die Bezeichnung des Kontos mit der Basiswährung und der Gegenwährung des Finanzinstruments, das Sie interessiert, zusammenhängt. Das gilt sowohl für CFDs als auch für Währungspaare.
In diesem Beispiel hätte die von mir kodierte Aufruffunktion bereits festgestellt, dass für AUDCAD das CalculatedBasePairForCross AUDUSD ist:Sobald Sie den Symboltyp kennen, können Sie den Hebel pro Finanzinstrument berechnen - hier ist zum Beispiel der Code, der zur Berechnung des Hebels für AUDCAD erforderlich ist:
CalculatedBasePairForCross=StringConcatenate(SymbolBase,AccountCurrency(),postfix);
Und die SymbolBase (das ist die Basiswährung des Finanzinstruments Symbol()) ist:Und so weiter.
Bei der Berechnung des Tick-Wertes müssen Sie den Symboltyp berücksichtigen, da dieser von Bedeutung ist, wenn sich die Bewertung sowohl des interessierenden Finanzinstruments - Symbol() - als auch des verbindenden Währungspaares, das zur Bezeichnung des Kontos zurückführt, ändert. In Fortsetzung des obigen Beispiels, in dem wir über den Symboltyp 4 - AUDCAD bei einem USD-Konto - sprechen, wird der Tick-Wert explizit wie folgt definiert:
Wobei die Variable CalculatedCounterPairForCross für AUDCAD zuvor als USDCAD festgelegt wurde:
CalculatedCounterPairForCross=StringConcatenate(AccountCurrency(),SymbolCounter,postfix);
Und SymbolCounter wurde bestimmt durch:Indem Sie die Berechnung dieser Werte explizit auf diese Weise programmieren, können Sie maklerunabhängige Marktinformationsfeststellungen treffen.
Beachten Sie, dass der Code hier nur für symboltype = 4 nützlich ist, bei dem die Kontenwährung die Gegenwährung ist, wenn sie mit der Basiswährung von Symbol() gepaart ist, und ebenso ist die Kontenwährung die Basiswährung, wenn sie mit der Gegenwährung gepaart ist, die das Symbol()-Paar bildet.
(AUDCAD -> AUDUSD & USDCAD)
Es stellt sich heraus, dass es zwar fünf universelle Symboltypen gibt, man aber nur vier von ihnen für die Berechnung von Hebelwirkung, Marge und Tickwert kategorisieren muss. Und die Mathematik wird nur dann zu einem besonderen Knackpunkt, wenn es um währungsübergreifende Paare im Verhältnis zur Kontendenz geht.
Ich habe die spezifischen Beziehungen zwischen allen Basis- und Gegenkombinationen herausgearbeitet, weil mein Geldmanagementansatz darin besteht, den Wert des Verlustrisikos für jeden Handel explizit zu definieren, und das setzt voraus, dass man genau den Kurswert kennt, zu dem der Handel beendet werden muss, damit der Verlust mit dem zuvor festgelegten Verlustbudget übereinstimmt. Bei Cross-Pairs stellt sich natürlich heraus, dass der Value at Risk auf dem Preis zweier Währungspaare zu einem bestimmten Zeitpunkt basiert (es sei denn, Sie sichern sich gegen das eine oder das andere ab).
Hilft diese Information überhaupt weiter?
TICKVALUE kann, wenn es allein verwendet wird, unzuverlässig sein.
Es wäre interessant zu wissen, auf welche(n) Broker dies zutrifft, oder ob es andere Überlegungen gibt, wie z. B. die Tatsache, dass der Markt gerade geöffnet/geschlossen ist. Ich war nie in der Lage, diese Ihre Ergebnisse zu replizieren.
Ist diese Information hilfreich?
Wow, ich habe nie realisiert, dass es so viel zur Berechnung des Wertes eines Pips gibt, in meinem EA habe ich es getan, indem ich das Ea es mit dem ersten offenen Auftrag berechnen ließ, wenn es ein Kauf ist, aktueller Geldkurs - offener Auftragskurs/Auftragsgewinn = Pip-Wert in der aktuellen Basiswährung, oder wenn es ein Verkauf ist, aktueller Auftrag+offenerKurs/Auftragsgewinn=Pip-Wert, wird das nicht richtig funktionieren?
Edit: Mir ist klar, dass ich das falsch herum geschrieben habe, ich meinte Ordergewinn/(aktueller Geldkurs - offener Kurs)=Pip-Wert
Wow, ich habe nie realisiert, dass es so viel zur Berechnung des Wertes eines Pips gibt, in meinem EA habe ich es getan, indem ich das Ea es mit dem ersten offenen Auftrag berechnen ließ, wenn es ein Kauf ist, aktueller Geldkurs - offener Auftragspreis/Auftragsgewinn = Pip-Wert in der aktuellen Basiswährung, oder wenn es ein Verkauf ist, aktueller Auftrag+offener Preis/Auftragsgewinn=Pip-Wert, wird dies nicht richtig funktionieren?
Diese Berechnung ist nur dann gültig, wenn jeder Pip den gleichen Wert hat, unabhängig vom aktuellen Geld- oder Briefkurs.
Dies gilt strikt für Währungspaare mit Symboltyp = 2, wie ich sie oben definiert habe, d. h. EURUSD usw. (jedes Währungspaar, bei dem die Denominierung des Kontos die Gegenwährung des Paares ist).
Für die meisten Leute spielen die Unterschiede wahrscheinlich keine Rolle, die daraus resultierenden Fehler sind gering. In meinem Fall wollte ich die Werte mit korrekten analytischen Ausdrücken solide berechnen.
Wenn ich z. B. 200 $ als maximal möglichen Verlust für einen bevorstehenden Handel einplane und meine Stopps auf 200 Punkte gesetzt sind, möchte ich die Losgröße für meine Order so festlegen, dass meine Verluste 200 $ nicht überschreiten... Um dies zuverlässig zu erreichen, muss ich die Pip-Bewertung zum Zeitpunkt des Stopp-Loss-Kurses korrekt berechnen. Das war weder für mich noch für meine Kunden eine akzeptable Option ;)
Ich bin froh, dass LEHayes alles in Ordnung gebracht hat. Und Phillip, du hast TickValue & Layout-Paare komplett entdistanziert - sehr gut, damit alle davon profitieren. Großartig!
Ich möchte nur hinzufügen: die Syntheseoperationen ...
CalculatedCounterPairForCross=StringConcatenate(AccountCurrency(),SymbolCounter,postfix);
SymbolCounter=StringSubstr(Symbol(),3,3);
... müssen für die extra append-age wie USDJPYm in einigen Mini-Lot-Broker aufpassen. Ich weiß nicht, ob ein Broker die ersten sechs Buchstaben der Symbole ändern könnte, indem er einen Buchstaben vor oder zwischen Basis und Zähler anhängt. Wenn Sie auf der Suche nach Robustheit sind, ist das Lesen aus einer .set- oder .sel-Datei IMO eine sicherere Wette.
Ich bin froh, dass LEHayes alles in Ordnung gebracht hat. Und Phillip, du hast TickValue & Layout-Paare komplett entdistanziert - sehr gut, damit alle davon profitieren. Großartig!
Ich möchte nur hinzufügen: die Syntheseoperationen ...
CalculatedCounterPairForCross=StringConcatenate(AccountCurrency(),SymbolCounter,postfix);
SymbolCounter=StringSubstr(Symbol(),3,3);
... müssen für die extra append-age wie USDJPYm in einigen Mini-Lot-Broker aufpassen. Ich weiß nicht, ob ein Broker die ersten sechs Buchstaben der Symbole ändern könnte, indem er einen Buchstaben vor oder zwischen Basis und Zähler anhängt. Wenn Sie auf der Suche nach Robustheit sind, ist IMO das Lesen aus einer .set- oder .sel-Datei eine sicherere Wahl.
Guter Punkt! Allerdings suche ich nicht nach dieser Art von Robustheit, wenn ich über robuste Berechnungen spreche.
Broker können ihre Währungspaare benennen, wie sie wollen, man würde hoffen, ich hätte die Geistesgegenwart, dies zu bemerken und meine Codes entsprechend zu ändern, bevor ich versuche, mit einem neuen Broker mit dem Währungssymbol lovelyUSDmoonCADcheese live zu handeln :P
Dieser Code deckt einfach 100% der Fälle ab, auf die ich bisher gestoßen bin (Alpari, CitiFX, CMS forex, forex.com, FXCM, FXDD, IBFX, MIG und ODL)... Ich mache mir keine Sorgen um die Zukunftssicherheit, nur um die Gegenwart. Wenn Sie etwas im Sinn haben, um es zukunftssicher zu machen... dann ist jetzt ein guter Zeitpunkt, um Ihre Meinung zu sagen :)
lovelyUSDmoonCADcheese! ...
Lol! Ich habe gesehen, dass Broker die Symbolbeschreibung in der Eigenschaft des Symbols falsch eingegeben haben (nicht den Symbol()-Parameter, aber auch den müssen sie irgendwann eingeben!) Wer weiß! :))
Ich kann nicht sagen, ob es jemals 100%ig narrensicher sein wird (was ist das schon?). Aber ich denke an so etwas wie dieses :
Gordon hat mir vor einiger Zeit seine Meinung darüber mitgeteilt, welche Vorteile eine automatische, narrensichere Prüfung in einem EA hätte. In Anbetracht dessen (und bei allem Respekt) denke ich immer noch, dass dies etwas sein könnte, das sich lohnt, und sei es nur zum Spaß! :)