ATcl - Interprète Tcl pour MT4 - page 6

Nouveau commentaire
 
Maxim Kuznetsov:

En termes de technologie logicielle, potentiellement oui. Les bibliothèques peuvent être appelées depuis l'optimiseur tant qu'elles ne sont pas dans le nuage.

du côté de la Nouvelle-Zélande - comment l'imaginez-vous ?

Dans l'optimiseur, un passage est effectué et les données sont écrites dans le fichier, puis elles sont passées à la formation du réseau, après la formation, les résultats de l'évaluation de la formation sont renvoyés à MT4/5 et le réseau (règles) est écrit dans le fichier. Et l'autre vue est celle où nous utilisons les fichiers enregistrés de la logique NS pour effectuer une optimisation (des variantes NS) et corriger les indicateurs standards de TS.

 

J'ai étendu la démo du graphique Tk - maintenant il montre aussi le tableau des commandes.

Tableau des commandes dans une fenêtre séparée

Le code MQL qui fait référence à la table des commandes
- sélectionne tous ses ordres et les envoie à tcl dans la méthode OnOrderList
- dans le résultat, nous obtenons 3 listes de tickets : les nouveaux, ceux qui ont été modifiés et ceux qui ont été supprimés.

void
SendOrderList() 
{
   int total=OrdersTotal();
   Tcl_Obj list=tcl.Ref(tcl.Obj()); // пустой список
   for(int pos=0;pos<total;pos++) {
      if (!OrderSelect(pos,SELECT_BY_POS,MODE_TRADES) ||
         OrderMagicNumber()!=MAGIC ||
         OrderSymbol()!=_Symbol ||
         OrderCloseTime()!=0) continue;
      Tcl_Obj ord=tcl.Ref(tcl.List(
         tcl.Obj(OrderTicket()),
         tcl.Obj(OrderType()),
         tcl.Obj(OrderOpenTime()),
         tcl.Obj(OrderSymbol()),
         tcl.Obj(OrderLots()),
         tcl.Obj(OrderOpenPrice()),
         tcl.Obj(OrderStopLoss()),
         tcl.Obj(OrderTakeProfit()),
         tcl.Obj(OrderComment()),
         tcl.Obj(OrderSwap()),
         tcl.Obj(OrderCommission())
      ));
      tcl.AppendObj(list,ord);
      tcl.Unref(ord);
   }
   if (tcl.Call(panel,methodOnOrderList,list)!=TCL_OK) {
      PrintFormat("OrderSendList failed : %s",tcl.StringResult());
   } else {
      Tcl_Obj triplet=tcl.Ref(tcl.Result()); // 0-новые 1-изменённые 2-удалённые
      Tcl_Obj created=tcl.Ref(tcl.Index(triplet,0));  // список новых ордеров
      Tcl_Obj changed=tcl.Ref(tcl.Index(triplet,1));  // список изменённых ордеров
      Tcl_Obj removed=tcl.Ref(tcl.Index(triplet,2));  // список удалённых ордеров
      PrintOrderList("New orders",created);
      PrintOrderList("Modified orders",changed);
      PrintOrderList("Deleted orders",removed);
      // объекты больше ненужны
      tcl.Unref(removed);
      tcl.Unref(changed);
      tcl.Unref(created);
      tcl.Unref(triplet);
   }
}

et la méthode Tcl qui fait le travail principal :
- obtient une nouvelle liste de commandes
- comparer avec les appels précédents
- construit 3 listes (nouveau, modifié, supprimé).
- il crée un tableau ...qui est en fait un arbre et qui peut être fait en plusieurs niveaux.


# надо обновить внутренние структуры
# и вернуть триплет (список из трёх списков)
#   1 - список новых ордеров
#   2 - ордера которые поменялись
#    3 - ордера которые удалены
method OnOrderList { orderList } {
    set created {}
    set changed {}
    set removed {}
    foreach order $orderList {
        set ticket [ lindex $order 0 ]
        set known($ticket) $order
        if { ! [ info exists Orders($ticket) ] } {
            # новый тикет
            # добавить в список свежесозданных
            lappend created $ticket
            set Orders($ticket) $order
            continue
        }
        if { $Orders($ticket) != $order } {
            # что-то поменялось
            # добавить в список изменённых
            set Orders($ticket) $order
            lappend changed $ticket
        }
    }
    foreach ticket [ array names Orders ] {
        if { ! [ info exists known($ticket) ] } {
            # прежнего ордера нет в новом списке - значит удалён
            lappend removed $ticket
            unset Orders($ticket)
        }
    }
    # обновить грфику :-)
    foreach ticket $removed {
        my OnRemoveOrder $ticket
    }
    foreach ticket $changed {
        my OnChangeOrder $ticket
    }
    foreach ticket $created {
        my OnCreateOrder $ticket
    }
    return [ list $created $changed $removed ]
}

tout est très compact.
Vous pouvez utiliser les points forts des deux langages : MQL est proche de l'environnement commercial et compte rapidement dans les tableaux,
Tcl peut facilement gérer les listes et les hachages.
MQL met en œuvre un algorithme de négociation robuste tandis que les scripts gèrent l'interaction avec le monde et l'utilisateur.

L'archive est jointe.

Dossiers :
atcl.zip  6662 kb
 

Un script pour exporter des devis vers Excel

J'ai créé un petit script pour exporter les devis directement vers Excel.
Sans aucune entrée dans le CSV ni aucun paramètre - il suffit de le lancer sur le graphique, la feuille Excel s'ouvre et toutes les cotations y sont copiées.

J'ai commenté le texte autant que possible et l'ai joint. J'ai fourni les détails du script sur mon site web http://nektomk.ru/atcl:ratestoexcel.
Le volume va au-delà du forum, donc voilà. Peut-être que lorsque je serai d'humeur, je le reproduirai dans le blog local afin que l'information ne soit pas perdue pour sûr.

Le script ci-joint

PS/ Est-ce que quelqu'un a un fichier make - pour la compilation par lot de mql ? qui changera un mqh, poussera make et reconstruira un tas de mq4 qui sont listés dans les dépendances....

mise à jour/ duplication de l'article sur le blog local https://www.mql5.com/ru/blogs/post/718304 - maintenant il ne va probablement pas disparaître
RatesToExcel
  • nektomk.ru
Часто возникающий (и довольно практичный) вопрос у пользователей MetaTrader - «Как скопировать котировки в Excel?» . При помощи библиотеки ATcl это программируется довольно легко. В состав библиотеки входит «большая» программа работающая с Excel, но для частых потребностей сделал короткий скрипт, который делает самую простую вещь - экспорт...
Dossiers :
RatesToExcel.mq4  12 kb
 

Le mailer fonctionne, mais il doit encore être amélioré...

En attendant, une question pour les gens - le GUI-Builder sera-t-il demandé ?
pour Tk, ils sont là, mais du fait que les scripts en texte s'écrivent plus vite qu'en dessin, ils sont peu demandés.

quelque chose comme ça :

PS/ le résultat d'un tel GUI-builder peut être lancé depuis MT4...

 
Maxim Kuznetsov:

le mailer fonctionne, mais il a encore du travail à faire...

mais en attendant, une question pour les gens - y aura-t-il une demande pour les GUI-Builder ?
pour Tk, ils le sont, mais en raison du fait que les scripts sont plus rapides à écrire en texte qu'en dessin, ils ne sont pas très demandés.

quelque chose comme ça :

PS/ le résultat d'un tel GUI-builder et maintenant avec l'aide de "telle et telle mère" peut être lancé à partir de MT4...

Quels trucs intéressants... seulement comment les appliquer ?

Ah, j'ai une idée pour les interfaces graphiques seulement - créer une logique de trading comme un arbre de décision ! C'est-à-dire créer un arbre dans l'éditeur graphique (c'est-à-dire le shell) et utiliser un bouton pour le convertir en règles simples, ou même directement en code ! Cependant, les règles peuvent également être lues en code de manière très compacte.

Pourquoi en avons-nous besoin ? Cette approche permet de détailler la stratégie de trading, par exemple, nous pouvons facilement la diviser en séries temporelles - non seulement décider de trader ou non, mais aussi de trader à tel moment et à tel autre de manière différente. Les signes d'un changement de tactique sont nombreux et variés, mais il n'est pas très pratique de l'écrire dans le code et, deuxièmement, il est difficile à lire visuellement - vous pouvez faire beaucoup d'erreurs.

Une telle idée vous intéresse pour mettre en œuvre vos talents ?

 
Aleksey Vyazmikin:

