Erreurs, bugs, questions - page 479

 
Puis écrivez à Servicedesk et joignez le code.
 
sergeev:

Puis écrivez au Service Desk et joignez le code.

Oui, il est préférable d'écrire au Service Desk en joignant le code expert.

Ne vous inquiétez pas pour le code - nous effaçons tout après les tests. Notre principale et unique tâche est de trouver des erreurs.

 

Une autre question. J'utilise la fonction CopyTime. Appelez :

CopyTime("EURUSD", PERIOD_MN1, D'2011.06.30', D'2011.08.01', Array)

ne renvoie qu'un seul élément avec la valeur D'2011.08.01' pour une raison quelconque. Où est D'2011.07.01' en fait ? Quelle est l'astuce ?

P.S. Array[] est un tableau dynamique.

 
marketeer:

Une autre question. J'utilise la fonction CopyTime. Appelez :

ne renvoie qu'un seul élément avec la valeur D'2011.08.01' pour une raison quelconque. Où est D'2011.07.01' en fait ? Quel est le piège ?

P.S. Le tableau Array[] est dynamique.

Oui, pour une raison quelconque, le premier élément est ignoré, écrivez à servicedesk.

datetime Array[];
   CopyTime("EURUSD", PERIOD_MN1, D'2011.06.01', D'2011.08.01', Array); 
   for(int i=0;i<ArraySize(Array);i++)
     {
      Print(i," ",Array[i]);
     }

1 2011.08.01 00:00:00

0 2011.07.01 00:00:00

 
marketeer:

Une autre question. J'utilise la fonction CopyTime.

Il existe déjà une application similaire.

J'ai compris.

 

Voici un autre mystère. Je n'arrive pas à attraper le virus - je ne sais pas si c'est le mien ou celui du terminal.

Il existe un code trivial qui compte le nombre d'ordres placés par l'Expert Advisor. Le compteur est stocké dans des variables globales. Ça ressemble à ça :

int Count;

int OnInit()
{
  Count = (int)GlobalVariableGet("Count");
  return(0);
}

void OnTick()
{
  // bla-bla-bla
  if(успешно отправлен ордер)
  {
    Count++;
    if(!MQL5InfoInteger(MQL5_TESTING))
    {
      if(GlobalVariableSet("Count", Count) == 0)
      {
        Print("GlobalVariableSet error ", GetLastError());
      }
    }
  }
}

Ce compte est utilisé dans les commentaires de commande. Par conséquent, je remarque parfois que le prochain numéro d'ordre est inférieur (de quelques unités) au nombre de positions qui sont déjà sur le marché. Il n'y a pas d'erreurs dans le journal.

Vous avez une idée ? Peut-être que quelqu'un a rencontré une "disparition" similaire des dernières valeurs des variables globales, par exemple à cause de leur non-sauvegarde par le terminal lors de la sortie sous certaines conditions (enfin, peut-être dans le cas où la connexion est perdue - juste une version) ?

Документация по MQL5: Глобальные переменные терминала / GlobalVariableGet
Документация по MQL5: Глобальные переменные терминала / GlobalVariableGet
  • www.mql5.com
Глобальные переменные терминала / GlobalVariableGet - Документация по MQL5
 
marketeer:

Voici une autre énigme. Je n'arrive pas à attraper le virus - je ne sais pas si c'est le mien ou celui du terminal.

Essayez quelque chose comme ça. Je ne l'ai pas vraiment fait au niveau mondial. Mais ça compte bien.

    int Amount_Orders = 0;

    for(count = 0; count < OrdersTotal(); count++)
       {  
        if(OrderSelect(OrderGetTicket(count))) 
          {
           int tp_ord = (ENUM_ORDER_TYPE)OrderGetInteger(ORDER_TYPE);  
           if(tp_ord == ORDER_TYPE_BUY_STOP  || tp_ord == ORDER_TYPE_SELL_STOP ||
              tp_ord == ORDER_TYPE_BUY_LIMIT || tp_ord == ORDER_TYPE_SELL_LIMIT)
           Amount_Orders++;  
          }
       }
 
