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

Nouveau commentaire
 
borilunad:

1) Normaliser toutes les conditions et actions ;


Vous devez également normaliser le lot s'il change et/ou est calculé. Quoi d'autre est possible ?
 
FOReignEXchange:

1) Vous devez normaliser les arrêts lorsqu'ils sont calculés séparément. Ceci est écrit dans l'aide. Pourquoi normaliser quelque chose d'autre qui n'a pas besoin d'être normalisé ? Soit 150 décimales. S'il n'affecte rien, il n'est pas nécessaire de le normaliser. Voici un code, par exemple.

Pourquoi devrions-nous normaliser a et b ? Je ne peux pas le comprendre. Il s'agit bien sûr d'un exemple simplifié. Mais le fait est que si vous avez affaire à des mathématiques dans votre code, pourquoi devriez-vous tout normaliser ? Seuls les tops doivent être normalisés s'ils sont obtenus à la suite de telles mathématiques.

2) J'ai vérifié les conditions à plusieurs reprises. Je suis en train de le vérifier. J'ai peut-être raté quelque chose.

3) Seulement 2 erreurs se produisent dans mon code. Erreur 130 - mauvais stops, et paramètres non valides lors de la suppression d'un ordre en attente. Tout est clair avec le premier et j'ai réglé le problème. Les paramètres désactivés pour la suppression des ordres en attente sont également clairs.

4) Nous n'avons pas le temps d'ouvrir des positions sans SL et TP, car nous fixons le profit minimum et il peut ne pas être fixé plus tard, car le prix évolue rapidement. Selon toute apparence, la quatrième règle est née du fait qu'il était auparavant impossible d'ouvrir des positions avec des stops à l'aide des terminaux BROKO. Maintenant vous pouvez. Je ne vois donc pas l'intérêt de cette règle.


Comme je le vois, vous savez mieux que quiconque...

Continuer comme ça, y compris l'erreur dans les stops et la suppression du pendentif, armé jusqu'aux dents de SL et TP, malgré l'importance à proximité immédiate du prix, et ne pas voir l'intérêt de tout le reste !

Le temps nous le dira et remettra tout à sa place !

 
FOReignEXchange:

Vous devez également normaliser le lot s'il change et/ou est calculé. Que pouvez-vous faire d'autre ?

Bien sûr ! Et tout ce qui concerne les calculs relatifs à l'évolution rapide des normes de VC dans les conditions du marché.
 
borilunad:


Comme je le vois, vous savez mieux que quiconque...

Continuez le bon travail, y compris l'erreur dans les arrêts et le retrait du pendule, armé jusqu'aux dents de SL et TP, malgré l'importance à proximité du prix, et ne voyant pas l'intérêt dans tout le reste !

Le temps montrera et mettra tout à sa place !


L'essentiel est que le code dans la vie réelle fonctionne et s'exécute sans problème. Tout le reste n'est pas important.

Faute STOPPING en raison de l'obsolescence des prix. Erreur 130. Le fait de réessayer répare tout. Il n'y a aucun problème à ce sujet. Il n'y a plus d'erreurs dans le journal.

Nous devons juste comprendre pourquoi les conditions de suppression des commandes ne sont pas remplies et c'est tout. La question annoncée dans le titre du sujet sera résolue.

 

FOReignEXchange:

La question annoncée dans le titre du sujet serait terminée.

Cela signifierait également une augmentation de la caution, la même que celle du testeur).

Je ne pense pas qu'il y ait un point sur le graphique où l'on puisse en toute confiance fixer une prise 11 et un stop 15 et savoir qu'il ira à la prise).

Pas un singe, pas un casier, vous ouvrez des positions individuelles, si je comprends bien.

Il n'y a pas de telle règle, surtout lorsque vous entrez à l'ouverture d'une bougie. C'est de la fantaisie et de la fiction. Le prix ne doit rien à personne. Il ne revient pas en arrière, là où nous l'avons prévu, ni n'avance, parce que nous l'avons décidé. Peu importe l'indicateur super-duper qui nous le montre.

 
FOReignEXchange:


L'essentiel est que le code fonctionne dans la vie réelle et qu'il soit fluide. Tout le reste est sans importance.

L'erreur réelle s'arrête à cause de l'obsolescence des prix. Erreur 130. Le fait de réessayer répare tout. Il n'y a aucun problème à ce sujet. Il n'y a plus d'erreurs dans le journal.

Nous devons juste comprendre pourquoi les conditions de suppression des commandes ne sont pas remplies et c'est tout. La question annoncée dans le titre du fil de discussion sera terminée.


Désolé, encore une précision ! Tous les paramètres changeants doivent être rafraîchis à partir de MarketInfo() au départ.

Et le glissement doit être d'au moins 20 sur 5 chiffres(Erreur 130).

Dans le testeur, ni eux ni les autres ne sont modifiés, donc le moins que je puisse faire est de me fier aux splendides résultats du test.

 
borilunad:


Désolé, encore une précision ! Tous les paramètres DC changeants doivent être rafraîchis à partir de MarketInfo() au départ.

Dans le testeur, ni eux ni les autres ne sont modifiés, donc je fais moins confiance aux beaux résultats du test.


Quels paramètres ? Seuls l'offre et la demande doivent être modifiés, et c'est tout. De même, MODEFREEZELEVEL est la seule chose utile que j'ai entendue aujourd'hui. Merci encore.

Quels autres paramètres du CC peuvent changer ? Une variation minimale du prix par paliers, ou

Niveau minimum de stop loss/stack profit en pips
ou
Nombre de chiffres après la virgule dans le symbole prix.
ou
Taille du pip dans la devise de la cotation

L'écart peut varier, mais je ne l'ai jamais remarqué sur l'Euro. Comment cela va-t-il l'affecter ? Dans mes conditions, cela peut n'affecter que la possibilité de placer un ordre en attente. Si

OrderOpenPrice()=Bid+MODE_SPREAD)= inférieur à la distance acceptable, l'ordre ne sera pas ouvert. Je suis conscient de cela. Mais nous n'avons jamais eu de telles erreurs.

 
FOReignEXchange:


Quels paramètres ? Seuls l'offre et la demande doivent être modifiés, c'est tout. De même, MODEFREEZELEVEL est la seule chose utile que j'ai entendue aujourd'hui. Merci encore.

Quels autres paramètres le DC peut-il modifier ? S'agit-il d'une étape minimale de changement de prix ou

Niveau minimum autorisé de stop loss/stake profit en pips
ou
Nombre de chiffres après la virgule dans le prix de l'instrument
ou
Taille d'un pip dans la devise de cotation

L'écart peut varier, mais je ne l'ai jamais remarqué sur l'Euro. Comment cela va-t-il l'affecter ? Dans mes conditions, cela peut n'affecter que la possibilité de placer un ordre en attente. Si

OrderOpenPrice()=Bid+MODE_SPREAD)= inférieur à la distance acceptable, l'ordre ne sera pas ouvert. Je suis conscient de cela. Mais nous n'avons jamais eu de telles erreurs.


Voir : https://docs.mql4.com/ru/constants/marketinfo à partir de Bid à votre FritzLevel "utile", en augmentant dans les périodes de volatilité extrême. Également StopLevel, etc.

Bid+Spread=Ask Donc, il est préférable d'utiliser Ask tout de suite dans ce cas, bien sûr, si Ask est aussi essayé par MarketInfo() au début du démarrage.

 

Désolé, je dois m'absenter un moment !

J'ai, par exemple, au début et après avoir affiné le lot, selon le MM :

  RefreshRates();
  ASK = NormalizeDouble(MarketInfo(Symbol(),MODE_ASK),Digits);
  BID = NormalizeDouble(MarketInfo(Symbol(),MODE_BID),Digits);
  double spread = NormalizeDouble(ASK-BID,Digits);
  StopLevel = NormalizeDouble(MarketInfo(Symbol(),MODE_STOPLEVEL),Digits);
  double step = NormalizeDouble(Step*Point,Digits);
  if(step < StopLevel) step = StopLevel;
Et puis tout le reste...
 

Sur ce code, j'ai mis le suivant

if (//Условие//)
   {
   if (OrderSelect(ticket_sell,SELECT_BY_TICKET)==true)
      if (OrderType()==OP_SELLSTOP) 
         {
         Print ("Заморозка: ",MarketInfo (Symbol(), MODE_FREEZELEVEL),", Bid: ",Bid,", Open=",OrderOpenPrice());
         if (Bid<=(OrderOpenPrice()+4*Point)) 
            {
            Comment ("1");                         
            i=0;
            while (i<10)
               {
               if (i>0) Sleep(500);      
               RefreshRates(); OrderDelete(ticket_sell); 
               err=GetLastError();
               if (err==0)
                  {
                  ticket_sell=0; return;
                  }
               i++;
               }
            }
         }
   }

18:34:14 $505,000 EURUSD,M1 : Freeze : 0, Bid : 1.3436, Open=1.3436
18:34:14 505 000 $ EURUSD,M1 : l'ordre de marché #26398219 ne peut être supprimé
18:34:14 505 000 $ EURUSD,M1 : l'ordre de marché #26398219 ne peut être supprimé
18:34:15 505 000 $ EURUSD,M1 : L'ordre de marché #26398219 ne peut être supprimé
18:34:15 505 000 $ EURUSD,M1 : l'ordre de marché #26398219 ne peut être supprimé
18:34:16 505 000 $ EURUSD,M1 : l'ordre de marché #26398219 ne peut être supprimé
1834:16 505 000 $ EURUSD,M1 : ordre de marché #26398219 ne peut être supprimé
18:34:17 505 000 $ EURUSD,M1 : ordre de marché #26398219 ne peut être supprimé
18:34:17 505 000 $ EURUSD,M1 : ordre de marché #26398219 ne peut être supprimé
18:34:18 505 000 $ EURUSD,M1 : ordre de marché #26398219 ne peut être supprimé
18:34:19 505 000 $ EURUSD,M1 : ordre de marché #26398219 ne peut être supprimé

Il a échoué 10 fois. Autant de fois que le i-cycle. Dans ce cas, il n'a tout simplement pas eu le temps de le supprimer, car le cours acheteur était déjà égal au prix d'ouverture de l 'ordre. C'est la première fois que je remarque un tel cas. Je vais essayer d'en trouver un autre. Celui-là a fonctionné du bon côté. La déviation du signal de quelques fractions de seconde n'est pas horrible. Je pense qu'il y a un autre cas, je vais l'attendre. Il y a des moments où il n'y a pas de réaction pendant 10-15 secondes.

1...282930313233343536373839404142...52
Nouveau commentaire
Raison: