L'optimisation dans le testeur de stratégie - page 8
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
L'exécution du test de l'exemple ci-dessus entraîne une surcharge du système d'environ 1,5 seconde au démarrage pour préparer toutes les données (autorisation et synchronisation des données de calcul). Le fait est que les agents de test sont complètement indépendants et découplés du terminal, ce qui entraîne la nécessité de transférer et de synchroniser entièrement toutes les données utilisées.
On ne peut pas dire que l'optimiseur ou le testeur génétique soit lent à effectuer des calculs ultrarapides en quelques secondes, car la surcharge du système a une grande influence sur le temps de calcul final. Dans les longs calculs de 20 secondes ou plus par exécution, l'impact de la surcharge du système est réduit à des valeurs négligeables.
À chaque construction, nous réduisons ce temps en mettant en cache la plupart des données directement dans les agents. Je pense que nous allons bientôt résoudre ce problème.
GA de joo est déjà plus rapide que le standard, et lors du transfert du code vers CPP par Studio 10 (adapté aux CPU multi-cœurs) l'accélération est encore 6 fois plus rapide.
C'est sans environnement de marché que l'on peut disposer d'un calculateur de vitesse personnalisé pour une tâche spécifique.
Mais si l'on essaie de créer un moteur de négociation universel fournissant à la demande des données de poti multidevises avec calcul automatique des profits/limites et rapports, la vitesse diminuera immédiatement de 2 à 4 ordres de grandeur.
L'exécution de tests sur l'exemple ci-dessus entraîne une surcharge du système d'environ 1,5 seconde au début pour préparer toutes les données (autorisation et synchronisation des données de calcul). Le fait est que les agents de test sont complètement indépendants et découplés du terminal, ce qui entraîne la nécessité de transférer et de synchroniser entièrement toutes les données utilisées.
On ne peut pas dire que l'optimiseur ou le testeur génétique soit lent à effectuer des calculs ultrarapides en quelques secondes, car la surcharge du système a une grande influence sur le temps de calcul final. Dans les longs calculs de 20 secondes ou plus par exécution, l'impact de l'overhead du système est réduit à des valeurs négligeables.
À chaque construction, nous réduisons ce temps en mettant en cache la plupart des données directement dans les agents. Je pense que nous allons bientôt résoudre ce problème.
Sans environnement de marché, il est possible de mettre en place un compteur rapide personnalisé pour une tâche spécifique.
Mais si l'on essaie de créer un moteur de négociation universel fournissant à la demande des données multidevises avec calcul automatique des profits et des limites et établissement de rapports, la vitesse diminuera immédiatement de 2 à 4 ordres de grandeur.
Renat, je ne veux pas dire qu'il faut du temps pour préparer l'environnement du marché et d'autres "freins" inévitables, j'ai écrit à la page précédente :
Il est fort probable qu'une différence aussi monstrueuse soit due au fait que le testeur, en plus des calculs directs FF, doit écrire des journaux, afficher des informations, etc. qui sont présents "freinage forcé".
2010.11.28 17:38:30 Core 1 genetic pass (424, 98130899813578) a retourné le résultat 48.16 en 2059 ms
2010.11.28 17:38:30 Core 2 genetic pass (426, 990006720) démarré
2010.11.28 17:38:30 core 2 genetic pass (425, 56291461) returned result 26.67 in 2012 ms
2010.11.28 17:38:28 core 2 genetic pass (425, 56291461) démarré
2010.11.28 17:38:28 core 2 genetic pass (423, 1510001908) returned result 49.98 in 2028 ms
2010.11.28 17:38:28 core 1 passe génétique (424, 98130899813578) démarrée
2010.11.28 17:38:28 core 1 genetic pass (422, 1668020166802) returned result 48.36 in 2013 ms
2010.11.28 17:38:26 core 2 genetic pass (423, 1510001908) démarré
2010.11.28 17:38:26 core 2 genetic pass (419, 99260769921339) returned result 49.22 in 1935 ms
2010.11.28 17:38:26 core 1 passe génétique (422, 1668020166802) démarrée
2010.11.28 17:38:26 core 1 genetic pass (418, 32073563420604) returned result 26.13 in 1934 ms
2010.11.28 17:38:24 Tester la passe génétique (421, 730000073) trouvée dans le cache avec le résultat 50.00
2010.11.28 17:38:24 Tester le succès génétique (420, 2080000208) trouvé dans le cache avec le résultat 50.00
2010.11.28 17:38:24 Core 2 genetic pass (419, 99260769921339) démarré
2010.11.28 17:38:24 2010/11/28 17:38:24 Core 2 genetic pass (417, 99249619924961) a retourné le résultat 49.26 en 2059 ms
2010.11.28 17:38:24 core 1 passe génétique (418, 32073563420604) démarrée
2010.11.28 17:38:24 core 1 genetic pass (416, 2479846771) a retourné le résultat 48.49 en 2309 ms
2010.11.28 17:38:22 core 2 genetic pass (417, 99249619924961) démarré
En d'autres termes, il faut plus de 2 secondes pour calculer le FF nu, et ce alors qu'il n'y a aucune référence à l'environnement du marché.
L'optimiseur résout une tâche aussi simple que f(x1,x2)=x1*x1+x2*x2 quelque part à la 500ème "passe" et continue à essayer des variantes car il a défini plus de 1000 variantes à calculer.
Et il n'y a aucun réglage permettant d'affecter les capacités de recherche de l'algorithme. De plus, la limite de 64 paramètres optimisables est frustrante.
Il est possible de mettre en place un calculateur de vitesse personnalisé pour une tâche spécifique sans environnement de marché.
Mais si l'on essaie de créer un moteur de négociation universel fournissant des données multidevises à la demande, avec calcul automatique des bénéfices/limites et rapports, la vitesse diminuera immédiatement de 2-3-4 ordres de grandeur.
Je ne vais pas polémiquer, mais il serait bon d'élargir les paramètres de contrôle de l'algorithme, les mêmes paramètres de sortie de recherche et le nombre de paramètres de recherche.
Nous, ici à mql5, travaillons sur des algorithmes pour rechercher 3000 paramètres, et ce n'est pas la limite, bien sûr pas en codage binaire mais en plan continu.
Et vous avez toujours un RRF dans vos mains.
J'ai essayé de le faire en codage binaire, mais GA perd dans ce cas sur mql5. La recherche continue est bonne car elle réduit elle-même le nombre de pas à la convergence. De plus, nous n'avons pas besoin de ressources pour le codage/décodage. Eh bien, en général, nous avons besoin de tests corrects, il est trop tôt pour dire quoi que ce soit avec certitude.
L'optimiseur génétique deviendra probablement plus personnalisable + nous minimiserons la surcharge du système.
Merci beaucoup. C'est en fait très important, plus important que ce que beaucoup pourraient penser.
Et j'espère que nous oublierons aussi "Threshold 64" à un moment donné.
Dans la nouvelle version 366 (sortie lundi), nous avons réduit les frais généraux du système à des valeurs minimales.
L'expert en génétique ci-dessus passe maintenant entre 200 et 300 ms au lieu de 2 secondes par passage.
Merci beaucoup. C'est vraiment très important, plus important que beaucoup ne le pensent.
Et espérons que nous oublierons Threshold 64 à un moment donné, aussi.
Oubliez-le maintenant, à 4 paramètres à 8 chiffres, le testeur donne un avertissement que la surdimension a dépassé la longue.
Ainsi, pour des besoins autres que le test d'EAs, écrivez un optimiseur personnalisé.
Et 64 paramètres sont tout à fait suffisants pour optimiser les EAs.
Oui, j'ai lu le fil de discussion, où trouvent-ils des conseillers avec autant de paramètres :)
Oui, j'ai lu le fil de discussion, où trouvent-ils des conseillers avec autant de paramètres :)