tol64:

Essayez quelque chose comme ça. Je ne l'ai pas vraiment fait au niveau mondial. Mais ça compte bien.

Mon problème est que la valeur écrite dans la variable globale est perdue, c'est-à-dire pas complètement (comme lors de la suppression par le timeout mensuel), mais l'ancienne valeur reste. Vous pouvez bien sûr recalculer les ordres, mais ma méthode devrait également fonctionner.
 
papaklass:

Aux développeurs :

Est-il prévu que si un ordre est clôturé avant son heure d' expiration, cela ne soit en aucun cas suivi par OnTrade ?

PS : L'objectif du gestionnaire d'événements de transaction OnTrade n'est pas clair du tout. Si un stop loss ou take n'est pas attrapé, si un ordre en attente est fermé avant son heure d'expiration, il n'est pas attrapé. Nous devons tout revérifier pendant l'exécution de l'algorithme. Cette approche est source de confusion car nous nous fions au gestionnaire de l'événement commercial, mais nous devons le revérifier. D'autant plus qu'après une double vérification, nous attrapons les événements qui ne sont pas traités par OnTrade(). Pourquoi est-ce nécessaire ? Mais maintenant, nous pouvons jouer au tétris et dessiner toutes sortes d'absurdités sur des graphiques. Les développeurs, s'il vous plaît, amenez la partie trading de la plateforme à sa conclusion logique.

Je ne peux rien dire sur les commandes en cours, je n'ai pas encore travaillé avec elles.

Par exemple, c'est le gestionnaire OnTrade qui envoie ces lignes dans le journal :

2011.08.08 09:03:05 ChTestExp (EURUSD,H1) Position longue par EURAUD à fermer de stop-loss
2011.08.08:09:03:05 ChTestExp (EURUSD,H1) -----------------Deal #5263582 [sl 1.37819]
2011.08.08 09:03:05 ChTestExp (EURUSD,H1) oldDealsTotal=558 newDealsTotal=559
 
papaklass:

Mettez la fonction Print(__FUNCTION__) dans la fonction OnTrade(). Et quand vous l'aurez dans votre journal

stop loss triggered buy 0.10 AUDUSD 0.89783 sl : 0.89544 tp : 0.90024 [#15 sell 0.10 AUDUSD at 0.89544]
transaction #7 vendre 0.10 AUDUSD à 0.89544 fait (basé sur l'ordre #15)
transaction effectuée [#7 vendre 0.10 AUDUSD à 0.89544].
ordre exécuté sell 0.10 at 0.89544 [#15 sell 0.10 AUDUSD at 0.89544]

Pouvez-vous vérifier si OnTrade() a fonctionné ?

Pour moi, tout fonctionne même sans votre insertion, car toutes les transactions, leurs volumes, leurs profits sont calculés, tout est additionné et affiché dans OnDeinite pour chaque symbole séparément. Comme tous les paramètres additionnés (nombre de transactions, bénéfice) coïncident exactement avec le rapport du testeur, je n'ai aucune raison de douter de OnTrade().

La seule chose qui n'est pas traitée dans OnTrade(), ce sont les transactions de fermeture de position à la fin du test (avec le commentaire 'end of test') et la fermeture par un stop out dans le testeur (commentaire 'so ...'), en mode test, nous devons les traiter en plus dans OnDeinit. Extrait du journal de bord du testeur :

2011.08.09 00:06:43 Core 1 fichier journal "E:\Program Files\MetaTrader 5\Tester\Agent-127.0.0.1-3000\logs\20110809.log" écrit
2011.08.09 00:06:43 Core 1 EURUSD,H1 : 888296 ticks (275 barres) générés en 13962 ms (total des barres dans l'historique 6479, temps total 16177 ms)
2011.08.09 00:06:43 Core 1 arrêt sur 8% de l'intervalle de test
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Deinit fin
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Tout Profit = -9072.04
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Total des transactions : 17
.....
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 ----------------------------------------
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Bénéfice total EURGBP = -4738.97
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Bénéfice de la semaine EURGBP = 319.68
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Bénéfice total GBPUSD = -3775.86
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Bénéfice de la semaine GBPUSD = -1798.83
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Bénéfice total EURUSD = -557.21
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Bénéfice de la semaine EURUSD = 65.85
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Balance=927.96 Equite=927.96 Profit=0.00 MarginLevel=0.00
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 ---------------Report-------------------
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Balance=10000.00 Equite=927.96 Profit=0.00 MarginLevel=0.00
2011.08.09 00:06:43 2011.01.18 10:11:00 Core 1 Erreurs d'ouverture : 1 Erreurs de fermeture : 0 Erreurs de modification : 0 Requotes : 1
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Temps d'exécution : 0 min. 14 sec.
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 ChTestExp Expert Advisor a terminé son travail sur le graphique EURUSD, période H1
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Désinit Exécution
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 OnDeinit_UninitReason = Une autre raison
2011.08.09 00:06:43 Core 1 Résultat OnTester 0
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 ordre acheter 1.65 à 1.59804 [#69 acheter 1.65 GBPUSD à 1.59804]
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 transaction effectuée [#68 acheter 1.65 GBPUSD à 1.59804].
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 deal #68 buy 1.65 GBPUSD at 1.59804 done (based on order #69)
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 position fermée en raison de la fin du test à 1.59804 [vendre 1.65 GBPUSD 1.57341182 tp : 1.57247].
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 ordre d'achat 0.45 à 0.83931 [#68 achat 0.45 EURGBP à 0.83931]
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 ordre exécuté [#67 acheter 0,45 EURGBP à 0,83931].
2011.08.09 00:06:43 2011.01.18 10:11:00 deal #67 acheter 0.45 EURGBP à 0.83931 fait (basé sur l'ordre #68)
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 position stop déclenchée à 29.09% [sell 0.45 EURGBP 0.83930333 tp : 0.80463]
2011.08.09 00:06:43 Core 1 2011.01.17 14:39:39 Position longue par EURUSD à fermer de stop-loss
2011.08.09 00:06:43 Core 1 2011.01.17 14:39:39 -----------------Deal #66 sl 1.32900

2011.08.09 00:06:43 Core 1 2011.01.17 14:39:39 oldDealsTotal=65 newDealsTotal=66

D'après le rapport du testeur :

Résultats
Qualité de l'histoire : 100%
Barres : 275 Tiki : 888296
Bénéfice net : -9 072.04 Bénéfice total : 1 652.29 Perte totale : -10 724.33
Rentabilité : 0.15 Le gain attendu : -533.65
Facteur de récupération : -0.92 Ratio de Sharpe : -0.35

Réduction du bilan :
Réduction absolue du bilan : 9 072.04 Prélèvement maximal sur le bilan : 10 392.34 (91.80%) Tirage relatif par bilan : 91.80% (10 392.34)
Prélèvement de fonds :
Retrait absolu dans les fonds : 9 072.04 Retrait maximal des fonds : 9 852.02 (91.39%) Retrait relatif des fonds : 91.39% (9 852.02)

Total des échanges : 17 Transactions courtes (% des gagnants) : 10 (70.00%) Transactions longues (% de gains) : 7 (85.71%)
Total des échanges : 67 Transactions rentables (% de toutes les transactions) : 13 (76.47%) Transactions à perte (% de toutes) : 4 (23.53%)

Le commerce le plus rentable : 263.25 La plus grosse transaction perdante : -5 036.39

Moyenne des transactions rentables : 127.10 Moyenne des transactions perdantes : -2 681.08

Nombre maximum de gains continus (profit) : 10 (1 320.30) Nombre maximum de pertes continues (perte) : 2 (-4 084.59)

Nombre maximum de bénéfices continus (nombre de gains) : 1 320.30 (10) Perte continue maximale (nombre de pertes) : -5 036.39 (1)

Gains moyens continus : 4 Pertes moyennes en continu : 1


Comme vous pouvez le voir, les chiffres totaux, calculés indépendamment, coïncident, cela signifie que tout est correct. J'ai fait exprès de retirer l'exemple du stop.
Raison: