Un peu surpris :) J'ai pensé que je devais partager et poser une question NON rhétorique. - page 14
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'optimiseur n'est pas exactement un "testeur à échelle linéaire", mais possède ses propres méthodes d'optimisation qui fonctionnent efficacement sur des calculs répétés à grande échelle.
Nous sommes juste en train d'accélérer les calculs de masse. Voici un lien vers les résultats passés, et une nouvelle version avec des calculs plus rapides est prête.
Je suis d'accord, ce n'est pas exactement un "testeur à échelle linéaire". Vous faites des optimisations explicites, ce qui est une très bonne chose. Cependant, je ne peux pas imaginer comment vous pourriez optimiser pour un cas univarié - une situation très fréquente :
L'optimisation porte sur deux paramètres, l'un (plage de 100 valeurs) ne touche pas les appels de l'indicateur, le second (plage de 5 valeurs) les touche.
Dans ce cas, vous calculerez les valeurs de l'indicateur 500 fois en recherchant 500 variantes. Dans ce cas, vous effectuerez en fait un très grand nombre de recalculs. C'est parce que la plage de la deuxième variable est seulement 5, et non 500.
Ce n'est que l'exemple le plus simple. Peut-être avez-vous déjà trouvé des idées pour contourner cette mise à l'échelle linéaire du testeur pour l'optimiseur.
P.S. Ce sont des exemples comme ceux-ci qui vous donnent un avantage de vitesse dans vos propres calculateurs, par ordre de grandeur et non par pourcentage. Mais ces calculatrices ne sont pas universelles, et la comparaison est donc incorrecte dès le départ.
Ok - disons qu'il existe un optimiseur sans cloud computing, mais multi-thread, et qui supporte C++ et MT4 (et tout son sous-système) et est 100 fois plus rapide que lui, et 6 fois plus rapide uniquement par le code MT5, oui... et "résout" non seulement avec la force brute et l'AG, mais aussi avec environ 50 autres variantes. A quel prix l'achèteriez-vous ? L'achèteriez-vous pour 1000 $ ? Pourquoi si cher ? Vous et dix autres personnes serez les seuls acheteurs. :)
Cependant, je ne peux pas imaginer comment vous pourriez optimiser pour un cas univarié - une situation très fréquente :
Je peux déjà imaginer quelque chose (mais pas complètement). Avant d'exécuter l'optimiseur, vous devez effectuer une analyse de dépendance sur les paramètres d'entrée à optimiser (dans l'exemple ci-dessus, deux variables sont complètement indépendantes). Ensuite, l'optimisation passe d'abord par les variables indépendantes, de la plus petite plage à la plus grande (ce qui n'est pas toujours correct, car cela dépend aussi de l'intensité des ressources des mêmes indicateurs). Parfois, il est préférable de compter 100 fois l'indicateur léger, plutôt que 5 fois l'indicateur lourd), en mettant les résultats en cache.
Il est clair que la mise en œuvre d'une telle optimisation est très complexe (surtout pour le cas du cloud). Mais s'il est mis en œuvre, alors au moins absolument tous les conseillers experts créés dans l'assistant MQL5 seront optimisés des ordres de grandeur plus rapidement. Parce que l'assistant MQL5 est une combinaison d'un grand nombre d'indicateurs entre eux (c'est-à-dire qu'il y a un grand nombre de paramètres d'entrée indépendants les uns des autres). D'autre part, une telle activité n'a aucun sens pour un trading rentable...
La mise en cache suivie de l'échantillonnage des résultats sur des échantillons énormes (des millions et des dizaines de millions) est plus coûteuse que le calcul direct.
La mise en cache avec échantillonnage ultérieur des résultats sur des échantillons énormes (des millions et des dizaines de millions) est plus coûteuse que le calcul direct.
Je suis sûr qu'il est presque irréaliste d'implémenter un optimiseur universel parfait pour qu'il soit aussi "intelligent" que je l'ai décrit ci-dessus. Bien sûr, il est possible de l'améliorer, mais il ne peut en aucun cas être parfait.
Des échantillons énormes (des dizaines de millions), bien sûr, vous exagérez considérablement. Il n'est pas du tout nécessaire de mettre ces choses en cachette.
Je pense que vous comprenez tous parfaitement ce que je veux dire. Et beaucoup le font. Personne ne vous critiquera même pour cela, sinon ce serait l'ignorance des critiques par les programmeurs. Parce que ceux qui sont adéquats sont bien conscients de la difficulté de mettre en œuvre de telles choses.
Je vais expliquer la signification de la mise en cache en utilisant le même exemple :
Si l'indicateur n'est pas redessiné, à la fin d'une seule exécution dans le testeur, vous aurez un tampon complet de toutes les valeurs de l'indicateur. Vous l'avez déjà. Et, si le passage suivant utilise les mêmes valeurs indicatrices (la deuxième variable n'a pas changé), nous n'avons pas besoin de le relire. Vous pouvez prendre les valeurs du tampon déjà calculé (que vous avez déjà, il n'est pas nécessaire de le mettre en cache, la mémoire de l'exécution précédente n'est pas complètement libre).
Si l'indicateur ne se redessine pas, alors
Je suis sûr qu'il est presque irréaliste d'implémenter un optimiseur universel parfait pour qu'il soit aussi "intelligent" que je l'ai décrit ci-dessus. Bien sûr, il y a beaucoup de place pour l'amélioration, mais on ne peut pas faire les choses parfaitement de toute façon.
Des échantillons énormes (des dizaines de millions), bien sûr, vous exagérez considérablement. Il n'est pas du tout nécessaire de mettre ces choses en cachette.
Par exemple, le test EURUSD pour les 11 dernières années donne plus de 50 millions de ticks.
Cela signifie qu'un indicateur simple à un tampon comme MA devra stocker 50 millions d'états (50 millions * 8 octets(double) = 400 mb de tampon), ce qui est trop. Si l'on utilise quelque chose de plus complexe ou de plus grand en nombre, en fait le cache ne tiendra pas dans la mémoire, sans parler des agents multi-cœurs.
Nous travaillions sur l'idée de caches d'indicateurs et il s'est avéré qu'il est beaucoup plus rapide et moins consommateur de ressources de calculer la prochaine valeur de l'indicateur (et même avec une méthode économique) que de construire des caches.
Oui, précisément parce qu'il est impossible d'écrire un optimiseur universel aussi rapide, les broyeurs numériques non universels gagneront toujours en termes de vitesse. Et il n'y a rien de bon ou de mauvais dans tout ça.
Ils ne gagnent rien.
Ils ne disposent d'aucun environnement de marché, d'aucune infrastructure, d'aucun indicateur, d'aucune analyse. Et cela est plus important qu'un cycle ponctuel (et même pas représenté).
Par exemple, le test EURUSD sur les 11 dernières années donne plus de 50 millions de ticks.
Nous parlons d'un optimiseur, et non d'un grand nombre de tests individuels. Le concept de l'optimiseur est tout à fait différent. Là, des gains de vitesse importants sont obtenus au prix de petites erreurs dans les résultats. L'optimiseur n'a pas du tout besoin de modèles basés sur les ticks. Tout au plus, ils sont basés sur les prix d'ouverture. Un optimiseur n'est pas un testeur, c'est tout à fait autre chose. Votre approche est différente, et assez logique aussi.
Ils ne gagnent rien.
Ils ne disposent d'aucun environnement de marché, d'aucune infrastructure, d'aucun indicateur, d'aucune analyse. Et c'est plus important qu'un cycle ponctuel (et même pas représenté).
Ils gagnent en vitesse, car rien ne peut être plus rapide que le seul cycle for. Parfois, la vitesse est exactement ce dont vous avez besoin, et une calculatrice battra n'importe quel testeur universel en termes de vitesse (mais pas pour les autres paramètres). Pas seulement chez MetaQuotes.
Je ne peux pas prouver mon affirmation pour la raison suivante :
Ma calculatrice est simplement une implémentation C++ de mon EA, où toutes les opérations sont spécifiquement rendues entières (les prix sont des entiers), où les passes inutiles etc. sont complètement réduites à zéro. Il n'y a pas d'interface, rien. La seule sortie est un fichier contenant les résultats de l'optimisation. Par exemple, je peux écrire un EA avec une optimisation algorithmique en C++ et mon testeur ne fera aucun contrôle de trading (par exemple, vérifier si la marge est suffisante, etc.). Il n'émule pas l'histoire et ne compte pas les indicateurs. Il n'y a rien d'universel en termes de polyvalence du testeur MT5. La seule tâche de la calculatrice est de calculer rapidement, le plus rapidement possible. Et il compte cent fois plus vite que le testeur MT4, produisant une erreur de <1%. Je ne comprends pas ce que j'essaie de montrer ici.
Il est évident que la boucle for sans contrôles et avec seulement des entiers comptera toujours plus vite qu'un testeur universel.