Le conseiller est-il adapté à la vie réelle ? - page 31

Nouveau commentaire
 
Oui, essayez.
 
OnGoing:
Je ne sais pas, ouais, essaye quand même.

Je ne sais pas. Bien qu'elle puisse être non normalisée, la condition sera toujours remplie. Vous devez normaliser les arrêts après les calculs, s'il y en a.
 
FOReignEXchange:

Je ne sais pas. Bien qu'il puisse s'agir d'une sorte de non-normalisation, la condition sera toujours remplie. Vous devez normaliser les arrêts après les calculs, s'il y en a.
Lorsque la différence entre Ascom et la valeur comparée n'est pas très importante, le nombre de décimales compte et la condition échoue souvent.
 

Pour une raison quelconque, je pense que nous devrions le faire. 

   if (OrderSelect(ticket_sell,SELECT_BY_TICKET)==true)
      {
      if (OrderType()==OP_SELLSTOP) 
         {
         if (Bid<(OrderOpenPrice()+4*Point)) 
            {

J'ai l'impression que 2 conditions à la fois ne peuvent parfois pas être lues. Je vais essayer de le mettre. Il semble qu'il y ait un bug dans le langage.

Je vais essayer de faire la même chose avec la normalisation.

Peut-être quelqu'un a-t-il déjà rencontré de tels problèmes ?

 

Non, les deux fonctionnent. Il est plus probable que les valeurs ne soient pas indiquées dans la comparaison.

Essayez de retracer les valeurs que vous obtenez à chaque étape.

 
OnGoing:

Non, les deux fonctionnent. Il est plus probable que les valeurs ne soient pas indiquées dans la comparaison.

Essayez de retracer les valeurs que vous obtenez à chaque étape.


J'ai déjà vérifié avec les commentaires. J'ai même mis un commentaire avant cette condition. Le signal va jusqu'à cette ligne, mais il ne va pas plus loin. Et cela arrive rarement. 2 à 4 fois par jour. Le reste du temps, tout fonctionne correctement. J'ai vérifié toutes les valeurs dans les commentaires lorsque la commande n'a pas été supprimée. Il aurait dû être supprimé, mais il n'a pas atteint la fonction de suppression. Le signal est allé jusqu'à cette condition et pas au-delà.
 
Putain d'idiot. J'ai oublié de dire la chose la plus importante. Tout fonctionne bien dans le testeur. C'est là le problème. Si la commande n'a pas été supprimée dans le testeur, je ne m'en préoccuperais pas. Mais il n'est pas supprimé dans le compte réel et il est supprimé dans le testeur si la visualisation est activée après une transaction. C'est pourquoi je pense que cela ressemble à une sorte de bug dans le langage. J'ai l'impression qu'il ne peut pas supprimer beaucoup de données de l'ordre sélectionné. Ce n'est pas la première fois que je rencontre ce problème. Pour être plus exact, j'y ai été confronté tout le temps. Tout est OK dans le testeur, mais pas dans la vie réelle.
 
Maintenant, j'ai allumé la visualisation et je la regarde. Il y a une énorme marge de temps pour le retrait. Une demi-minute presque. Dans le testeur, il a supprimé et aujourd'hui sur le compte de démonstration, il n'a même pas essayé de supprimer et a ouvert une transaction de saumon :)
 

Affiche les valeurs qui ne sont pas devant la condition, mais exactement les expressions qui sont à l'intérieur de la condition. Contrôlez ce qui est comparé à quoi. Ainsi, la prochaine fois qu'une telle défaillance se produira, vous serez en mesure d'en saisir la cause.

Après tout, nous savons que la condition est défaillante. Nous devons donc découvrir pourquoi. Pour ce faire, toutes les valeurs comparées doivent être contrôlées en permanence.

 

J'ai déjà fait tout ça. Je suis maintenant de retour à la visualisation d'un autre endroit où la commande n'a pas été supprimée. Chaque fois que j'ai coché la case, j'ai regardé les commentaires sur l'état des lieux. Tout y est correct et le testeur a supprimé la commande. Et le temps pour le supprimer était de 10-15 secondes.

J'ai consulté les journaux du compte de démonstration pendant cette période et il n'y a eu aucune tentative de suppression de l'ordre. Le testeur l'a fait, mais pas le compte de démonstration. J'ai essayé de mettre des commentaires avant et après les conditions, à la fin du code et au début du code, tout à la fois. Toutes les conditions sont remplies, mais je ne suis pas allé plus loin que cela. Nous n'avons même pas essayé de supprimer la commande ! Nous avons tout le temps de le supprimer, mais ce n'est pas une question de temps puisque nous n'avons même pas essayé de le faire. Il n'y a pas eu non plus de sauts sur 2-3 tics. La condition ne passe pas à la fonction de suppression et c'est tout.

Ok, je vais essayer une autre option - définir ces conditions avec chaque nouvelle ligne séparément. Je verrai ce qui se passe demain. Pour le premier problème, j'ai en quelque sorte deviné comment le résoudre. Demain, je verrai comment le code mis à jour se comportera.

1...242526272829303132333435363738...52
Nouveau commentaire