Erreurs, bugs, questions - page 3131

Nouveau commentaire
 
Alexey Viktorov #:

Dans votre cas, ce n'est pas le cas, car les deux conditions doivent être remplies. Mais si tu mets ça

alors, oui. Si la condition "a" est remplie, la deuxième condition ne sera pas vérifiée. On s'est battu pour cela pendant des années, et maintenant vous suggérez que nous retournions au siècle dernier...

Bien que... j'aie tort dans cette déclaration. Apparemment, je ne comprends pas bien ce qui est écrit ici.

x572intraday #:

Je n'ose pas appeler ça un bug. C'est pourquoi je dirai simplement que j'ai remarqué une particularité de l'opérateur if. Je pense qu'elle peut également s'appliquer à d'autres langues écrites.

Si a s'avère être vrai, la vérification saute à Array[over_index] et ici le terminal commence à s'écraser sur la partie'array out of range', qui est tout à fait vraie. Mais si a s'avère être faux, le terminal ne vérifiera pas la condition Array[over_index] et donc la redondance d'index, et si sautera plus loin et le codeur ne saura pas qu'il y a un tableau avec un index inexistant dans son programme.... ou plutôt une existante mais redondante.

Peut-être devrait-il y avoir un correctif pour que la vérification de 'array out of range' soit effectuée à la toute fin de la boucle if et que le même message soit affiché ? Ou bien cela réduira-t-il considérablement la vitesse de l'opérateur ?

Même si la condition && et la première condition ne sont pas remplies, la seconde ne sera pas vérifiée. Alors, excusez-moi si j'ai induit quelqu'un en erreur...

 
x572intraday #:

J'ai déjà essayé de faire une pause et de revenir en vitesse, mais ça n'a fait qu'empirer les choses. Je vais essayer de simplifier un peu plus le code et le repenser avec pause...

for(int i=start; i<rates_total-n && !IsStopped(); i++)
{
   for(int increment=1, bool h_plus=true ; h_plus && increment<=n ; increment++)
     h_plus =  high[i]>high[i+increment]; // можно не накапливать, вылетим из цикла на первом false

   if(h_plus) {...}
   ...
}

Comme ça.

 

Lorsque vous mettez le graphique à l'échelle en déplaçant la souris le long de la ligne de temps, le graphique se déplace vers la gauche ou la droite, selon la direction de la souris, de sorte que tout ce qui se trouve dans le champ de vision de l'utilisateur disparaît souvent au-delà des limites du graphique. C'est terriblement gênant, car il faut alors chercher le bon endroit, et c'est le cas depuis que je connais MT.

Il était logique de penser qu'en cliquant sur l'icône de la loupe, le graphique serait remis à l'échelle au centre, mais non, le comportement est le même qu'avec l'échelle de la souris - le graphique se déplace vers la gauche (compression) ou vers la droite (expansion).

Chers développeurs ! Nous vous demandons instamment de modifier le comportement de mise à l'échelle de la carte, il est nécessaire de laisser le centre de la carte au centre.

Toutes les personnes avec qui j'ai discuté de cet inconvénient de travailler avec le tableau sont d'accord avec moi, j'ai donc de bonnes chances d'être objectif sur ce problème.

J'ai essayé de m'y habituer pendant 14 ans - je n'ai pas pu.

 
JRandomTrader #:
for(int i=start; i<rates_total-n && !IsStopped(); i++)
{
   for(int increment=1, bool h_plus=true ; h_plus && increment<=n ; increment++)
     h_plus = high[i]>high[i+increment]; // можно не накапливать, вылетим из цикла на первом false

   if(h_plus) {...}
   ...
}

C'est quelque chose comme ça.

Nouvelle idée, je vais l'essayer.

Comme pour l'option précédente :

for(int i=start; i<rates_total-3 && !IsStopped(); i++)
{
   bool h_plus=true; //false?
   for(int increment=1; increment<=n; increment++)
     {
      h_plus&=high[i]>high[i+increment];
      if(!h_plus)break;
     }
   if(h_plus) {...}
   ...
}

sans même l'essayer, il est déjà clair que

if(!h_plus)break;

est après la sommation, ce qui signifie que le terminal verra la ligne précédente en premier et comprendra qu'il y a un tableau avec un index excessif et donnera le même message'array out of range'. C'est la deuxième chose. La première est que nous devrions vérifier non pas !h_plus mais ArraySize(high)<=i+increment et sortir de la boucle en cas de dépassement de l'indice. J'ai essayé tout cela hier, mais j'ai échoué dans certaines subtilités. Oui, il n'y avait pas de message, mais l'indicateur a aussi commencé à faire des siennes.

 
x572intraday #:

Comme pour l'option précédente :

sans même l'essayer, il est déjà clair que

est après la sommation, ce qui signifie que le terminal verra la ligne précédente en premier et comprendra qu'il y a un tableau avec un index excessif et donnera le même message'array out of range'. C'est la deuxième chose. La première est que nous devrions vérifier non pas !h_plus mais ArraySize(high)<=i+increment et sortir de la boucle en cas de dépassement de l'indice. J'ai essayé tout cela hier, mais j'ai échoué dans certaines subtilités. Oui, le messager est parti, mais l'indicateur a aussi commencé à faire des dégâts.

