Prix par tuyau - page 9

Nouveau commentaire
 
gordon:

Ma définition perd son sens initial lorsqu'elle est citée hors contexte. Pour clarifier, le mot "prix" dans la définition de MODE_TICKSIZE fait référence aux cotations de prix réelles possibles , alors que dans la définition de Point, il fait référence à n'importe quel prix.

- Gordon, ma définition n'est pas terrible non plus (Point = facteur multiplicateur pour le prix décimal le plus bas) et l'analogie hexadécimale est tellement boiteuse... Mais j'ai peut-être un gagnant ici...

Logique :
Le courtier a besoin d'établir des relations de prix entre les paires pour tourner autour de MODE_LOTSIZE qui est de 100.000 unités de la devise cotée et MODE_TICKVALUE qui est de 10 unités de la devise cotée. Ce n'est que par cette condition égale d'inter-relation que les prix peuvent être cotés entre eux. Je suppose que c'est la base de la construction des prix du forex.

Point = MODE_LOTSIZE / Tickvalue en devise cotée. ex :
GBPUSD 0.0001 = 100,000 / 10 USD
USDJPY 0.01 = 100,000 / 1,000 JPY <-- MathRound( MODE_TICKVALUE * dernier Bid de la devise cotée )
CHFJPY .... etc. Si vous ou quelqu'un peut confirmer, ce serait formidable.

Les jeux sont faits si nous commençons à parler de contrats à terme. Par exemple, FXPro propose des contrats à terme au format quasi normal #AAmy où "my" est un code d'expiration standard tel que M0. EUR_JPY_fut sonne comme un contrat synthétique bizarre.

- Ok Jjc... Je suppose que les futurs contrats ont aussi des prix et des valeurs TICK_VALUE différents. Donc, cela exclut définitivement tous les instruments non-forex. Les préfixes et les in-between-fixes sont considérés comme moins probables.

- CB Je serais très intéressé d'entendre votre opinion sur le calcul ci-dessus. Merci pour votre opinion jusqu'à présent.

meilleures salutations
cameo

 
cameofx:

- Gordon, ma définition n'est pas terrible non plus ( Point = facteur multiplicateur pour le prix décimal le plus bas ) et l'analogie hexadécimale est tellement boiteuse... Mais j'ai peut-être un gagnant ici...

Logique :
Le courtier a besoin d'établir des relations de prix entre les paires pour tourner autour de MODE_LOTSIZE qui est de 100.000 unités de la devise cotée et MODE_TICKVALUE qui est de 10 unités de la devise cotée. Ce n'est que par cette condition égale d'inter-relation que les prix peuvent être cotés entre eux. Je suppose que c'est la base de la construction des prix du forex.

Point = MODE_LOTSIZE / Tickvalue en devise cotée. ex :
GBPUSD 0.0001 = 100,000 / 10 USD
USDJPY 0.01 = 100,000 / 1,000 JPY <-- MathRound( MODE_TICKVALUE * dernier Bid de la devise cotée )
CHFJPY .... etc. Si vous ou quelqu'un peut confirmer, ce serait formidable.

- Ok Jjc... Je suppose que le futur a aussi des constructions différentes de Price & TICK_VALUE. Cela exclut donc définitivement tous les instruments non-forex. Les préfixes et les in-between-fixes sont considérés comme moins probables.

- CB Je serais très intéressé d'entendre votre opinion sur le calcul ci-dessus. Je vous remercie de votre opinion jusqu'à présent.

meilleures salutations
cameo

La logique changerait-elle si Chiffres = 5 ou Chiffres = 3 ?
 

J'ai enfin une connexion pour poster...

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

Non engcomp, la logique n'est pas censée changer. Du moins, c'est ce que j'essaie de comprendre.

J'essaie d'aller au fond de plusieurs choses, les cas sont jusqu'à présent : Point, MODE_TICKVALUE, MODE_TICKSIZE, Prix. Il se peut que je finisse par ne les présenter que sous un jour nouveau, mais si je peux les exploiter à partir de là, cela en vaudra la peine.

IMO, MODE_TICKVALUE converti en devise cotée est très important . Pour les besoins de la discussion, je l'appellerai donc QUOTE_TICKVALUE. L'équation précédente est d'ailleurs inversée.

Pour calculer si Point est effectivement : QUOTE_TICKVALUE (TickValue en devise cotée) / MODE_LOTSIZE, j'ai ceci. (Calc_Point est censé correspondre à Point) 

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);
   }
}
Remarque : pour les paires croisées dont la devise cotée est la base de leur forme en USD (par exemple EURGBP), les points ci-dessus devront être légèrement modifiés.

Donc, à tout moment, à tout prix donné:

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

Je dois souligner que j'extrais QUOTE_TICKVALUE du TICK_VALUE flottant. Je pense donc que cela signifie que QUOTE_TICKVALUE est prédéterminé par le courtier et ce qui est plus important, c'est qu'il sera parallèlement cohérent entre chaque devise qui sert de devise cotée. Ainsi, tant que MODE_LOTSIZE = 100 000 et QUOTE_TICKVALUE = 10 pour USD, nous pouvons être sûrs que les autres composants du symbole qui servent de devise de cotation seront également cohérents (c'est-à-dire que vous ne pouvez pas changer 10 USD en 1 USD sans diviser les autres QUOTE_TICKVALUE-s par 10 également - je crois que c'est là que nous pouvons déterminer mon Valid_Point au sens large). J'espère que c'est clair...

Je ne peux pas (sur ma vie) avoir net & MT4 en même temps ces jours-ci (c'est compliqué..). Donc si quelqu'un peut aider ou vérifier, ce serait génial.

camée

 

J'ai trouvé ce dont j'avais besoin, Valid_Point et même plus. Une compréhension plus approfondie de Point, TickValue, Ticksize, Symbol(), et du prix en général. Merci à tous ceux qui ont partagé leurs idées et leurs commentaires depuis que LEHayes a lancé ce fil de discussion.

Meilleures salutations
camée

 

Mec, regarde tout le remue-méninges que j'ai provoqué. J'espère que c'était utile. Je n'ai pas eu le temps de suivre le fil de discussion, mais j'espère avoir l'occasion de le revoir.

Après toutes ces discussions et cet excellent travail, sommes-nous arrivés à un point où nous avons une sorte de fonction standard pour générer ce que nous recherchons ? Cette question a pour but de nous amener à un résumé.

 

Quelqu'un a-t-il une expérience avec les conseils de calcul ci-dessus sur les métaux ou d'autres symboles que les devises ?

J'ai trouvé ce sujet car je m'intéressais au calcul du changement de prix dans la devise du compte d'un mouvement de point dans le symbole.

Ma théorie de base était la suivante :

Prix par pip = Taille du contrat * Point

Prix par pip dans la devise du compte = Prix par pip * Taux de croisement du compteur du compte,

où

Taille du contrat = MarketInfo(Symbol(), MODE_LOTSIZE)

Point = Point = MarketInfo(Symbol(), MODE_POINT)

Account Counter Cross rate est le prix de la contre devise du symbole exprimé dans la devise du compte (CCCAAA bid rate où AAA est la devise du compte et CCC la contre devise du symbole).

J'ai vérifié ce qui précède avec les comptes de démonstration de différents courtiers (icm, insta, fxopen, fxopen ecn) par rapport aux transactions réelles de 1,0 lot dans l'historique du compte. J'ai également vérifié la méthode de calcul de la tickvalue de cloudbreaker.

J'ai trouvé ce qui suit :

- Le prix du mouvement d'un point d'un symbole n'est pas facile à calculer avec différents courtiers et dans le cas des métaux.

- même la formule tickvalue * point / ticksize de cloudbreaker peut conduire à de faux résultats (insta - argent, icm - eurusd, fxopen - argent et or)

- dans le cas de icm - gold, même Contract size * Point conduit à un mauvais résultat (0.5 au lieu de 5.0, est-ce une erreur de données du courtier ?)

Vous pouvez trouver des résultats détaillés ici :Prix d'un point.

Ma conclusion est donc qu'il n'y a pas de méthode de calcul du prix par point fiable à 100%.

 
Merci d'avoir partagé ce petit programme que vous avez écrit. Je n'arrive pas à croire que c'était si facile ! vous m'avez fait gagner beaucoup de temps :-)
engcomp:

Vous trouverez ci-joint un petit script que j'ai développé et qui pourrait répondre à votre question.

Comme les scripts n'ont pas de paramètres "externes", vous devez les modifier dans le code et recompiler.

Il suffit de le charger dans votre dossier experts/scripts, de le compiler et de le joindre à un graphique.

Faites-moi savoir comment ça se passe, Helmut.

 
Commentaires sur la note DE30
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.
}
 
J'ai essayé de calculer le pourcentage de risque sur les symboles non-forex, mais je n'ai pas réussi à trouver quelque chose qui soit un tant soit peu fiable car la plupart des symboles non-forex se comportent très différemment. Quelqu'un a-t-il des indications sur la façon de calculer la valeur correcte des pip sur les symboles non-forex afin de calculer un pourcentage de risque correct ?
 
Comment ce qui précède ne fonctionne PAS correctement ?
12345678910
Nouveau commentaire
Raison: