Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Donc lSL est le nombre de points vers SL
Point = 0.00001 (sur les cotations à 5 chiffres)
dLotStep = 0,01
La formule (lSL*dLotCost*dLotStep))*dLotStep est incorrecte.
Cela devrait être quelque chose comme (lSL*dLotCost*Point))*dLotStep
Tu n'as pas besoin d'inventer quoi que ce soit. La taille du lot est différente pour chaque société de courtage et vous devez l'ajuster à la bonne taille. Les points n'ont rien à voir avec cela
Vous n'avez pas besoin d'inventer quoi que ce soit. La taille du lot est différente dans chaque société de courtage et nous devons l'amener à la bonne taille. Les points n'ont rien à voir avec cela.
Dans notre cas, lSL est la taille du drawdown en points de cotations mais pas en points du lot.En d'autres termes, les points n'ont rien à voir avec cela.
Ainsi, dans la formule de calcul, nous devons multiplier (ce qui est entre parenthèses) par Point, et non par dLotStep.
Une autre chose est que cela est déjà fait aux dépens de dLotCost (avec la conversion en monnaie de dépôt)...
C'est à dire que nous sommes les premiers dans les
Obtenir un nombre entier, puis recalculer en unités correctes du lot en multipliant par dLotStep ?
Il y a aussi une option avec un dépôt de 3 livres pour trader l'EURUSD et mettre 30% sur le côté perdant... mais ceci est hors d'une série de perversions
En ce qui concerne le problème, lSL est la taille du drawdown en points de cotations, et non en points du lot.En d'autres termes, les points n'ont rien à voir avec cela.
Ainsi, dans la formule de calcul, nous devons multiplier (ce qui est entre parenthèses) par Point, et non par dLotStep.
Une autre chose est que cela est déjà fait aux dépens de dLotCost (avec la conversion en monnaie de dépôt)...
C'est-à-dire que nous sommes les premiers à
obtenir un nombre entier, puis recalculer pour revenir aux unités correctes du lot en multipliant par dLotStep ?
Oui
La formule est toujours fausse (pour un bloc de iSL>0).
TICKVALUE donne le prix de TICKSIZE.
Et lSL est donné en points POINT.
LePOINT ne coïncide pas toujours avec le TICKSIZE (voir la paire à 3 chiffres XAUUSD chez Alpari).
Vous devez donc convertir lSL de POINT en TICKSIZE.
Sinon, nous obtiendrons un lot 10 fois surestimé (c'est ce que j'ai observé sur la paire XAUUSD jusqu'à ce que j'ajoute le recalcul).
si (lSL>0){
lSL= (int)(MarketInfo(lSymbol,MODE_TICKSIZE) / MarketInfo(lSymbol,MODE_POINT) )* lSL ; // TICKSIZE/POINT donnera un entier (1 ou 10), nous pouvons utiliser le type int lSL
// Voilà ce que c'était.
PS : pour les CT optimisés pour de nombreuses passes (>10mln) tous les paramètres invariables du symbole(TICKSIZE, POINT, TICKVALUE, LOTSTEP, MINLOT, MAXLOT etc.) doivent être assignés à des variables dans la fonctioninit() et utiliser ces variables dans les calculs.
Notamment en mettant la valeur de TickSize/Point dans une variable.
La formule est toujours fausse (pour un bloc de iSL>0).
TICKVALUE donne le prix de TICKSIZE.
Et lSL est donné en points POINT.
LePOINT ne coïncide pas toujours avec le TICKSIZE (voir la paire à 3 chiffres XAUUSD chez Alpari).
Vous devez donc convertir lSL de POINT en TICKSIZE.
Sinon, nous obtiendrons un lot 10 fois surestimé (c'est ce que j'ai observé sur la paire XAUUSD jusqu'à ce que j'ajoute le recalcul).
si (lSL>0){
lSL= (int)(MarketInfo(lSymbol,MODE_TICKSIZE) / MarketInfo(lSymbol,MODE_POINT) )* lSL ; // TICKSIZE/POINT donnera un entier (1 ou 10), nous pouvons utiliser le type int lSL
// Voilà ce que c'était.
PS : pour les TS qui optimisent de nombreuses passes (>10mln) tous les paramètres non modifiables du symbole(TICKSIZE, POINT, TICKVALUE, LOTSTEP, MINLOT, MAXLOT etc.) doivent être assignés à des variables dans la fonctioninit() et utiliser les variables dans les calculs.
Notamment en mettant la valeur de TickSize/Point dans une variable.
Merci.
Merci
Le topicstarter a envoyé ses respects dès la première page et n'est jamais revenu.
Il y a quelques années, cette question a été discutée sur un forum quelque part. Je vais la raconter de mémoire, mais sans formules.
Supposons que nous négocions la paire AUDCHF. Elle a été prise de manière tout à fait arbitraire afin d'expliquer comment se forment les profits ou les pertes sur une position. Le même sujet a été abordé à https://www.mql5.com/ru/forum/150912.
Si nous négocions un lot unique de 100000 AUD, alors ( sur une base de cinq chiffres) chaque pip fait 1 CHF (dénominateur de la paire) de profit ou de perte (cela dépend de la direction que nous avons prise et de la direction que prend le prix).
Par conséquent, à tout moment, nous savons combien de CHF nous avons gagné/perdu. Le gain/la perte est converti(e) dans la devise du dépôt, en utilisant le taux de change USDCHF du moment, si la devise du dépôt est USD, ou EURCHF, si la devise du dépôt est EUR. Par analogie, pour toutes les paires et les devises de dépôt.
Voici la réponse : nous ne pouvons pas toujours estimer la taille exacte du lot. MarketInfo() avec le paramètre de requête MODE_TICKVALUE peut servir de guide.
D'où la réponse : nous ne pouvons pas toujours estimer la taille exacte du lot. MarketInfo() avec le paramètre de requête MODE_TICKVALUE peut servir de guide.
C'est ainsi qu'il a été comptabilisé pendant longtemps. Au moins dans le bon post de Vinin (avec un calcul de lot erroné pour des TICKSIZE c POINT non concordants) et l'ancien post de Martingeil (avec un calcul de lot correct, mais pas de possibilité de définir drawdown ==0).
L'essentiel est que la valeur correcte de TICKVALUE arrive de la société de courtage (ou soit calculée correctement sur le client, si elle est calculée en MT).
Au début de ce thème, il n'y avait pas de TICKVALUE .
Et avec son avènement, tout s'est simplifié et ce sujet a langui pendant un certain temps.
PS : bientôt je posterai ma version - un hybride de la version de Vinin (elle a une formule plus simple et iSL==0) et de celle de Martingeil (contrôle des fonds insuffisants même pour le lot minimum).
Caractéristiques : 1) calcul du solde à partir de AccountFreeMargin(), et non de AccountBalance().
2) Et (pour les shifters) il est pris en compte que le solde diminuera d'un certain montant lorsqu'une transaction ouverte se ferme sur SL.
S'il n'y a pas assez d'argent, même pour le solde minimum, le volume du lot sera de -134 (erreur 134 - pas assez d'argent pour ouvrir une transaction).
A ce propos, la question à Vinin (et autres camarades expérimentés) : ce code se colore tout seul ou vous le faites vous-même ? J'ai essayé de définir le style du snippet "code", mais cela ne l'a pas coloré. Ou est-ce qu'il n'est coloré qu'après avoir soumis le message ?
Une question pour Vinin (et d'autres camarades expérimentés) : le code se colore-t-il lui-même, ou le colorez-vous vous-même ? J'ai essayé de définir le style du snippet "code", mais il n'est pas coloré. Ou est-ce qu'il n'est coloré qu'après avoir soumis le message ?
j'ai finalisé mon idée (pour les plateformes avec pourcentage de stop-out)... je partage le code... critique constructive acceptée