[ARCHIVE]Toute question de débutant, afin de ne pas encombrer le forum. Professionnels, ne passez pas à côté. Je ne peux aller nulle part sans toi - 5. - page 129
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
Je veux que mon conseiller expert achète lorsque le prix est proche du prix du masque + retraiti_thresholdFromMa. Je l'ai écrit de cette façon pour une longue position :
La valeur defastMa est transmise par les paramètres de la fonction. Ensuite, je compare les valeurs du haut et du bas actuels avec la valeur de la course rapidefastMa.
Si la valeur du haut ou du bas est égale à la valeur de la vanne rapidefastMa , alors logiquement un ordre devrait être ouvert au prix (valeur de la vanne rapidefastMa+ décalage par rapport à celle-cii_thresholdFromMa).
La fonction ne fonctionne pas. Quelle en est la raison ? Le conseiller expert n'envoie pas d'erreurs au journal.
Je veux que mon conseiller expert achète lorsque le prix est proche du prix du masque + retraiti_thresholdFromMa. Je l'ai écrit de cette façon pour une longue position :
La valeur defastMa est transmise par les paramètres de la fonction. Ensuite, je compare les valeurs du haut et du bas actuels avec la valeur de la course rapidefastMa.
Si la valeur du haut ou du bas est égale à la valeur de la vanne rapidefastMa , alors logiquement un ordre devrait être ouvert au prix (valeur de la vanne rapidefastMa+ décalage par rapport à celle-cii_thresholdFromMa).
La fonction ne fonctionne pas. Quelle en est la raison ? Le conseiller expert n'envoie pas d'erreurs au journal.
Bonsoir, vous êtes au milieu de la nuit !
Les égalités entre fractions ne seront jamais fixées ! Les ticks vont glisser et il n'y aura pas de signal. C'est pourquoi c'est mieux comme ça :
Je suis d'accord avec Boris, mais j'ajouterais qu'il est préférable de faire toute comparaison de prix de la manière suivante
pas Bid>fastMA mais Bid-fastMA>Zero
Pas High[0]>=fastMA , mais High[0]-fastMA>-Zero , et ainsi de suite :)
Dans la section globale :
#define Zero 0.00000001 , ou quelque chose de similaire.
Je suis d'accord avec Boris, mais j'ajouterais qu'il est préférable de procéder comme suit pour toute comparaison de prix
pas Bid>fastMA mais Bid-fastMA>Zero
Pas High[0]>=fastMA , mais High[0]-fastMA>-Zero , et ainsi de suite :)
Dans la section globale :
#define Zero 0.00000001 , ou quelque chose de similaire.
Alexey et Boris, merci pour vos précieux commentaires.
#define Zero 0.00000001 , Je pense que ce serait très petit :) Je suppose que vous pouvez mettre en toute sécurité un demi-point ici ou un point d'écart...
Alexey et Boris, merci pour vos précieux commentaires.
#define Zero 0.00000001 , Je pense que ce serait très petit :) Je suppose que vous pouvez mettre en toute sécurité un demi-point ici ou un point d'écart...
Essayez de mettre une variable à la place du zéro et c'est ainsi que vous définissez le dégagement nécessaire ! Et vous devriez très probablement le laisser, car sa valeur changera en fonction de l'état du marché.
Oui, s'il existe une variable, nous devons la tester et observer les résultats du marché. En attendant, je l'écris pour l'exécuter dans le testeur et identifier les forces et les faiblesses de mon TS.
C'est ma logique :
J'ai mis 1 à la place du jeu variable pour l'instant pour le test, puis je le déplacerai sur le jeu externe.
Si je comprends bien, ce sera la variante la plus correcte. Si le prix touche ou non la barre, il sera important d'obtenir un signal. Le chandelier a deux extrémités (haut et bas). Cela signifie que nous vérifions par ses 2 extrêmes. C'est pourquoi j'ai écrit que l'écart devait être inférieur à 1.
Mais je me demande si elle s'ouvre à la distance dei_thresholdFromMa(retrait), c'est-à-dire non pas à partir du poignet, mais de l'extrémité de la bougie.
Je vous demanderai de ne pas prêter attention à la condition d'entrée dans la fonction d'ouverture, bien sûr je l'inclurai dans la fonction de signal.
Voici une capture d'écran, par exemple,
La boule rouge est fastMA.i_thresholdFromMa(retrait de l'ondulation) est 5 dans les variables externes. Toutes les autres conditions sont achetées. Ici nous voyons 2 ordres stop bleus sous le fastMa rouge. Je ne vois aucune logique ici. L'ordre est envoyé précisément au prixND(fastMa + i_thresholdFromMa * pt) et je peux le voir dans la fonction donnée...
Oui, si elle est variable, elle doit être testée et observée sur le marché, pour voir quels résultats elle donne. En attendant, j'écris ceci pour l'exécuter dans le testeur et identifier les forces et les faiblesses du TS.
C'est ma logique :
J'ai mis 1 à la place du jeu variable pour l'instant pour le test, puis je le déplacerai sur le jeu externe.
Si je comprends bien, ce sera la variante la plus correcte. Si le prix touche ou non la barre, il sera important d'obtenir un signal. Le chandelier a deux extrémités (haut et bas). Cela signifie que nous vérifions par ses 2 extrêmes. C'est pourquoi j'ai écrit que l'écart devait être inférieur à 1.
Mais je me demande si elle s'ouvre à la distance dei_thresholdFromMa(retrait), c'est-à-dire non pas à partir du poignet, mais de l'extrémité de la bougie.
Je vous demanderai de ne pas prêter attention à la condition d'entrée dans la fonction d'ouverture, bien sûr je l'inclurai dans la fonction de signal.
Voici une capture d'écran, par exemple,
La coche rouge est fastMA.i_thresholdFromMa(retrait de l'ondulation) est 5 dans les variables externes. Dans toutes les conditions, le reste est acheté. Ici nous voyons 2 ordres stop bleus sous le fastMa rouge. Je ne vois aucune logique ici. L'ordre est envoyé exactement au prixND(fastMa + i_thresholdFromMa * pt) et je peux le voir dans la fonction donnée...
Si vous voulez que la position s'ouvre plus tôt, au milieu d'une barre, vous devez spécifier la barre basse pour le Bai et la barre haute pour le Sall.
Si vous voulez que la position s'ouvre plus tôt, au milieu d'une barre, vous devez spécifier la barre basse pour le Bai et la barre haute pour le Sall.
Vous n'avez pas à le faire plus tôt. Je ne sais pas de quel côté la bougie s'approche du masque. En haut ou en bas. C'est la question. C'est pourquoi c'est inapproprié. N'est-ce pas ?
De toute façon, le prix ouvert dans ma fonction OrderSend() est différent et de toute façon il est plus élevé que le masque :
Ici, j'imprime les valeurs de la fonction :
Voici ce que montre le journal :
C'est évident, le prix d'ouverture doit être fixé par moi. Vous êtes en train d'être calculé. Un écart est ajouté à la valeur de la machine. Et vous pouvez le voir dans l'empreinte...
Victor, bien tu as mis le travail du DC, c'est bien qu'il soit virtuel pour le moment ! Pourquoi la commande qui vient d'être passée est-elle supprimée d'un seul coup ? C'est pourquoi nous devons la contrôler en permanence, expérimenter et accumuler progressivement des compétences. Tout TS est ajusté dans le testeur. Si tout est acceptable, vous pouvez utiliser le mode démo et, là encore, obtenir beaucoup d'idées et de variantes. Vous le faites pour vous, c'est donc notre travail quotidien et créatif. Ainsi, vous obtiendrez ce que vous voulez ! Succès !
J'aimerais ajouter que nous n'avons pas besoin de fixer des SL et TP dans les postponies, car nous n'avons pas à nous soucier des sociétés de courtage. Nous n'avons pas besoin de fixer un SL et un TP, nous avons juste besoin de positions. Dans les ordres en attente, il est judicieux de ne modifier que le prix d'ouverture, si nécessaire, et de ne supprimer que pour une bonne raison.