Communauté d'expertise - page 2
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
Si vous tracez un stop avec une précision d'un pip, le courtier va hurler et couper les Expert Advisors :)
Je pense que c'est mieux :
if (MathAbs(CurrentStopLoss - NewStopLoss) > (Ask - Bid)*Koef) { // Modifier le stop loss ................ }C'est-à-dire que nous modifions l'ordre si le nouveau stop diffère de l'ancien par un nombre donné de spreads (1 - 2).
Votre problème est automatiquement résolu ici.
Seulement ici, le problème est différent - il essaie de définir _à_la_même_valeur_... C'est-à-dire qu'une telle vérification ne sauvera pas de l'erreur, mais réduira seulement sa probabilité =)
C'est très probablement un problème dans le texte de l'EA.
J'en ai eu un semblable, je ne me souviens pas comment il a été réparé.
Mais l'exemple ci-dessus garantit que toute erreur dans le script
il n'y aura pas de tentatives de réglage à la même valeur.
Il s'agit probablement d'un problème dans le texte de l'expert. J'en ai eu un similaire, comment il a été réparé, je ne me souviens pas. Mais l'exemple ci-dessus garantit que toute erreur dans le script ne tentera pas de définir la même valeur.
Mak, il y a 1 ligne de texte =
J'ai écrit la fonction précisément pour éviter de telles erreurs, et le contrôle est le même, à la différence que chaque pépin est travaillé.
Si la valeur est la même (la distance entre le prix et le stop est égale à 50 dans ce cas), les trailing stops ne devraient pas fonctionner.
De plus, dans la plupart des cas, cela ne fonctionne pas =)))), et parfois cela passe à travers pour une raison quelconque .....
Est-ce qu'il arrondit ou rejette ?
D'une manière générale, il est préférable de ne jamais comparer les types flottants pour l'égalité.
La seule exception :
Et sur une ligne ...
Dans _TrailingStop il y a beaucoup de lignes,
et s'il y en a au moins 2, il y a déjà une raison pour des erreurs :)
Je l'ai déjà partiellement corrigé ici : instead
sur
et le reste semblait aller bien :
Renat, je place généralement mes espoirs en vous =) il y a probablement quelque chose d'aussi simple qu'un angle ici - et je ne le remarque pas...
komposter, vous avez tort :) Comme l'a dit la fille qui tordait les cuillères, "les choses ne sont pas ce qu'elles semblent être".
Par exemple, la boucle suivante imprime 5 chiffres :
Combien le prochain cycle imprimera-t-il avec des limites augmentées de 1,0 ?
On s'attendrait à ce qu'il imprime également 5 chiffres, mais il n'en imprime que 4 (quatre). N'est-ce pas génial ?
Si nous ajoutons une autre ligne après la boucle :
Print("d=" + d + "(d <= 1.5)=" + (d <= 1.5)) ;on obtient :
Presque comme le vôtre avec un arrêt, mais plus fondamental :). Le problème est aussi vieux que la première puce d'ordinateur :
Les ordinateurs utilisent l'arithmétique binaire et les humains l'arithmétique décimale. Lors de l'arrondi, des artefacts apparaissent.
"Arrondir vers le haut", ce que Mak a suggéré, aide si vous avez un problème fondamental avec l'arrondi, et non un bug trivial.
De nombreuses personnes pensent que les calculs financiers DOIVENT UTILISER des bibliothèques arithmétiques décimales spéciales, mais même celles-ci peuvent contenir des erreurs, parfois
ce qui peut parfois avoir de graves conséquences. Au fait, Renat, quelle implémentation de l'arithmétique utilisez-vous ?
J'ai jeté un coup d'œil rapide (je n'ai pas encore creusé), j'ai trouvé la référence du point que vous calculez.
Essayez de le "jeter" et de mettre Point. C'est probablement là que réside le problème (le point dans MarketInfo n'aboutit pas toujours à ce que l'on veut ?).