Erreurs, bugs, questions - page 212
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
Oui, c'est vrai, uniquement sous la forme de fonctions standard pour optimiser la vitesse d'accès.
Je ne pense pas que l'on puisse encore parler de vitesse, d'autant plus que MQL5 traite rapidement l'ensemble des données d'actualité existantes. Et ce, dans l'espoir que le MQL soit encore plus rapide.
Mais je voudrais m'étendre sur ce sujet. Je me demande ce que vous comptez faire de ces données par la suite.
Je ne pense pas que l'on puisse encore parler de vitesse, d'autant plus que MQL5 traite rapidement l'ensemble des données d'actualité existantes. Et il faut espérer que le MQL sera encore plus rapide.
Mais je voudrais développer ce point. Je me demande ce qu'ils prévoient de faire avec ces données ? des exemples concrets d'utilisation ?
Et ce qui vient ensuite est un domaine chaud, les nouvelles n'étaient pas disponibles normalement avant, et alors le codage des stratégies de nouvelles va exploser.
J'ai l'intention de l'utiliser tout au long des comités NS, mais j'aimerais développer davantage le sujet.
ZZZY Mais tant que les nouvelles n'apparaîtront pas dans le testeur (c'est-à-dire les articles de presse), il faudra passer par des fichiers, et analyser les nouvelles sur des ressources tierces.
Le testeur ralentit lorsque le nombre de transactions augmente.
En ouvrant des trades avec une intensité d'environ 1 trade par 2 minutes, vous pouvez voir (onglet Log) qu'une seconde de temps de test à la fin d'une période assez longue a plusieurs fois moins de trades qu'au début du test. Image similaire lors de la sortie des résultats de test au format Open XML.
En fait, le temps de test ne dépend pas directement du nombre de transactions. Pour être exact, une exécution unique avec 10 transactions prendra bien sûr moins de temps qu'une exécution avec 100 000 transactions, car chaque transaction dans le testeur a besoin de temps pour être traitée.
Mais c'est le nombre de ticks traités dans une passe qui affecte le plus le temps de test. J'ai exécuté la moyenne mobile standard en mode tous les ticks à partir d'un mois (intervalle 2009.01.01-2009.02.01) et j'ai augmenté la durée du test d'un mois à chaque fois jusqu'à 22 mois.
Comme vous pouvez le voir sur le diagramme, la dépendance du temps de test par rapport au nombre de ticks est strictement linéaire.
Bonjour, reflétez l'ajout de la construction
#property tester_indicator "indicator.ex5"
dans la documentation, dans la description de la fonction iCustom. J'ai passé quelques heures à essayer de comprendre la raison pour laquelle iCustom fonctionne dans le graphique, mais ne fonctionne pas dans le testeur.
Ceci est décrit dans la section des propriétés du programme.
indicateur du testeur
chaîne de caractères
Nom de l'indicateur personnalisé au format "nom_indicateur.ex5" .Les indicateurs nécessaires aux tests sont déterminés automatiquement à partir de l'appel de la fonction iCustom(), si le paramètre correspondant est spécifié comme une chaîne constante. Pour les autres cas (utilisation de la fonction IndicatorCreate() ou utilisation d'une chaîne non constante dans le paramètre qui définit le nom de l'indicateur), nous avons besoin de cette propriété
fichier_testant
chaîne de caractères
Nom du fichier du testeur, en précisant son extension, entre guillemets (comme une chaîne constante). Le fichier spécifié sera transmis au testeur pour être exploité. Les fichiers d'entrée pour les tests, s'ils sont nécessaires, doivent toujours être spécifiés.
bibliothèque du testeur
chaîne de caractères
Nom de la bibliothèque avec l'extension, entre guillemets. Une bibliothèque peut avoir à la fois une extension dll et une extension ex5. Les bibliothèques nécessaires aux tests sont détectées automatiquement. Cependant, si une bibliothèque est utilisée par un indicateur personnalisé, on doit utiliser cette propriété
Mais vous avez raison, vous devez ajouter explicitement des informations à ce sujet aux endroits appropriés.
En fait, le temps de test ne dépend pas directement du nombre de transactions. Pour être exact, une exécution unique avec 10 transactions prendra bien sûr moins de temps qu'une exécution avec 100 000 transactions, car chaque transaction dans le testeur a besoin de temps pour être traitée.
Mais c'est le nombre de ticks traités dans une passe qui affecte le plus le temps de test. J'ai exécuté la moyenne mobile standard en mode tous les ticks à partir d'un mois (intervalle 2009.01.01-2009.02.01) et j'ai augmenté la durée du test d'un mois à chaque fois jusqu'à 22 mois.
Comme on peut le voir sur le diagramme, la dépendance du temps de test par rapport au nombre de ticks est strictement linéaire.
Je devrais probablement lire "une exécution unique avec 10 transactions prendra bien sûr MOINS de temps qu'une exécution avec 100 000 transactions, car chaque transaction dans le testeur a besoin de temps pour être traitée.
Je suis d'accord pour les tiques. Mais faites exactement attention au nombre de transactions - la croissance du temps n'y est évidemment pas linéaire, et la formation d'un rapport d'essai est totalement hors de question !
Quelle est la durée maximale qui peut être définie dans EventSetTimer( ) ?
INT_MAX? Je ne pense pas. Je ne veux pas enquêter par moi-même, et il n'y en a pas dans l'aide.
Il faut probablement lire "une exécution unique avec 10 transactions prendra bien sûr MOINS de temps qu'une exécution avec 100 000 transactions, car le traitement de chaque transaction dans le testeur prend du temps.
Je suis d'accord pour les tiques. Mais une fois de plus, veuillez prêter attention au nombre de transactions - la croissance du temps n'y est clairement pas linéaire, et la formation du rapport de test est complètement hors de question !
Au cours des essais, quelques questions se sont posées, je montre des photos prises au même moment :
Comme on peut le voir sur la figure, seuls trois cœurs fonctionnent, nous avons été confrontés plus d'une fois à une situation où, au cours des tests, le nombre de cœurs impliqués dans le travail est progressivement tombé à zéro, puis est entré en fonctionnement d'un seul coup, c'est-à-dire qu'il y a un temps d'arrêt, pourquoi les cœurs libérés ne commencent pas à fonctionner immédiatement ?
Le nombre d'exécutions est défini comme 287, mais les résultats de l'optimisation le montrent ainsi :
Que signifient ces chiffres alors ? Le nombre de points dans le graphe d'optimisation est également d'environ 381...