Erreurs, bugs, questions - page 3129

Nouveau commentaire
 
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 ?


Dans quelle langue la syntaxe est-elle différente ? "La syntaxe signifie littéralement non seulement composer, mais aussi arranger...".

Si vous voulez vérifier s'il y a un 'array out of range', changez l'ordre.

if(Array[over_index]>val && a) {...}
 
Lilita Bogachkova #:

Dans quelle langue la syntaxe est-elle différente ?"La syntaxe signifie littéralement non seulement composer, mais aussi ordonner...".

Si vous voulez vérifier s'il y a un 'array out of range', changez l'ordre.

La commande est souhaitable car vous devez vérifier.

Par exemple, si "a" est modifié plus souvent, il est préférable de le mettre comme premier argument.

 
Vitaly Muzichenko #:

L'ordre est souhaitable car les contrôles sont nécessaires.

Par exemple, si "a" change plus souvent, il est préférable de le mettre comme premier argument.

Non, la première dépend des conditions principales, les autres ne sont que des conditions supplémentaires.

Par exemple, il n'est pas pertinent de vérifier l'heure de la durée du travail en cours si la durée du travail n'a pas encore commencé.
 

En fait, je suis tombé sur cette fonctionnalité par hasard. Ce n'est pas ce que je voulais...

if(high[i]>high[i+1] && high[i]>high[i+2] && high[i]>high[i+3] && ... && high[i]>high[i+n])

ou

if(high[i]>high[i+1])
   if(high[i]>high[i+2])
      if(high[i]>high[i+3])
         if(...)
            if(high[i]>high[i+n])

L'ennui, c'est que n peut être assez grand, et j'ai donc voulu résumer cette longue chaîne de conditions en une formule compacte. J'ai essayé de cette façon :

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) {...}
   ...
}

mais ça s'est avéré être un peu le bordel. Au moins parce que h_plus, avec cet algorithme, devra prendre la somme totale des conditions vérifiées, y compris la condition avec la vérification redondante du tableau d'indices, ce qui ne se produisait pas dans le premier if déballé, sans for. Et d'autres vernis gâchent le tableau.

Cela vaut-il la peine d'être envisagé ? Est-il possible de le faire ?

 
Lilita Bogachkova #:

Dans quelle langue la syntaxe est-elle différente ? "La syntaxe signifie littéralement non seulement composer, mais aussi ordonner...".

Si vous voulez vérifier s'il y a un "tableau hors limites", changez l'ordre.

On ne sait pas toujours à l'avance ce qu'il faut mettre avant et ce qu'il faut mettre après.

 
Lilita Bogachkova #:

Non, la première détermine les conditions de base, les autres ne sont que des conditions supplémentaires.

Par exemple, il n'est pas pertinent de vérifier l'heure de la durée du travail en cours si la durée du travail n'a pas encore commencé.

Oui, nous vérifions d'abord les conditions du signal, nous parcourons le tableau et nous le comparons, nous vérifions le prix actuel, puis il s'avère que ce n'est pas le bon moment, mais avant cela, beaucoup d'actions compliquées sont effectuées.

N'est-ce pas ?

 
Vitaly Muzichenko #:

Oui, nous vérifions d'abord les conditions du signal, nous parcourons le tableau et nous comparons, nous vérifions le prix actuel, et ensuite il s'avère que le moment n'est pas le bon, mais beaucoup d'actions compliquées ont été faites avant cela.

N'est-ce pas ?

C'est vrai, tu ne devrais pas faire ça.
 
Vitaly Muzichenko #:

Vérifiez

Qui vous a dit que "a" de la condition ci-dessus serait toujours faux ?

 
x572intraday #:

En fait, je suis tombé sur cette fonctionnalité par hasard. Ce n'est pas ce que je voulais...

ou

L'ennui, c'est que n peut être assez grand, et j'ai donc voulu résumer cette longue chaîne de conditions en une formule compacte. J'ai essayé de cette façon :

mais ça s'est avéré être un peu le bordel. Au moins parce que h_plus, avec cet algorithme, devra prendre la somme totale des conditions vérifiées, y compris la condition avec la vérification redondante du tableau d'indices, ce qui ne se produisait pas dans le premier if déballé, sans for. Et d'autres vernis gâchent le tableau.

Cela vaut-il la peine d'être envisagé ? Est-il possible de faire un dépassement ?

Voici ce code que je ne comprends pas du tout

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) {...}
   ...
}

Que signifie le signe & dans ce code ? Et dans quelle boucle faut-il exécuter if(h_plus) ? Vous n'avez pas manqué de crochets courbés ?

 
Alexey Viktorov #:

Je ne comprends pas du tout ce code.

Que signifie le & mis en évidence dans ce code ? Et dans quelle boucle faut-il exécuter if(h_plus) ? Tu n'as pas manqué de crochets courbés ?

En MQL, un bool est vrai s'il est supérieur à 0. Dans d'autres langues, une valeur booléenne est vraie uniquement si elle est égale à 1.

1...312231233124312531263127312831293130313131323133313431353136...3184
Nouveau commentaire