Donc le problème ici est

i<rates_total-3
J'ai écrit 
i<rates_total-n
pour une raison, et le coup de pied précoce de la boucle est précisément pour simuler le calcul if()
 
x572intraday #:

Je n'ose pas dire que c'est un bug. Je vais donc dire que j'ai remarqué une particularité de l'instruction if. Je pense que cela peut s'appliquer à d'autres langues également.

Si a s'avère être vrai, la vérification saute à Array[over_index] et ici le terminal commence à s'écraser sur la partie'array out of range', qui est tout à fait vraie. Mais si a s'avère être faux, le terminal ne vérifiera pas la condition Array[over_index] et donc la redondance d'index, et si sautera plus loin et le codeur ne saura pas qu'il y a un tableau avec un index inexistant dans son programme.... ou plutôt une existante mais redondante.

Peut-être devrait-il y avoir un correctif pour que la vérification de 'array out of range' soit effectuée à la toute fin de la boucle if et que le même message soit affiché ? Ou bien cela réduira-t-il considérablement la vitesse de l'opérateur ?


Si vous mettez la variable a à false, le contrôle est transmis et n'affecte pas le tableau ou le code entre parenthèses après if, car dans votre cas

if(a && Array[over_index]>val) {...}

le contrôle sera transmis à la partie droite de la condition uniquement si la partie gauche (a) est vraie.

si, par exemple, vous faites

if(check(over_index) && Array[over_index]>val) {...}

où la fonction check vérifie le tableau Array,vous n' obtiendrez jamais"array out of range". Donc, vous pouvez vérifier l'index du tableau et l'adresser dans un if. Mais passer le contrôle à la deuxième partie du if avec l'opérateur &&, si la première partie est fausse, n'est guère possible dans aucun des langages de programmation existants...

 

Il y a un problème, il apparaît de manière aléatoire et occasionnelle.

Apparaît lorsque l'on travaille dans le testeur avec plusieurs devises.

Dans chaque cycle, je demande les prix réels des symboles. Si, pour une raison quelconque, le testeur ne reçoit pas de cotations pour un symbole particulier, il utilise les cotations obtenues précédemment pour un autre symbole.

Je dois ouvrir une position si le prix est supérieur au prix spécifié. Je dois ouvrir une position si j'ai reçu des données erronées d'un autre symbole.

Le symbole EURCAD s'ouvre si le prix est supérieur à 1,45117. 1.74425>1.45117 ? Oui, il est plus élevé mais c'est le prix d'un autre symbole.

Nous avons détecté 7 commandes erronées sur 500.

 
Yury Lemeshev #:

Il y a un problème, il apparaît de manière aléatoire et occasionnelle.

Il apparaît lorsque l'on travaille dans le testeur avec plusieurs devises.

Dans chaque cycle, je demande les prix réels des symboles. Si, pour une raison quelconque, le testeur ne reçoit pas de cotations pour un symbole particulier, il utilise les cotations obtenues précédemment pour un autre symbole.

Je dois ouvrir une position si le prix est supérieur au prix spécifié. J'utilise les mauvaises données d'un autre symbole pour l'ouverture.

Symbole EURCAD si le prix est supérieur à 1.45117 alors il s'ouvre. 1.74425>1.45117 ? Oui, il est plus élevé mais c'est le prix d'un autre symbole.

Nous avons détecté 7 commandes erronées sur 500.

Le problème se trouve dans le code, mais les télépathes sont déjà en train de faire la fête et quand ils sortiront de leur sommeil, ils diront que l'erreur se trouve à la ligne 123652.

 
Alexey Viktorov #:

Des problèmes dans le code, mais les télépathes sont déjà en train de faire la fête, et quand ils sortiront de leur bringue, ils diront que l'erreur est dans la ligne 123652

Il n'y a pas d'erreur dans le code, le code a été réécrit pour éliminer l'erreur, et l'erreur n'apparaît pas régulièrement, c'est complètement chaotique.

 
Yury Lemeshev #:

Il y a un problème, il apparaît de manière aléatoire et occasionnelle.

Apparaît lorsque l'on travaille dans le testeur avec plusieurs devises.

Dans chaque cycle, je demande les prix réels des symboles. Si, pour une raison quelconque, le testeur ne reçoit pas de cotations pour un symbole particulier, il utilise les cotations obtenues précédemment pour un autre symbole.

Je dois ouvrir une position si le prix est supérieur au prix spécifié. Je dois ouvrir une position si j'ai reçu des données erronées d'un autre symbole.

Le symbole EURCAD s'ouvre si le prix est supérieur à 1,45117. 1.74425>1.45117 ? Oui, il est plus élevé mais c'est le prix d'un autre symbole.

Nous avons détecté 7 commandes erronées sur 500.

Je ne peux que spéculer que la demande de prix du symbole, la réponse est jetée dans une seule et même variable d'environnement. Juste une vérification rapide pour voir si elle est égale à la valeur précédente. Si c'est un autre symbole égale très rarement.

1...312431253126312731283129313031313132313331343135313631373138...3184
Nouveau commentaire
Raison: