Algorithmes, méthodes de résolution, comparaison de leurs performances - page 22
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
Mis à jour en 2269. Résultats du profileur d'une grande EA (non synthétique).
Testeur
Virtual
Probablement, le profileur fait de mauvaises mesures. Sinon, il s'avère que OrderSend five prend 912 ms en moyenne.
Tous les doublets normalisés par le même algorithme (par exemple via NormalizeDouble) peuvent être comparés entre eux directement.
Ce fait évident permet d'éviter les constructions coûteuses de comparaison de nombres réels dans de nombreux cas. Ce qui, dans certaines tâches, peut augmenter considérablement les performances.
L'une des tâches les plus exemplaires est peut-être celle de Testeur. Analysons-la par l'exemple.
Il y a une BuyLimit. A chaque tick, le testeur doit comparer la BuyLimit avec le prix Ask. Le testeur standard procède de cette manière pour le moment
C'est-à-dire que tout niveau de transaction(ordre en suspens ou SL/TP) déclenche une normalisation.
Mais nous pouvons toujours nous en sortir avec une construction de comparaison très efficace si les prix ont été normalisés au préalable (avant le backtest).
if (BuyLimit_Price >= Ask) BuyLimit -> Buy;
Essayons une comparaison. J'ai fait tourner ce robot dans Tester via Virtual.
Comparaison des prix par la normalisation.
Sans normalisation.
Nous pouvons voir que le gain est supérieur à 20% si nous ne faisons pas de normalisation lors de la comparaison des prix.
Par conséquent, si le testeur interne passe aux prix normalisés et n'effectue pas de normalisation interne lors de la comparaison des prix, il est possible d'obtenir une sérieuse amélioration des performances.
Après une affectation directe sans mat. les opérations
Le préfixe, bien sûr, copie la représentation en octet du nombre sans modification.
Devrions-nous effectuer un test de plus d'une seconde pour plus de clarté ?
Il y a un écart de 3 temps dans une version : passage le plus court 0:00:00.604, passage le plus long 0:00:01.743. Que comparons-nous ?
Peut-être faire un test de plus d'une seconde pour plus de clarté ?
Il y a un écart de 3 temps dans une version : passage le plus court 0:00:00.604, passage le plus long 0:00:01.743. Que comparons-nous ?
En comparant le plus court, bien sûr. J'ai l'habitude de courir sur des ticks filtrés. Je préparerai les non filtrés plus tard.
En comparant le plus court, bien sûr.
Pourquoi ? L'optimisation ne consiste pas en un seul passage. Quelle différence cela fait-il qu'un passage soit si rapide, si la moyenne n'est pas très différente ?
J'ai l'habitude de courir sur des ticks filtrés. Je préparerai les non filtrés plus tard.
Je peux juste faire un intervalle plus long. Au moins 30 secondes pour le test.
Pourquoi ? Ce n'est pas comme si l'optimisation consistait en un seul passage. Quelle différence cela fait-il qu'un passage soit si rapide, si la moyenne n'est pas très différente ?
Ce paramètre est optimisé.
Et cela n'affecte pas la logique. C'est pourquoi il est le plus court.
Ce paramètre est optimisé
Et cela n'affecte pas la logique. C'est pour ça que c'est le plus court.
Qu'est-ce que la logique d'EA a à voir avec ça ? Nous mesurons la vitesse du testeur.
Qu'est-ce que la logique de l'EA a à voir avec ça ? Nous mesurons la vitesse du testeur.
C'est ainsi qu'un agent fonctionne, il compte consécutivement la même chose. Si vous enlevez tout le caractère aléatoire, la performance nette est proche de la plus courte.