Erreurs, bugs, questions - page 213
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
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:
Это не проблема, нужная сумма может быть вбита руками.