Erreurs, bugs, questions - page 1781
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
Je ne comprends pas si l'erreur est la mienne ou celle du terminal.
Au 5ème chiffre{
double A=1.11111;
double B=1.11111;
double C=1.11111;
long CalcX=
NormalizeDouble(A,Digits)*MathPow(10,(Digits+1)*3-1)+
NormalizeDouble(B,Digits)*MathPow(10,(Digits+1)*2-1)+
NormalizeDouble(C,Digits)*MathPow(10,(Digits+1)*1-1);
Print ("CalcX=",CalcX);
}
Imprime CalcX=111111111111111111111104 valeur attendue CalcX=111111111111111111111111
Ordre incorrect des appels de fonction lors du changement de période du graphique
Séquence des actions :
Il reste à ajouter ici que l'ajout d'un indicateur au graphique et la suppression d'un indicateur du graphique sont des opérations non synchrones.
En outre, lorsque l'on change de cadre temporel, l'indicateur n'est pas immédiatement déchargé de ce cadre temporel. Et il crée une nouvelle copie de l'indicateur sur le nouveau cadre temporel. Je vois vos empreintes dans le constructeur-destructeur, pensez-vous que le destructeur est appelé immédiatement ? Non, vous vous trompez. Le destructeur est appelé lorsque l'indicateur est déchargé, et l'indicateur n'est déchargé que quelques secondes après la suppression de l'indicateur.
Montrer les journaux. Donc vous pouvez voir le timing.
Il reste à ajouter que l'ajout d'un indicateur à un graphique et la suppression d'un indicateur d'un graphique sont des opérations non synchrones.
En outre, lorsque vous changez d'horizon temporel, l'indicateur ne sera pas immédiatement déchargé de cet horizon temporel. Et il crée une nouvelle copie de l'indicateur sur le nouveau cadre temporel. Je vois vos empreintes dans le constructeur-destructeur, pensez-vous que le destructeur est appelé immédiatement ? Non, vous vous trompez. Le destructeur est appelé lorsque l'indicateur est déchargé et l'indicateur n'est déchargé que quelques secondes après son retrait.
Il est supposé qu'il y a suffisamment de temps entre les étapes (la période du graphique change).
2017.02.05 19:49:49.984 I::I->M5 #step 1 : join
2017.02.05 19:49:49.984 OnInit->M5
2017.02.05 19:51:39.853 I::I->M15 #étape 2 : changement de période M5 ->M15
2017.02.05 19:51:39.853 OnInit->M15
2017.02.05 19:53:29.813 OnDeinit->M15:3 #étape 3 : changement de période M15->M30
2017.02.05 19:53:29.813 I::~I->M15
2017.02.05 19:53:29.864 I::I->M30
2017.02.05 19:53:29.864 OnInit->M30
2017.02.05 19:54:03.245 OnDeinit->M30:3 #étape 4 : changement de période M30->H1
2017.02.05 19:54:03.245 I::~I->M30
2017.02.05 19:54:03.286 I::I->H1
2017.02.05 19:54:03.286 OnInit->H1
2017.02.05 19:55:02.984 I::I->H4 #étape 5 : changement de période H1 ->H4
2017.02.02.05 19:55:02.984 OnInit->H4
2017.02.05 19:55:02.984 OnDeinit->H1:3
2017.02.05 19:55:02.984 I::~I->H1
2017.02.05 19:55:50.697 I::I->D1 #step 6 : period change H4 ->D1
2017.02.05 19:55:50.697 OnInit->D1
2017.02.05 19:55:50.697 OnDeinit->H4:3
2017.02.05 19:55:50.697 I::~I->H4
2017.02.05 19:56:11.122 OnDeinit->M5:1 #step 7 : delete
2017.02.05 19:56:11.122 I::~I->M5
2017.02.05 19:56:11.122 OnDeinit->D1:1
2017.02.05 19:56:11.123 I::~I->D1
La non-simultanéité n'affecte que l'ordre différent des appels de fonction au sein d'une étape (comme on le voit dans les étapes 3 et 5).
Comme vous pouvez le constater, tous les changements de période du graphique, à l'exception du premier (étape 2 : deux lignes de sortie), sont attendus (comme pour l'étape 3 : quatre lignes de sortie). Et pourquoi le premier changement de période graphique devrait-il être différent de tous les autres ? En quoi est-ce mieux/mauvais ? Pourquoi les deux lignes de sortie manquantes de l'étape n°2 (et seulement celle-là) ont-elles été déplacées vers l'étape n°7 (surlignée en rouge) ?
Je ne comprends pas si l'erreur est la mienne ou celle du terminal.
Imprime CalcX=111111111111111111111104 valeur attendue CalcX=111111111111111111111111
Il est supposé qu'il y a suffisamment de temps entre les étapes (la période du graphique change).
2017.02.05 19:49:49.984 I::I->M5 #step1 : join
2017.02.05 19:49:49.984 OnInit->M5
2017.02.05 19:51:39.853 I::I->M15 #étape 2 : changement de période M5 ->M15
2017.02.05 19:51:39.853 OnInit->M15
2017.02.05 19:53:29.813 OnDeinit->M15:3 #étape 3 : changement de période M15->M30
2017.02.05 19:53:29.813 I::~I->M15
2017.02.05 19:53:29.864 I::I->M30
2017.02.05 19:53:29.864 OnInit->M30
2017.02.05 19:54:03.245 OnDeinit->M30:3 #étape 4 : changement de période M30->H1
2017.02.05 19:54:03.245 I::~I->M30
2017.02.05 19:54:03.286 I::I->H1
2017.02.05 19:54:03.286 OnInit->H1
2017.02.05 19:55:02.984 I::I->H4 #étape 5 : changement de période H1 ->H4
2017.02.02.05 19:55:02.984 OnInit->H4
2017.02.05 19:55:02.984 OnDeinit->H1:3
2017.02.05 19:55:02.984 I::~I->H1
2017.02.05 19:55:50.697 I::I->D1 #step 6 : period change H4 ->D1
2017.02.05 19:55:50.697 OnInit->D1
2017.02.05 19:55:50.697 OnDeinit->H4:3
2017.02.05 19:55:50.697 I::~I->H4
2017.02.05 19:56:11.122 OnDeinit->M5:1 #step 7 : delete
2017.02.05 19:56:11.122 I::~I->M5
2017.02.05 19:56:11.122 OnDeinit->D1:1
2017.02.05 19:56:11.123 I::~I->D1
La non-simultanéité n'affecte que l'ordre différent des appels de fonction dans une étape (comme on le voit aux étapes 3 et 5).
Comme nous pouvons le constater, tous les changements de période ultérieurs du graphique, à l'exception du premier (étape n° 2), se déroulent comme prévu (comme à l'étape n° 3). Pourquoi le premier changement de période devrait-il être différent de tous les autres ? En quoi est-ce mieux/mauvais ?
Il y a une sorte d'indicateur sur la carte M5. Lorsque vous changez de cadre temporel de M5 à M15, une deuxième copie du même indicateur est créée. Une commande est envoyée aux deux indicateurs - le premier à M5 Deinit, le second à M15 Init. En même temps, nous ne savons pas laquelle de ces commandes sera exécutée avant l'autre - il y a une course classique entre les différents threads.
Après cela, le premier indicateur verra son compteur d'utilisation diminuer. Quelques secondes après que le compteur d'utilisation soit devenu nul, l'indicateur sera déchargé du graphique. A ce moment là, les destructeurs des objets globaux de cet indicateur seront appelés
Laissez-moi essayer d'expliquer à nouveau
Il y a un certain indicateur sur le graphique M5. Lorsque vous changez de cadre temporel de M5 à M15, une deuxième copie du même indicateur est créée. Une commande est envoyée aux deux indicateurs - le premier à M5 Deinit, le second à M15 Init. En même temps, nous ne savons pas laquelle de ces commandes sera exécutée avant l'autre - il y a une course classique entre les différents threads.
Après cela, le premier indicateur verra son compteur d'utilisation diminuer. Quelques secondes après que le compteur d'utilisation soit devenu nul, l'indicateur sera déchargé du graphique. Les destructeurs des objets globaux de cet indicateur seront appelés
J'affirme (et je propose de le vérifier) que lorsque l'on passe de M5 à M15, aucune commande M5 Deinit n'est envoyée au premier indicateur (et seulement à lui - dans ce cas M5) et il n'est pas déchargé du graphique jusqu'à ce que l'utilisateur supprime l'EA.
Si lastructure I de 'Test_i.ex5' est exclue (sans effet), la sortie est simplifiée :
2017.02.05 20:49:06.842 OnInit->M5
2017.02.05 20:49:21.253 OnInit->M15(*) changement de période M5 -> M15 : l' indicateur M5 n'est pas déchargé
2017.02.05 20:56:40.001 OnDeinit->M15:3 changement de période M15 -> M30 : l'indicateurM15 est déchargé immédiatement
2017.02.05 20:56:40.132 OnInit->M30
Plus de 5 minutes se sont écoulées depuis (*), mais l'indicateur M5 n'est pas déchargé.
Suppression de l'Expert Advisor du graphique
2017.02.05 20:57:35.176 OnDeinit->M5:1 l'indicateur M5 n'est déchargé qu'après avoir supprimé le conseiller expert
2017.02.05 20:57:35.177 OnDeinit->M30:1
Laissez-moi essayer d'expliquer à nouveau
Il y a un certain indicateur sur le graphique M5. Lorsque vous changez de cadre temporel de M5 à M15, la deuxième copie du même indicateur est créée. Une commande est envoyée aux deux indicateurs - le premier à M5 Deinit, le second à M15 Init. En même temps, nous ne savons pas laquelle de ces commandes sera exécutée avant l'autre - il y a une course classique entre les différents threads.
Après cela, le premier indicateur verra son compteur d'utilisation diminuer. Quelques secondes après que le compteur d'utilisation soit devenu nul, l'indicateur sera déchargé du graphique. A cela, les destructeurs des objets globaux de cet indicateur seront appelés
Problèmes lors de l'installation des indicateurs de Bill Williams
J'ai mis des fractales - ça fait
fixer AO - ADX est fixé
construire 1031
Si le nombre de décimales significatives dans le double > DBL_DIG=15, les règles normales ne fonctionnent pas.
Lesquelles fonctionnent ?
Dans le fichier d'aide, il est indiqué que la valeur maximale pour le long est de9223372036854775807 - je ne l'atteins évidemment pas.
Lesquelles fonctionnent ?
La règle consistant à perdre les chiffres significatifs et à les remplir avec des chiffres aléatoires fonctionne.
Le résultat est long, mais dans les calculs intermédiaires de double et c'est là que les chiffres significatifs sont perdus
(Chiffres+1)*3-1=17