Preis pro Pip - Seite 9

Neuer Kommentar
 
gordon:

Meine Definition verliert ihre ursprüngliche Bedeutung, wenn sie aus dem Zusammenhang gerissen wird. Zur Klarstellung: Das Wort "Preis" in der Definition für MODE_TICKSIZE bezieht sich auf die tatsächlich möglichen Kursnotierungen, während es sich in der Definition für Point auf einen beliebigen Preis bezieht.

- Gordon, meine Definition ist auch nicht so toll (Punkt = Multiplikationsfaktor für den niedrigsten Dezimalpreis) und die Hexadezimal-Analogie ist so lahm... Aber vielleicht habe ich hier einen Gewinner...

Logik :
Der Broker muss die Preisrelationen zwischen den Paaren so festlegen, dass MODE_LOTSIZE 100.000 Einheiten der notierten Währung ist und MODE_TICKVALUE 10 Einheiten der notierten Währung ist. Nur durch diese gleiche Bedingung der gegenseitigen Beziehung, kann der Preis untereinander notiert werden. Ich gehe davon aus, dass dies die Grundlage der Forex-Preisbildung ist.

Punkt = MODE_LOTSIZE / Tickwert in notierter Währung. z.B.:
GBPUSD 0.0001 = 100.000 / 10 USD
USDJPY 0,01 = 100.000 / 1.000 JPY <-- MathRound( MODE_TICKVALUE * letzter Bid der notierten Währung )
CHFJPY .... usw., wenn Sie oder jemand kann bestätigen, wäre es toll.

Wenn wir anfangen, über Futures-Kontrakte zu sprechen, sind alle Wetten verloren. FXPro hat zum Beispiel Futures-Kontrakte im fast normalen Format #AAmy, wobei "my" ein Standard-Verfallscode wie M0 ist. EUR_JPY_fut klingt wie ein seltsamer synthetischer Kontrakt.

- Ok Jjc... Ich gehe davon aus, dass Futures auch unterschiedliche Price & TICK_VALUE Gebäude haben. Dies würde also definitiv alle Nicht-Forex-Instrumente ausschließen. Präfixe und Zwischenfixe werden als weniger wahrscheinlich angesehen.

- CB Ich wäre sehr an Ihrer Meinung zu der obigen Berechnung interessiert. Vielen Dank für Ihre bisherige Meinung.

Mit freundlichen Grüßen
cameo

 
cameofx:

- Gordon, meine Definition ist auch nicht so toll (Punkt = Multiplikationsfaktor für den niedrigsten Dezimalpreis) und die Hexadezimal-Analogie ist so lahm... Aber vielleicht habe ich hier einen Gewinner...

Logik :
Der Broker muss die Preisrelationen zwischen den Paaren so festlegen, dass MODE_LOTSIZE 100.000 Einheiten der notierten Währung ist und MODE_TICKVALUE 10 Einheiten der notierten Währung ist. Nur durch diese gleiche Bedingung der gegenseitigen Beziehung, kann der Preis untereinander notiert werden. Ich gehe davon aus, dass dies die Grundlage der Forex-Preisbildung ist.

Punkt = MODE_LOTSIZE / Tickwert in notierter Währung. z.B.:
GBPUSD 0.0001 = 100.000 / 10 USD
USDJPY 0,01 = 100.000 / 1.000 JPY <-- MathRound( MODE_TICKVALUE * letzter Bid der notierten Währung )
CHFJPY .... usw., wenn Sie oder jemand kann bestätigen, wäre es toll.

- Ok Jjc... Ich gehe davon aus, dass Futures auch verschiedene Price & TICK_VALUE Gebäude haben. Dies würde also definitiv alle Nicht-Forex-Instrumente ausschließen. Präfixe & Zwischenfixe werden als weniger wahrscheinlich angesehen.

- CB Ich wäre sehr an Ihrer Meinung zu der obigen Berechnung interessiert. Ich danke Ihnen für Ihre bisherige Meinung.

Mit freundlichen Grüßen
cameo

Würde sich die Logik ändern, wenn Ziffern = 5 oder Ziffern = 3 wären?
 

Habe endlich Anschluss an die Post...

Would the logic change if Digits = 5 or Digits = 3?

Nein, Engcomp, die Logik soll sich nicht ändern. Zumindest ist es das, was ich versuche, herauszufinden.

Ich versuche, mehreren Dingen auf den Grund zu gehen, die Rollen sind bisher : Punkt, MODE_TICKVALUE, MODE_TICKSIZE, Preis. Es könnte sein, dass ich sie am Ende nur in einem neuen Licht darstelle, aber wenn ich sie von dort aus ausnutzen kann, dann wäre es das wert.

IMO, MODE_TICKVALUE umgerechnet in notierte Währung ist sehr wichtig . Der Diskussion halber nenne ich ihn also QUOTE_TICKVALUE. Die vorherige Gleichung ist übrigens rückwärts gerichtet.

Um zu berechnen, ob Point tatsächlich : QUOTE_TICKVALUE (TickValue in notierter Währung) / MODE_LOTSIZE, habe ich dies. (Calc_Point soll mit Point übereinstimmen) 

string Sym = Symbol();
double Calc_Point = QUOTE_TICKVALUE(Sym) / MarketInfo(Sym, MODE_LOTSIZE);
int QUOTE_TICKVALUE(string Sym)
{
   string quoted_currency_name = StringSubstr(Sym,3,3); double TV, QTV = 0.0;
   if (MarketInfo(StringConcatenate("USD", quoted_currency_name), MODE_LOTSIZE)) > 0)
   {
     TV = MarketInfo(Sym, MODE_TICKVALUE);
     QTV = MathRound(TV * MarketInfo(Sym, MODE_BID));
     return(QTV);
   }
   else if ((MarketInfo(StringConcatenate(quoted_currency_name, "USD"), MODE_LOTSIZE)) > 0)
   {
     TV = MarketInfo(Sym, MODE_TICKVALUE);
     QTV = MathRound(TV * MarketInfo(Sym, MODE_BID));
     return(QTV);
   }
}
Hinweis: Für Währungspaare, die in ihrer USD-Form als Basiswährung notiert sind (z.B. EURGBP), müssen die obigen Angaben ein wenig geändert werden.

Zu jedem beliebigen Zeitpunkt, zu jedem beliebigen Preis:

USDJPY, GBPJPY, AUDJPY, XXXJPY............. hat QUOTE_TICKVALUE von --> 1000 [JPY]
EURUSD, AUDUSD, GBPUSD, XXXUSD ........ hat QUOTE_TICKVALUE von --> 10 [USD]
EURCHF, USDCHF, XXXCHF....................... hat QUOTE_TICKVALUE von --> MathPow(10, x) [CHF]

Ich muss betonen, dass ich den QUOTE_TICKVALUE aus dem gleitenden TICK_VALUE "extrahiere". Also ich denke, was dies bedeutet, ist QUOTE_TICKVALUE wird von Broker vorbestimmt & was noch wichtiger ist: sie paralell werden unter jeder Währungen, die als die notierte Währung dienen konsistent sein. So lange MODE_LOTSIZE = 100.000 und USD's QUOTE_TICKVALUE = 10 können wir sicher sein, dass die anderen Symbolkomponenten, die als Kurswährung dienen, auch konsistent sein werden (d.h. Sie können nicht 10 USD zu 1 USD ändern, ohne andere QUOTE_TICKVALUE-s mit 10 zu teilen -- dies ist, glaube ich, wo wir meine Valid_Point im Großen und Ganzen bestimmen können). Ich hoffe, das ist klar...

Ich kann nicht (für das Leben von mir) haben net & MT4 zur gleichen Zeit in diesen Tagen (es ist kompliziert..). Wenn also jemand helfen oder überprüfen kann, wäre es großartig.

cameo

 

Ich habe gefunden, was ich brauche, Valid_Point & noch mehr. Ein tieferes Verständnis für Point, TickValue, Ticksize, Symbol(), & Preis im Allgemeinen. Vielen Dank an alle, die ihre Einsichten und Kommentare geteilt haben, seit LEHayes diesen Thread gestartet hat.

Mit freundlichen Grüßen
cameo

 

Mann, was habe ich für ein Brainstorming verursacht. Ich hoffe, es war nützlich. Ich hatte noch nicht die Zeit, den Thread zu verfolgen, aber ich hoffe, dass ich die Gelegenheit haben werde, ihn zu überprüfen.

Sind wir nach all diesen Diskussionen und der hervorragenden Arbeit an einem Punkt angelangt, an dem wir eine Art Standardfunktion haben, um das zu erzeugen, wonach wir suchen? Diese Frage soll uns zu einer Zusammenfassung bringen.

 

Hat jemand Erfahrung mit den obigen Berechnungstipps für Metalle oder andere Symbole als Crosscurrencies?

Ich habe dieses Thema gefunden, da ich an der Berechnung der Preisänderung in der Kontowährung einer Punktbewegung im Symbol interessiert war.

Meine Grundtheorie war diese:

Preis pro Pip = Kontraktgröße * Punkt

Preis pro Pip in Kontowährung = Preis pro Pip * Kontozähler Crossrate,

wobei

Kontraktgröße = MarketInfo(Symbol(), MODE_LOTSIZE)

Punkt = Punkt = MarketInfo(Symbol(), MODE_POINT)

Account Counter Cross rate ist der Preis der Gegenwährung des Symbols, ausgedrückt in der Währung des Kontos (CCCAAA bid rate, wobei AAA die Kontowährung und CCC die Gegenwährung des Symbols ist).

Ich habe die obigen Ergebnisse mit verschiedenen Broker-Demokonten (icm, insta, fxopen, fxopen ecn) mit den tatsächlichen 1.0 Lot Trades in der Account History verglichen. Ich habe auch die Tickvalue-Berechnungsmethode von Cloudbreaker überprüft.

Ich habe das Folgende gefunden:

- Der Preis für eine Point-Bewegung eines Symbols ist bei verschiedenen Brokern und im Falle von Metallen nicht einfach zu berechnen.

- Sogar die Formel tickvalue * point / ticksize von cloudbreaker kann zu falschen Ergebnissen führen (insta - Silber, icm - eurusd, fxopen - Silber und Gold)

- im Falle von icm - gold führt sogar Contract size * Point zu einem schlechten Ergebnis (0.5 statt der tatsächlichen 5.0, ist das ein Broker-Datenfehler?)

Detaillierte Ergebnisse können Sie hier finden:Preis pro Pip.

Meine Schlussfolgerung ist also, dass es keine 100% sichere Methode zur Berechnung des Preises pro Pip gibt.

 
Danke, dass du dieses kleine Programm, das du geschrieben hast, mit mir geteilt hast. Ich kann nicht glauben, dass es so einfach war!!.. Sie haben mir eine Menge Zeit gespart :-)
engcomp:

Im Anhang finden Sie ein kleines Skript, das ich entwickelt habe und das Ihre Frage beantworten könnte.

Da Skripte keine "externen" Parameter haben, müssen Sie sie im Code ändern und neu kompilieren.

Laden Sie es einfach in den Ordner experts/scripts, kompilieren Sie es und hängen Sie es an ein Diagramm an.

Lassen Sie mich wissen, wie es läuft, Helmut

 
Kommentare zu DE30 beachten
double  PointValuePerLot(string pair=""){
    /* Value in account currency of a Point of Symbol.
     * In tester I had a sale: open=1.35883 close=1.35736 (0.0147)
     * gain$=97.32/6.62 lots/147 points=$0.10/point or $1.00/pip.
     * IBFX demo/mini       EURUSD TICKVALUE=0.1 MAXLOT=50 LOTSIZE=10,000
     * IBFX demo/standard   EURUSD TICKVALUE=1.0 MAXLOT=50 LOTSIZE=100,000
     *                                  $1.00/point or $10.0/pip.
     *
     * https://forum.mql4.com/33975 CB: MODE_TICKSIZE will usually return the
     * same value as MODE_POINT (or Point for the current symbol), however, an
     * example of where to use MODE_TICKSIZE would be as part of a ratio with
     * MODE_TICKVALUE when performing money management calculations which need
     * to take account of the pair and the account currency. The reason I use
     * this ratio is that although TV and TS may constantly be returned as
     * something like 7.00 and 0.0001 respectively, I've seen this
     * (intermittently) change to 14.00 and 0.0002 respectively (just example
     * tick values to illustrate).
     * https://forum.mql4.com/43064#515262 zzuegg reports for non-currency DE30:
     * MarketInfo(Symbol(),MODE_TICKSIZE) returns 0.5
     * MarketInfo(Symbol(),MODE_DIGITS) return 1
     * Point = 0.1
     * Prices to open must be a multiple of ticksize */
    if (pair == "") pair = Symbol();
    return(  MarketInfo(pair, MODE_TICKVALUE)
           / MarketInfo(pair, MODE_TICKSIZE) ); // Not Point.
}
 
Ich habe versucht, den Risikoprozentsatz für Nicht-Devisen-Symbole zu berechnen, aber ich habe nichts gefunden, was auch nur annähernd zuverlässig ist, da sich die meisten Nicht-Devisen-Symbole sehr unterschiedlich verhalten. Hat jemand einen Tipp, wie man den korrekten Pipwert für Nicht-Forex-Symbole berechnet, um einen korrekten Risikoprozentsatz zu ermitteln?
 
Wie funktioniert das oben genannte NICHT richtig?
12345678910
Neuer Kommentar