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
3 personnes regardaient =)) Renat est venu et a juste pointé son doigt sur l'erreur =))))
Je vais vérifier maintenant, bien sûr, mais c'est probablement le problème... Je n'ai pas normalisé "bid - TrailingStop * point", et cette construction même est impliquée dans la modification de l'ordre...
Nous ne sommes pas attentifs, messieurs ;)
Plusieurs personnes vous ont donc proposé cette variante du problème. J'ai même écrit que l'offre peut avoir 5 décimales. J'ai d'abord pensé que ce n'était pas possible, puis je me suis souvenu que les citations sont faites par un automate qui prend probablement des citations de plusieurs flux de données et en fait la moyenne en utilisant une sorte d'algorithme.
. Les symboles Bid/Ask ont une précision standard sans ambiguïté. Par ailleurs, au lieu de 1,6666, vous pouvez voir 1,6665999 (en raison d'une erreur de virgule flottante).
Je tiens à noter que les problèmes de comparaison de ces nombres(type double) existent dans _tous_ les langages et sont une conséquence de la précision limitée de base de ce type d'arithmétique. Par conséquent, il ne faut pas blâmer qui que ce soit, mais être conscient du problème et écrire du code protégé.
L'offre et la demande sont clairement d'une précision de caractère standard. Une autre chose est qu'au lieu de 1.6666, on peut voir 1.6665999 (en raison des particularités de l'erreur de virgule flottante).
Je tiens à noter que les problèmes de comparaison de ces nombres (type double) existent dans _tous_ les langages et sont une conséquence de la précision limitée de base de ce type d'arithmétique. En conséquence, vous ne devez blâmer personne, mais être conscient du problème et écrire du code sécurisé.
Donc je n'accuse personne. Je n'ai pas demandé à komposter pour rien - sur laquelle monnaie le trailing n'a pas fonctionné correctement. Je me souviens avec certitude que dans MT3 vous pouvez voir 3 décimales en Yen. En tout cas, je l'ai vu plus d'une fois.
nous ne sommes pas attentifs, messieurs ;)
la normalisation n'a pas aidé =(
plus précisément - erreurs de suivi (euro - position d'achat) :
03:41
12:07
12:11
14:31
14:33
14:36
14:39
14:44
14:46
14:47
14:48
(heure du serveur)
Renat, comment dois-je procéder ?
Pour le moment, il y a 3 options :
1. if ( orderstoploss < ( bid - TrailingStop * point ) ) remplacé par if ( TrailingStop < ( bid -orderstoploss) / point )
2. Comparer int, pas double, en utilisant les fonctions Begun
3. Modifier l'avance du stop ( pas à chaque point, mais après n spreads)
et leurs combinaisons, bien sûr.
Comme le logiciel est assez responsable, j'aimerais obtenir ( ! pas une garantie !) des recommandations pour écrire...
Essayez plutôt :
écrire :
Y aura-t-il aussi des erreurs ?
Il est clair que vous pouvez faire un retour de bâton, mais ce n'est pas sérieux..... Et si je dois faire un contrecoup de 10-20 pips, "pour la fiabilité", oui, sur M30, juste un conte de fées =)
Veuillez revérifier votre code, le simplifier, insérer des messages de débogage.
Pour être honnête, je ne sais pas comment le simplifier...
Mais vous pouvez le vérifier, bien sûr. Voici le code tel qu'il est utilisé maintenant (en partie) :
vérifier les paramètres entrants et sélectionner l'ordre requis. Si une erreur se produit, nous sortons simplement, c'est-à-dire que l'ordre ne sera pas modifié...
Sauvegarder toutes les données de la commande dans des variables et les normaliser :
voici la couleur et la "beauté" de la bûche...
maintenant, pour une position longue, définir un nouveau niveau SL, le normaliser et le comparer avec l'ancien (seulement si la position est rentable).
le mettre dans le journal
une triple tentative de modification de l'ordre après une pause de 10 secondes (l'ordre est mis en évidence à chaque fois)
et seulement si ordermodify <= 0 un code d'erreur est envoyé
si après 3 essais l'ordre n'a pas été modifié, nous sortons (-1)
puis la même chose pour les positions de vente
et enfin, s'il n'y a pas besoin de modifier le stop, exit(0)
ne sait pas....
Qu'est-ce que ça a à voir avec ça ? "+Point" résout le problème de l'arrondi du dernier chiffre significatif du prix. Nous ne parlons pas de 2, 3, et encore moins de 10-20 pips.