10points 3.mq4 - page 92
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
Bonjour yeoeleven,
Merci pour votre réponse et vos conseils.
Je vais les suivre
Il semble y avoir un bug dans Jugulator pour le calcul de ActualOrders.
Dans mon test, une seule position s'est ouverte pour GBPJPYm à un moment donné. Elle a été fermée en raison de ConfirmedOrders=1 et ActualOrders=2.
Je ne sais pas exactement d'où vient ce problème. Dans le code, ActualOrders semble toujours augmenter de 1 lorsqu'un ordre est envoyé. Si le SendOrder échoue (pour diverses raisons), ActualOrders augmente toujours de 1. Peut-être est-il préférable de vérifier l'erreur de SendOrder. S'il n'y a pas d'erreur, alors ActualOrders augmente de 1.
Merci !Cela devrait être corrigé ici (Page 89, post 890, Jugulator.zip). Il y a une nouvelle variable dans l'EA qui est définie par le numéro de l'ordre. Si l'ordre échoue, il ne devrait pas y avoir de numéro d'ordre et le code vérifie cela avant d'incrémenter la variable ActualOrders.
void OrderNeedsOpening() {
//Préservez les valeurs avant de les modifier
double TempActualLotSize = ActualLotSize ;
//Augmente la taille du lot
ActualLotSize = NormalizeDouble(ActualLotSize * LotsIncreaseBy, LotPrecision) ;
//Est-ce que nous essayons d'être long ?
if (OrderDirection == 1) {
//Définir le Take Profit et ouvrir un ordre Long
ActualTP = Ask + (TakeProfit * Point) ;
LastTicket = OrderSend(Symbol(), OP_BUY, ActualLotSize, Ask, OrderSlippage, ActualSL, ActualTP, "Order" + (ActualOrders + 1), Magic, 0, Blue) ;
}
//Est-ce que nous essayons d'être short ?
else if (OrderDirection == 2) {
//Définir le Take Profit et ouvrir un ordre Short
ActualTP = Bid - (TakeProfit * Point) ;
LastTicket = OrderSend(Symbol(), OP_SELL, ActualLotSize, Bid, OrderSlippage, ActualSL, ActualTP, "Order" + (ActualOrders + 1), Magic, 0, Red) ;
}
//Si l'ordre a été exécuté, il sera supérieur à 0.
if (LastTicket > 0) {
ActualOrders++ ;
}
//La commande a échoué, nous devons donc rétablir la valeur.
else {
ActualLotSize = TempActualLotSize ;
}
}
Le code que vous utilisez reflète-t-il ce changement ? C'est ce que j'utilise et je n'ai aucun problème à ouvrir plusieurs ordres et à les fermer alors qu'ils devraient être TP ou SL. Notez que ce type de changement se trouve également dans d'autres parties du code, donc copier et coller cette section seule ne résoudra pas le problème.
Résultats du Jugulator H4
Voici les résultats 0.10 et 0.01 pour ce matin.
Résultats du Jugulator H4
Voici les résultats des comptes 0.10 et 0.01 pour ce matin à 10h EST après plusieurs nouvelles importantes.
Le compte 0.01 a augmenté de 268,94 $.
Le compte 0.10 a augmenté de 1 912,44 $.
10points3 Dynamic Stop
Fermé pour la semaine 10points3 Dynamic Stop. Fermeture des paires lorsqu'elles deviennent rentables. Paramètres précédemment postés
Une bonne semaine dans l'ensemble.
J'attends toujours que l'USDJPY se retrace avant de fermer le Jugulator.
John
Jugulator1.1
Dans la continuité des réglages du post #891 et des résultats précédents du post #898. Voici le relevé détaillé après la fermeture pour la semaine.
Je regarderai les paramètres avant l'ouverture lundi et me rapprocherai probablement de ceux de Matt puisqu'ils sont clairement meilleurs que les miens.
John
Cela devrait être corrigé ici (Page 89, post 890, Jugulator.zip). Il y a une nouvelle variable dans l'EA qui est définie par le numéro de l'ordre. Si l'ordre échoue, il ne devrait pas y avoir de numéro d'ordre et le code vérifie cela avant d'incrémenter la variable ActualOrders.
void OrderNeedsOpening() {
//Préserver les valeurs avant de les modifier
double TempActualLotSize = ActualLotSize ;
//Augmente la taille du lot
ActualLotSize = NormalizeDouble(ActualLotSize * LotsIncreaseBy, LotPrecision) ;
//Est-ce que nous essayons d'être long ?
if (OrderDirection == 1) {
//Définir le Take Profit et ouvrir un ordre Long
ActualTP = Ask + (TakeProfit * Point) ;
LastTicket = OrderSend(Symbol(), OP_BUY, ActualLotSize, Ask, OrderSlippage, ActualSL, ActualTP, "Order" + (ActualOrders + 1), Magic, 0, Blue) ;
}
//Est-ce que nous essayons d'être short ?
else if (OrderDirection == 2) {
//Définir le Take Profit et ouvrir un ordre Short
ActualTP = Bid - (TakeProfit * Point) ;
LastTicket = OrderSend(Symbol(), OP_SELL, ActualLotSize, Bid, OrderSlippage, ActualSL, ActualTP, "Order" + (ActualOrders + 1), Magic, 0, Red) ;
}
//Si l'ordre a été exécuté, il sera supérieur à 0.
if (LastTicket > 0) {
ActualOrders++ ;
}
//La commande a échoué, nous devons donc rétablir la valeur.
else {
ActualLotSize = TempActualLotSize ;
}
}
Le code que vous utilisez reflète-t-il ce changement ? C'est ce que j'utilise et je n'ai aucun problème à ouvrir plusieurs ordres et à les fermer alors qu'ils devraient être TP ou SL. Notez que ce type de changement se trouve également dans d'autres zones du code, donc copier et coller cette section seule ne résoudra pas le problème.La version que je teste ne contient pas la modification ci-dessus. Je vais utiliser la version la plus récente. Merci mtaboneweb !
Je continue à tester le Dynamic Stop 10points3 et j'obtiens toujours de bons résultats.
J'ai supprimé le GBPUSD hier dans un effort pour rendre cet EA sûr pour les petits comptes ; cela a probablement réduit la rentabilité mais, espérons-le, augmenté la sécurité.
JohnUtilisez-vous toujours le Dynamic Stop 10points3 original qui se trouve à la page 18 ?
Merci
10points3 Dynamic Stop
Utilisez-vous toujours la version originale de 10points3 Dynamic Stop qui se trouve à la page 18 ? Merci.
Oui, c'est la version que je teste toujours avec Goblin et Jugulator. Elle tient toujours la route avec ces EAs qui ont été développés à partir d'elle.
John
tf
1. Attendez la barre : Actuellement, l'EA ouvre de nouveaux ordres dans un cycle de niveaux de pip cohérents. Une approche alternative serait de s'assurer que les nouveaux ordres ne sont pas ouverts dans la même barre. Ainsi, si vous avez un très grand mouvement, l'EA attendrait jusqu'à la clôture de la barre, réévaluerait la tendance, puis placerait un autre ordre dans le cycle si la valeur du pip est supérieure à celle spécifiée dans le paramètre de pips de l'EA.
.1 - .2 - .3 - .5 - .8 - 1.3 - 2.1 - 4.4 - 6.5 - etc.
Ceci a été posté par Stockwet dans le fil de discussion sur les gobelins. idée très intéressante mais au lieu de reprendre là où les ordres se sont arrêtés, il faut sauter les ordres qui ont été passés et passer à l'incrément suivant. ainsi, si le prix a augmenté rapidement, vous n'avez des pertes que sur ce que vous avez sur le tableau. disons qu'après 3 incréments de prix, le prix s'envole de 40 pips sur une barre de 15 minutes. Lorsque la barre est terminée, l'application vérifie quel est le nombre d'ordres à mettre en œuvre et commence à partir de là avec le nombre correct de lots. Ainsi, l'ordre n° 4 pourrait être en fait 2,1 lots au lieu de 0,5 lot. De cette façon, vos 2,1 lots pourraient compenser les pertes que l'ordre normal suivant (.5), ne pourrait pas faire s'il était lancé à ce point particulier du prix. votre ordre de 2,1 lots devient maintenant l'ordre n° 4 et progresse à partir de là. Cela ne réduirait pas les pertes si la progression allait jusqu'à 10, mais permettrait à la progression d'aller plus loin avant la fermeture, vous donnant ainsi une meilleure chance de récupérer. Ou les transactions pourraient être fermées s'il est déterminé que la tendance a changé pour une perte plus petite que celle qui aurait été normalement encourue. Serait-ce une idée réalisable ? ??