Quels trucs intéressants... mais comment les appliquer ?

Ah, j'ai une idée pour les interfaces graphiques seulement - créer une logique de trading comme un arbre de décision ! C'est-à-dire que nous créons un arbre dans l'éditeur graphique (c'est-à-dire le shell) et utilisons un bouton pour le convertir en règles simples ou même directement en code ! Cependant, les règles peuvent également être lues en code de manière très compacte.

Pourquoi en avons-nous besoin ? Cette approche permet de détailler la stratégie de trading, par exemple, nous pouvons facilement la diviser en séries temporelles - non seulement décider de trader ou non, mais aussi de trader à tel moment et à tel autre de manière différente. Les signes d'un changement de tactique sont nombreux et variés, mais il n'est pas très pratique de l'écrire dans le code et, deuxièmement, il est difficile à lire visuellement - vous pouvez faire beaucoup d'erreurs.

Une telle idée d'application de vos talents vous intéresse ?

Je ne comprends pas l'idée d'un "arbre de décision graphique". :-) peut-être que votre talent n'est pas suffisant :-)

 
Maxim Kuznetsov:

Je ne comprends pas du tout l'idée de "l'arbre de décision graphique". :-) peut-être que vous n'êtes pas assez talentueux :-)

Imaginez un tableau de données avec un ensemble de règles



Ces règles sont organisées en code de la manière suivante

      for(int i=1;i<StrokTotal_Buy; i++)
        {
         UslovieSumm_Buy=
                          Sravnenief(arr_Vektor_Week,arrRead_Buy_01[i])+
                          Sravnenief(arr_Vektor_Day,arrRead_Buy_02[i])+
                          Sravnenief(arr_Vektor_Don,arrRead_Buy_03[i])+
                          Sravnenief(arr_DonProc,arrRead_Buy_04[i])+
                          Sravnenief(arr_iDelta_H1,arrRead_Buy_05[i])+
                          Sravnenief(arr_iDelta_H3,arrRead_Buy_06[i])+
                          Sravnenief(arr_iDelta_H4,arrRead_Buy_07[i])+
                          Sravnenief(arr_iDelta_H6,arrRead_Buy_08[i])+
                          Sravnenief(arr_iDelta_H12,arrRead_Buy_09[i])+
                          Sravnenief(arr_iDelta_D1,arrRead_Buy_10[i])+
                          Sravnenief(arr_iDelta_W1,arrRead_Buy_11[i])+
                          Sravnenief(arr_iDelta_MN1,arrRead_Buy_12[i])+
                          Sravnenief(arr_RSI_Open_M1,arrRead_Buy_13[i])+
                          Sravnenief(arr_RSI_Open_H1,arrRead_Buy_14[i])+
                          Sravnenief(arr_BB_Center_Open,arrRead_Buy_15[i])+
                          Sravnenief(arr_BB_Up_Open,arrRead_Buy_16[i])+
                          Sravnenief(arr_BB_Down_Open,arrRead_Buy_17[i])+
                          Sravnenief(arr_TimeH,arrRead_Buy_18[i])+
                          Sravnenief(arr_Den_Nedeli,arrRead_Buy_19[i])+
                          Sravnenief(arr_iDelta_Max_H1,arrRead_Buy_20[i])+
                          Sravnenief(arr_iDelta_Min_H1,arrRead_Buy_21[i])+
                          Sravnenief(arr_iDelta_Max_D1,arrRead_Buy_22[i])+
                          Sravnenief(arr_iDelta_Min_D1,arrRead_Buy_23[i]);                                                                              
;




         if(UslovieSumm_Buy==23)
           {
            Pattern_Buy=1;
            Pravilo_Buy=i;
            break;
           }
        }

