Comme vous pouvez le voir sur la figure, seuls trois cœurs fonctionnent, j'ai vu plus d'une situation où, pendant le test, le nombre de cœurs impliqués dans le travail tombe progressivement à zéro, après quoi tous les cœurs se mettent à travailler en même temps, c'est-à-dire qu'il y a un temps d'arrêt, pourquoi les cœurs libérés ne se mettent pas à travailler en même temps ?
Pour pouvoir commencer à calculer la génération suivante, nous devons d'abord traiter la génération actuelle. Toutes les exécutions de la génération actuelle doivent être terminées afin de sélectionner les meilleures et d'effectuer des opérations génétiques entre les meilleures. Ce n'est qu'alors que la prochaine génération pourra être lancée.
Lorsqu'il ne reste plus que quelques résultats manquants pour achever le traitement de la génération actuelle, les agents de contrôle libérés sont au chômage.
N'importe quel temps peut être utilisé ici, mais dans le testeur le temps sera pris modulo 50 jours. Environ 4 220 000 secondes.
La qualité du MQL5 est démotivante.
Vous pouvez définir un maximum de 2 147 483 secondes (correspondant à 35 791 minutes, 596 heures ou 24 jours). Ce n'est pas la façon dont le minuteur est géré dans le testeur.
Contre question. Pourquoi régler la minuterie sur 24 jours ?
Il est possible de régler un maximum de 2 147 483 secondes (correspondant à 35 791 minutes, 596 heures ou 24 jours). Ce n'est pas la façon dont le minuteur est géré dans le testeur.
Contre question. Pourquoi régler la minuterie sur 24 jours ?
Je veux que la position soit fermée après l'ouverture dans un délai allant de 1 seconde à 10 ans, en fonction de quelque chose.
J'ai essayé de cette façon
request.type_time=ORDER_TIME_SPECIFIED ; // La commande sera valide jusqu'à la date d'expiration. request.expiration=1 ; //or TimeCurrent()+time ; (int time=1 ;)
ne fonctionne pas avec les secondes.
Contourner ce problème avec EventSetTimer( ). Également limité à 24 jours. Et surtout, je ne m'attendais pas à un tel gâchis de la part de la minuterie. Vous auriez dû être prévenu. Oh bien.
À propos, l'heure indiquée dans le chronomètre correspond-elle à l'heure réelle du calendrier ou seulement à l'heure de négociation ? En d'autres termes, immédiatement après le week-end, combien de temps est affiché sur la minuterie ?
A nouveau, un cas de perte partielle de communication entre le terminal et le serveur a été signalé. Construire 360. Aucun devis n'est reçu, mais les informations sur le temps et le volume des transactions sont mises à jour. L'indicateur d'état de la connexion comporte un cercle rotatif avec des secteurs gris. Il y a des messages dans le journal :
2010.11.29 18:03:03 Trades '630031' : deal #2107036 acheter 0.10 GBPUSD à 1.55387 effectué (basé sur l'ordre #2157432) 2010.11.29 18:00:02 Transactions '630031' : transaction #2106895 acheter 0.10 GBPUSD à 1.55341 fait (basé sur l'ordre #2157265) 2010.11.29 17:07:49 Network '630031' : autorisé sur MetaQuotes-Demo 2010.11.29 17:07:47 Network '630031' : connexion à MetaQuotes-Demo perdue 2010.11.29 16:10:47 Network '630031' : le trading a été désactivé - mode investisseur 2010.11.29 16:10:47 Réseau '630031' : le terminal s'est synchronisé avec MetaQuotes Software Corp. 2010.11.29 16:10:47 Network '630031' : autorisé sur MetaQuotes-Demo 2010.11.29 16:10:45 Network '630031' : connexion à MetaQuotes-Demo perdue
Notez qu'il n'y a pas de message "terminal synchronisé avec MetaQuotes Software Corp." après 17:07:49, au moment même où de nouvelles transactions sont signalées.
Rosh: Сделайте прогоны с одинаковым количеством тиком и разным количеством сделок. Тогда можно сравнивать.
Voilà.
Système de test (quel qu'il soit !) : Windows XP SP3, Pentium 4, 3GHz, 1,25 Go de mémoire.
Toutes les exécutions ont été effectuées en utilisant Alpari-Demo, GPBUSD M1, période 04.10.2010-05.11.2010 (1521376 ticks, 34194 barres) en mode Normal, chaque tick, dépôt 10000USD (à propos, où avez-vous obtenu un dépôt de 1000000USD ? Ma liste se termine par 100000), effet de levier 1:100. J'ai construit un Expert Advisor qui utilise la particularité du compte Alpari-Demo - zéro marge - pour simplifier sa construction. Pour chaque tick, le conseiller expert ouvre un ordre de 0,1 lot dans une direction, jusqu'à ce qu'il atteigne le nombre de trades spécifié à l'aide du paramètre, le reste des ticks sont ignorés. Ainsi, l'influence du nombre de trades est minimisée (1 trade a été obtenu sur tous les tests). A propos, à la fin de chaque test, nous avons vérifié le temps approximatif de formation du rapport dans le format Open XML (n'a pas dépassé le seuil de la patience jusqu'à présent). Les transactions générées par le testeur à la fin du test n'ont pas été prises en compte (une transaction par run).
Ainsi :
La première série de tests de 10 à 100 transactions avec des incréments de 10 n'est pas intéressante en raison du faible temps de test - temps de génération de tick de 5359 à 6453.
La série suivante va de 100 à 1000 transactions par incréments de 100 (le résultat pour 100 est repris de la série précédente) :
Transactions
Temps, ms
Temps total, ms
Durée approximative de la formation du rapport xlsx, en secondes.
Notes
100
6359
6813
5
Moins de 5 secondes
200
6172
6594
5
300
6875
7375
7
400
5734
6094
10
500
6109
6562
14
600
6281
6687
17
700
8016
8563
23
800
7281
7719
28
900
9047
9610
35
1000
8453
8812
44
Tout est bon, mais le problème de génération de rapports commence à se faire sentir.
Ashes: Toutes les exécutions ont été effectuées avec Alpari-Demo, GPBUSD M1, période 04.10.2010-05.11.2010 (1521376 ticks, 34194 barres) en mode Normal, chaque tick, dépôt 10000USD (au fait, où avez-vous obtenu le dépôt de 10000USD ?
Ce n'est pas un problème, le montant requis peut être saisi manuellement.
La série finale (les tests supplémentaires sur ce matériel sont trop durs pour moi ;) de 1000 à 10000 par pas de 1000 :
C'est là que les freins auxquels Rosh a fait référence de manière interrogative apparaissent dans toute leur gloire.
Les métiers
Temps, ms
Temps total, ms
Durée approximative de la génération du rapport xlsx, en secondes.
Notes
1000
8453
8812
44
2000
26750
27266
159
3000
60782
61141
355
**
4000
125469
171391
480
Plus de 480 secondes
**
5000
414609
459281
Pas de données
Pas de génération de rapports pour les exécutions supérieures à 4000 transactions
6000
600610
601094
Pas de données
7000
648234
675576
648234 675576 Pas de données
**
8000
1082437
1082796
1082437 1082796 Pas de données
9000
1465203
1508359
Pas de données
10000
1988031
2012500
Pas de données
Pour paraphraser Rosh, comme vous pouvez le voir sur le diagramme, la dépendance du temps de test par rapport au nombre de RATEs n'est PAS strictement linéaire. Au contraire, elle n'est pas du tout linéaire.
Le résultat à 5000 et 6000 est probablement un peu surestimé, mais une tendance peut être observée.
Je tiens à vous rappeler que ce résultat a été obtenu en utilisant l'Expert Advisor le plus simple, qui ne consacre pratiquement pas de temps à une quelconque analyse et n'utilise pas d'indicateurs ; autrement dit, les résultats seraient encore pires dans un EA qui fonctionne.
À titre de comparaison :
L'exécution de ce test avec 10000 transactions sur une machine Windows 7, Intel Pentium Dual-Core E5400 @ 2.70 GHz, 2038 MB (PR111) a pris 472866ms.
À la lumière de ce qui précède, il y a une certaine probabilité que certains des candidats au Championnat 2010 aient pu être injustement disqualifiés en raison de la barrière des 15 minutes et des particularités du testeur (s'il y avait beaucoup d'affaires).
** - à plusieurs reprises à la fin du test, le graphique du symbole montrant les transactions n'était pas affiché.
Comme vous pouvez le voir sur la figure, seuls trois cœurs fonctionnent, j'ai vu plus d'une situation où, pendant le test, le nombre de cœurs impliqués dans le travail tombe progressivement à zéro, après quoi tous les cœurs se mettent à travailler en même temps, c'est-à-dire qu'il y a un temps d'arrêt, pourquoi les cœurs libérés ne se mettent pas à travailler en même temps ?
Pour pouvoir commencer à calculer la génération suivante, nous devons d'abord traiter la génération actuelle. Toutes les exécutions de la génération actuelle doivent être terminées afin de sélectionner les meilleures et d'effectuer des opérations génétiques entre les meilleures. Ce n'est qu'alors que la prochaine génération pourra être lancée.
Lorsqu'il ne reste plus que quelques résultats manquants pour achever le traitement de la génération actuelle, les agents de contrôle libérés sont au chômage.
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 moi-même et ce n'est pas dans l'aide.
N'importe quel temps peut être défini ici, mais dans le testeur le temps sera pris modulo 50 jours. Environ 4 220 000 secondes.
La qualité du MQL5 me démotive.
N'importe quel temps peut être utilisé ici, mais dans le testeur le temps sera pris modulo 50 jours. Environ 4 220 000 secondes.
La qualité du MQL5 est démotivante.
Vous pouvez définir un maximum de 2 147 483 secondes (correspondant à 35 791 minutes, 596 heures ou 24 jours). Ce n'est pas la façon dont le minuteur est géré dans le testeur.
Contre question. Pourquoi régler la minuterie sur 24 jours ?
Il est possible de régler un maximum de 2 147 483 secondes (correspondant à 35 791 minutes, 596 heures ou 24 jours). Ce n'est pas la façon dont le minuteur est géré dans le testeur.
Contre question. Pourquoi régler la minuterie sur 24 jours ?
Je veux que la position soit fermée après l'ouverture dans un délai allant de 1 seconde à 10 ans, en fonction de quelque chose.
J'ai essayé de cette façon
request.type_time=ORDER_TIME_SPECIFIED ; // La commande sera valide jusqu'à la date d'expiration.
request.expiration=1 ; //or TimeCurrent()+time ; (int time=1 ;)
ne fonctionne pas avec les secondes.
Contourner ce problème avec EventSetTimer( ). Également limité à 24 jours. Et surtout, je ne m'attendais pas à un tel gâchis de la part de la minuterie. Vous auriez dû être prévenu. Oh bien.
À propos, l'heure indiquée dans le chronomètre correspond-elle à l'heure réelle du calendrier ou seulement à l'heure de négociation ? En d'autres termes, immédiatement après le week-end, combien de temps est affiché sur la minuterie ?
A nouveau, un cas de perte partielle de communication entre le terminal et le serveur a été signalé. Construire 360. Aucun devis n'est reçu, mais les informations sur le temps et le volume des transactions sont mises à jour. L'indicateur d'état de la connexion comporte un cercle rotatif avec des secteurs gris. Il y a des messages dans le journal :
2010.11.29 18:03:03 Trades '630031' : deal #2107036 acheter 0.10 GBPUSD à 1.55387 effectué (basé sur l'ordre #2157432)
2010.11.29 18:00:02 Transactions '630031' : transaction #2106895 acheter 0.10 GBPUSD à 1.55341 fait (basé sur l'ordre #2157265)
2010.11.29 17:07:49 Network '630031' : autorisé sur MetaQuotes-Demo
2010.11.29 17:07:47 Network '630031' : connexion à MetaQuotes-Demo perdue
2010.11.29 16:10:47 Network '630031' : le trading a été désactivé - mode investisseur
2010.11.29 16:10:47 Réseau '630031' : le terminal s'est synchronisé avec MetaQuotes Software Corp.
2010.11.29 16:10:47 Network '630031' : autorisé sur MetaQuotes-Demo
2010.11.29 16:10:45 Network '630031' : connexion à MetaQuotes-Demo perdue
Notez qu'il n'y a pas de message "terminal synchronisé avec MetaQuotes Software Corp." après 17:07:49, au moment même où de nouvelles transactions sont signalées.
Rosh:
Сделайте прогоны с одинаковым количеством тиком и разным количеством сделок. Тогда можно сравнивать.
Voilà.
Système de test (quel qu'il soit !) : Windows XP SP3, Pentium 4, 3GHz, 1,25 Go de mémoire.
Toutes les exécutions ont été effectuées en utilisant Alpari-Demo, GPBUSD M1, période 04.10.2010-05.11.2010 (1521376 ticks, 34194 barres) en mode Normal, chaque tick, dépôt 10000USD (à propos, où avez-vous obtenu un dépôt de 1000000USD ? Ma liste se termine par 100000), effet de levier 1:100. J'ai construit un Expert Advisor qui utilise la particularité du compte Alpari-Demo - zéro marge - pour simplifier sa construction. Pour chaque tick, le conseiller expert ouvre un ordre de 0,1 lot dans une direction, jusqu'à ce qu'il atteigne le nombre de trades spécifié à l'aide du paramètre, le reste des ticks sont ignorés. Ainsi, l'influence du nombre de trades est minimisée (1 trade a été obtenu sur tous les tests). A propos, à la fin de chaque test, nous avons vérifié le temps approximatif de formation du rapport dans le format Open XML (n'a pas dépassé le seuil de la patience jusqu'à présent). Les transactions générées par le testeur à la fin du test n'ont pas été prises en compte (une transaction par run).
Ainsi :
La première série de tests de 10 à 100 transactions avec des incréments de 10 n'est pas intéressante en raison du faible temps de test - temps de génération de tick de 5359 à 6453.
La série suivante va de 100 à 1000 transactions par incréments de 100 (le résultat pour 100 est repris de la série précédente) :
14
Tout est bon, mais le problème de génération de rapports commence à se faire sentir.
Toutes les exécutions ont été effectuées avec Alpari-Demo, GPBUSD M1, période 04.10.2010-05.11.2010 (1521376 ticks, 34194 barres) en mode Normal, chaque tick, dépôt 10000USD (au fait, où avez-vous obtenu le dépôt de 10000USD ?
La série finale (les tests supplémentaires sur ce matériel sont trop durs pour moi ;) de 1000 à 10000 par pas de 1000 :
C'est là que les freins auxquels Rosh a fait référence de manière interrogative apparaissent dans toute leur gloire.
**
Pour paraphraser Rosh, comme vous pouvez le voir sur le diagramme, la dépendance du temps de test par rapport au nombre de RATEs n'est PAS strictement linéaire. Au contraire, elle n'est pas du tout linéaire.
Le résultat à 5000 et 6000 est probablement un peu surestimé, mais une tendance peut être observée.
Je tiens à vous rappeler que ce résultat a été obtenu en utilisant l'Expert Advisor le plus simple, qui ne consacre pratiquement pas de temps à une quelconque analyse et n'utilise pas d'indicateurs ; autrement dit, les résultats seraient encore pires dans un EA qui fonctionne.
À titre de comparaison :
L'exécution de ce test avec 10000 transactions sur une machine Windows 7, Intel Pentium Dual-Core E5400 @ 2.70 GHz, 2038 MB (PR111) a pris 472866ms.
À la lumière de ce qui précède, il y a une certaine probabilité que certains des candidats au Championnat 2010 aient pu être injustement disqualifiés en raison de la barrière des 15 minutes et des particularités du testeur (s'il y avait beaucoup d'affaires).
** - à plusieurs reprises à la fin du test, le graphique du symbole montrant les transactions n'était pas affiché.
Interesting:
Это не проблема, нужная сумма может быть вбита руками.