League of Trading Systems. Continuez à faire du bon travail. - page 192
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
Pourquoi n'est-il pas autorisé ? Quelle est la fonction exacte qui empêche une transaction de se clôturer avec une perte de 0,8 de la fourchette d'un jour, s'il se trouve que le trilling TP "rattrape" le prix dans exactement ces conditions ?
Je me suis mal exprimé.
Ce que je voulais dire, c'est qu'après une perte de 0,8 jour - après 6 transactions, il devrait y avoir un retrait de la transaction parce que nous attendons trop longtemps pour une mise à jour élevée.
C'est dur pour toi... :-)
C'est possible qu'il y ait après un coup sur l'équité et la hausse !!!?!!!!
Si ça commence à baisser, oui. Bien que, bien sûr - vous le savez mieux que quiconque... Nous continuerons à regarder...
Possible.
Mais, deux années de suite, cela ne s'est pas produit. Est-ce que nous attendons un "vol vers le haut" ? ?? C'est certainement possible, mais la probabilité d'une "fuite" est plus grande, à mon avis.
Je me suis mal exprimé.
Ce que je voulais dire, c'est qu'après une perte de 0,8 jour de fourchette - après 6 transactions, il devrait y avoir un retrait de la transaction parce que nous attendons trop longtemps une mise à jour élevée.
Exactement.
Considérons l'exemple 643642. Pendant l'optimisation, il n'a pas subi de perte significative (aucune perte supérieure à 0,6 gamme).
Pendant le trading, des pertes supérieures à 0,6 peuvent facilement se produire (comme on peut le voir dans le drawdown sur les ticks réels). Ainsi, en cas de perte supérieure à 0,6, vous privez le TS d'une chance de regagner sa place. Et ce n'est pas logique, ce que l'on peut constater à nouveau dans la course aux ticks réels. Cette perte ne signifie pas que le système a cessé de gagner de l'argent, il n'a simplement pas été modélisé sur OHLC. Il s'avère que dès que le TS réalise une perte significative, il sera automatiquement retiré du marché pour cause de non-renouvellement du maximum.
IMHO. Nous devrions d'une manière ou d'une autre diviser la marche du TC dans un endroit et son rétablissement après une perte. Par exemple, en introduisant le critère de la rentabilité moyenne de n-trades.
Vous n'êtes toujours pas d'accord sur le fait que le contrôle après optimisation utilisant des ticks réels peut être utile pour comprendre les aspects latents du comportement du TS ?
Exactement.
Considérons l'exemple 643642. Pendant l'optimisation, il n'a pas subi une seule perte significative (aucune perte supérieure à 0,6 gamme).
Pendant le trading, des pertes supérieures à 0,6 peuvent facilement se produire (comme on peut le voir dans la course sur les ticks réels). Ainsi, en cas de perte supérieure à 0,6, vous privez le TS d'une chance de regagner sa place. Et ce n'est pas logique, ce que l'on peut constater à nouveau dans la course aux ticks réels. Cette perte ne signifie pas que le système a cessé de gagner de l'argent, il n'a simplement pas été modélisé sur OHLC. Il s'avère que dès que le TS réalise une perte significative, il sera automatiquement retiré du marché pour cause de non-renouvellement du maximum.
Le système doit être retiré du commerce car il n'est pas modélisé.
La principale raison pour laquelle le système a été retiré du marché : le système ne se comporte pas comme il s'est comporté dans l'historique. Peu importe la raison : soit un élément n'a pas été pris en compte lors des tests, soit le marché a changé, soit une erreur a été commise dans l'algorithme.
Si la perte, qui a conduit à la suppression du système du commerce, est accidentelle, le système sera réoptimisé en un jour, et les résultats de la réoptimisation seront certainement meilleurs que ceux d'un commerce réel, et il commencera immédiatement à montrer le même résultat que précédemment. Et la division n'a pas d'importance, le script qui recueille les statistiques pour le rapport - les recueille immédiatement pour toutes les divisions, mais, bien sûr, que dans le haut obtenir seulement le TS de la division supérieure, parce que dès que le TS de la division moyenne ou inférieure commence à montrer la qualité du commerce dans la division supérieure - il transfère immédiatement à elle.
C'est-à-dire que si ce TS est si cher pour toi, Edward, alors le maximum que tu perdes est de 10 affaires. Étant donné qu'il s'agit d'un "six", chacune de ses transactions est très petite. J'essaierai de ne pas oublier de prévenir les intéressés lorsque, après une sur-optimisation, le TS passera directement en première division.
Il y a actuellement 90 CTs opérant dans la division supérieure.
Selon moi, il est nécessaire de faire une distinction entre le fait de piétiner un endroit et la récupération après une perte. Par exemple, en introduisant un critère de rentabilité moyenne pour n-trades.
N'est-ce pas séparé ?
Ecoutez, nous avons passé deux années entières à tester le fonctionnement du système. Et nous prenons la plus longue période de récupération. Si le TS met plus de temps à se rétablir dans les échanges réels, c'est un signe clair que le TS ne fonctionne pas comme prévu (encore une fois, la raison ne nous importe pas).
Vous n'êtes toujours pas d'accord sur le fait que les tests de post-optimisation sur des ticks réels peuvent être utiles pour comprendre les aspects cachés du comportement des CT ?
Je n'en vois pas l'intérêt. Après tout, ce qui était là ne le sera plus jamais.
Cependant, personne ne vous empêche de le faire vous-même. Tout TC sans restrictions fonctionne dans le testeur sans aucun code d'enregistrement.
Que dit le journal à propos de ce code ? Invalide ? ??
J'ai vérifié - tout semble fonctionner...
Je pense que ce n'est pas le code d'enregistrement.Je suis là.
voici le crash.
il est écrit "code d'enregistrement".
Compte : 2599118
Magie : 542041
Code d'enregistrement : 3265001878
mettre
avec l'arrivée du tic, c'est parti...
voici le journal
Roman, c'est jurer sur la magik. 542041 a une date de construction de 12.06.2019 Votre exécutable a une date de juin. Ma supposition : lorsque cet exécutable a été créé, il n'y avait pas encore de 542041.
Prenez un module plus récent, ça devrait marcher.
Je n'en vois pas l'intérêt. Après tout, ce qui était là ne le sera plus jamais.
Dans ce cas, quel est l'intérêt d'optimiser l'histoire ?
Si c'était techniquement possible (en termes de temps), j'optimiserais tout uniquement sur les ticks réels.