Si une valeur de la règle et une valeur calculée (valeur de l'indicateur/heure/autre modèle) coïncident, une action commerciale est exécutée, par exemple.

Cette méthode de décisions commerciales est très compacte et polyvalente - nous pouvons coder de manière aussi simple, par exemple, de nombreuses stratégies - en leur donnant différents symboles magiques.

Mais le problème est que nous avons besoin d'un environnement adapté à ce style de programmation. Cet environnement devrait ressembler à un arbre de décision (un schéma fonctionnel primitif) où nous pouvons créer des blocs (résultat de calcul par exemplearr_iDelta_Max_D1 avec des valeurs prédéfinies (1,2,3,4 ...n) et/ou avec la possibilité de limiter les valeurs de et à, créant ainsi de nombreux groupes différents), à partir de ce bloc se ramifiera pour chaque valeur de variable ou plage de valeurs de variable, et ainsi de suite jusqu'au bloc suivant et ainsi de suite. Nous aurons donc un ensemble de règles, dont chacune, soit dit en passant, ne doit pas nécessairement utiliser tous les blocs.

Est-ce que cela vous fait comprendre ? Si vous avez besoin d'explications, n'hésitez pas à demander.

 
Aleksey Vyazmikin:

Présenter un tableau de données avec un ensemble de règles



Ces règles sont codées comme suit

En cas de coïncidence entre les valeurs de la règle et les valeurs calculées (valeur de l'indicateur/heure/autre modèle), une action commerciale est exécutée, par exemple.

Cette méthode de décisions commerciales est très compacte et polyvalente - nous pouvons coder de manière aussi simple, par exemple, de nombreuses stratégies - en leur donnant différents symboles magiques.

Mais le problème est que nous avons besoin d'un environnement adapté à ce style de programmation. Cet environnement devrait ressembler à un arbre de décision (un schéma fonctionnel primitif) où nous pouvons créer des blocs (résultat de calcul par exemplearr_iDelta_Max_D1 avec des valeurs prédéfinies (1,2,3,4 ...n) et/ou avec la possibilité de limiter les valeurs de et à, créant ainsi de nombreux groupes différents), à partir de ce bloc se ramifiera pour chaque valeur de variable ou plage de valeurs de variable, et ainsi de suite jusqu'au bloc suivant et ainsi de suite. Nous aurons donc un ensemble de règles, dont chacune, soit dit en passant, ne doit pas nécessairement utiliser tous les blocs.

Est-ce que cela vous fait comprendre ? Si vous avez besoin d'explications, n'hésitez pas à demander.

Comme Xcos (http://www.scilab.org/en/scilab/features/xcos) et autres fantaisies similaires dans les simulations ?
Je l'ai vu en tcl - un environnement où ils connectent des blocs avec des flèches... c'est comme ça qu'ils programmaient le traitement du son/vidéo/graphique. http://wiki.tcl.tk/8565 semble être un tas de choses, ils ont même collé Maxima dans un certain bloc
Si c'est le cas, je serai très attentif.
Xcos / Features / Scilab / Home - Scilab
Xcos / Features / Scilab / Home - Scilab
  • Scilab Enterprises
  • www.scilab.org
Xcos is a graphical editor to design hybrid dynamical systems models. Models can be designed, loaded, saved, compiled and simulated.
 
Maxim Kuznetsov:
Comme Xcos (http://www.scilab.org/en/scilab/features/xcos) et les modes similaires dans les simulations ?
Je l'ai vu dans l'environnement tcl - où ils relient les blocs avec des flèches... c'est comme ça qu'ils programmaient le traitement du son/vidéo/graphique. http://wiki.tcl.tk/8565 semble être beaucoup de choses, ils ont même collé Maxima dans certains blocs
Si c'est le cas, je serai très attentif.

Oui, c'est la bonne approche ! L'essentiel est de ne pas compliquer les choses, et de faire un interpréteur correct, de sorte que tous les blocs soient rassemblés en une seule ligne (une branche), avec laquelle le programme en MQL fonctionnera déjà.

 
Aleksey Vyazmikin:

Oui, c'est la bonne approche ! L'essentiel est de ne pas compliquer les choses, et de faire un interpréteur correct, de sorte que tous les blocs soient rassemblés en une seule ligne (une branche), ce qui fonctionnera déjà avec le programme en MQL.

Je ne pense pas vouloir compliquer à l'excès, par exemple, je ne veux pas m'embrouiller avec le code bwise.

Tout au plus, je l'adapterai pour l'utiliser avec ATcl (i.e. transférer les données de Mql à ses entrées) et prendre les sorties.
Bien sûr, je vais devoir écrire un HowTo "comment dessiner des carrés et les attacher à l'EA". Et pratiquez l'anglais lorsque vous communiquez avec l'auteur ou les auteurs :-)

12345678910
Nouveau commentaire