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

Nouveau commentaire
 
FOReignEXchange:

Je vais certainement passer à autre chose quand le moment sera venu.

Bonne chance à vous
 
dentraf:

Bonne chance à vous !

Merci !
 
FOReignEXchange:

L'idée est d'opérer dans un marché désordonné à forte volatilité. Toutes les principales paires de devises sont comme ça maintenant. La volatilité est élevée, la logique et les systèmes ne fonctionnent pas. C'est le chaos. ....
Allez. Tout fonctionne comme avant.
 

Après la volatilité d'aujourd'hui, j'ai comparé les résultats du testeur avec les résultats réels. Malheureusement, des divergences importantes ont été révélées sur ce marché.

J'ai décortiqué les journaux du terminal à la minute près et j'ai vu une bonne chose. Tous les pips ont été fixés exactement à un point. Le robot a récolté tous les bénéfices qu'il pouvait sur ce secteur. Mais tout ce profit a été gaspillé, car il y avait un problème. Le problème est soluble, mais je n'arrive pas à comprendre pourquoi c'est un problème. Autrement dit, nous ne pouvons pas supprimer les commandes inutiles. Je pense qu'il y a deux raisons à cela.

Premièrement : Dans le journal, il est écrit ceci

22:23:30 '882613' : supprime l' ordre en attente #26344474 buy stop 4.00 EURUSD à 1.3787 sl : 1.3773 tp : 1.3799
22:23:30 '882613' : suppression de l'ordre en attente #26344474 buy stop 4.00 EURUSD à 1.3787 sl : 1.3773 tp : 1.3799 failed [Invalid parameters].

22:37:27 '882613' : supprime l'ordre en attente #26347980 sell stop 4.00 EURUSD à 1.3668 sl : 1.3682 tp : 1.3656
22:37:27 '882613' : suppression de l'ordre en attente #26347980 sell stop 4.00 EURUSD à 1.3668 sl : 1.3682 tp : 1.3656 failed [Invalid parameters].
22:37:27 '882613' : supprime l'ordre en attente #26347980 sell stop 4.00 EURUSD à 1.3668 sl : 1.3682 tp : 1.3656
22:37:28 '882613' : suppression de l'ordre en attente #26347980 sell 4.00 EURUSD at 1.3668 sl : 1.3682 tp : 1.3656 failed [Invalid parameters].

Ces deux ordres n'ont pas été supprimés et ils ont tous deux causé des pertes. La deuxième commande a essayé d'être supprimée deux fois. Je ne comprends pas pourquoi ils ne sont pas supprimés. Tout fonctionne bien toute la journée, mais ici ce n'est pas le cas, même si vous mettez RefreshRates() avant la fonction de suppression.

Et deuxièmement :

Je pense que c'est un bug. Il semble que le terminal n'ait pas assez de mémoire ou de cerveau. Il oublie que nous sélectionnons un ordre. Ce sont les pièces qui ne fonctionnent pas.

if (//Тут условие//)
   {
   if (OrderSelect(ticket_buy,SELECT_BY_TICKET)==true)
     {
     if (OrderType()==OP_BUYSTOP && Ask>(OrderOpenPrice()-4*Point)) 
        {
        i=0;
        while (i<10)
              {
              if (i>0) Sleep(500);      
              RefreshRates(); OrderDelete(ticket_buy); 
              err=GetLastError();
              if (err==0)
                 {
                 ticket_buy=0; return;
                 }
              i++;
              }
        }
     }
   }

Toutes les conditions sont remplies, je les ai vérifiées avec des commentaires. Au stade de la vérification du type de commande, tout se bloque. La fonction de suppression n'est plus utilisée. Bien qu'ils le devraient, puisque toutes les conditions sont remplies et que tous les commentaires les vérifient. Ce n'est pas la première fois que je remarque que lorsque nous sélectionnons un ordre et que nous entrons ensuite les paramètres de l'ordre sélectionné dans la condition, nous ne parvenons pas toujours à lire correctement cette condition. Plus le nombre de paramètres d'ordre dans la condition est élevé, plus la condition échoue souvent. Dans ce cas, nous avons les paramètres OrderType() et OrderOpenPrice(). Je pense que beaucoup d'entre nous ont remarqué cette chose étrange. Comment pouvons-nous nous en débarrasser ? Ou peut-être le problème réside-t-il dans quelque chose d'autre ? J'ai oublié de dire qu'il n'y a pas d'erreur dans le journal dans ce cas, juste que la condition n'est pas remplie, alors qu'elle devrait l'être.

Je pense qu'il n'y a peut-être pas de problème dans l'autre, car la condition n'est pas remplie rarement, habituellement tout fonctionne bien dans cette partie, mais parfois elle ne fonctionne pas et apporte des pertes.

Ne me jugez pas sévèrement pour un code aussi analphabète, je suis autodidacte.

Pourquoi exactement la suppression des ordres se produit-elle avec de tels problèmes ? Mes commandes sont passées exactement comme il faut et le robot recueille tous les bénéfices. Mais tout s'embrouille car nous ne pouvons pas supprimer les commandes inutiles ! Si vous vous débarrassez de ces problèmes, tout fonctionnera comme il se doit !

 
FOReignEXchange:

A en juger par le journal, le code n'est pas arrivé à temps.

C'est-à-dire que la suppression était déjà en cours lorsque l'ordre a été déclenché.

 
TheXpert:

A en juger par le journal, le code n'est pas arrivé à temps.

C'est-à-dire que la suppression était déjà en cours lorsque l'ordre a été déclenché.


Et les ordres en attente sont fixés exactement au même moment et ne sont pas manqués. Pourquoi y a-t-il un problème avec la suppression ? Surtout dans le second cas, il a essayé de le supprimer deux fois.
 
FOReignEXchange:
Et les ordres en attente sont fixés exactement au même moment et ne sont pas manqués. Pourquoi y a-t-il un problème avec la suppression ? D'autant plus que dans le second cas, il a essayé de le supprimer deux fois.

Regardez attentivement - c'est la deuxième fois que vous essayez de supprimer un ordre exécuté, et non un ordre limité.

Et pour la mise en place, il y a des niveaux d'arrêt et pour la suppression, il n'y a que des niveaux de liberté.

 
TheXpert:

Regardez attentivement - c'est la deuxième fois que vous essayez de supprimer un ordre exécuté, et non un ordre limité.

Et il y a des lignes d'arrêt pour passer une commande, mais seulement des freesliders à supprimer, et ce, s'il y en a.


Tout est clair avec le premier cas. Merci beaucoup ! Connaissez-vous le second ? Il est plus important car il se produit plus souvent et cause plus de pertes. Tout est OK en termes de conditions. Et ce n'est pas la vitesse du marché et il y a beaucoup de temps pour le supprimer. La condition n'est tout simplement pas remplie, alors qu'elle devrait l'être.
 
FOReignEXchange:

Connaissez-vous le second par hasard ? La condition ne fonctionne tout simplement pas, alors qu'elle devrait.

Peut-être que cette condition échoue parfois, à savoir que son côté droit

if (OrderType()==OP_BUYSTOP && Ask>(OrderOpenPrice()-4*Point))

Normaliser Demander avant de comparer.

 
OnGoing:

Peut-être que cette condition échoue parfois

Normaliser la demande avant de la comparer.


Comme ça ? 

NormalizeDouble(Ask,Digits)>(OrderOpenPrice()-4*Point))
1...232425262728293031323334353637...52
Nouveau commentaire