L'Apprentissage Automatique dans le trading : théorie, modèles, pratique et trading algo - page 2947

 
Aleksey Nikolayev #:

Très bien. Et quelles versions et quels opsets d'ONNX seront pris en charge ?

Tous ceux qui figurent dans le projet open source ONNX Runtime.

 
Renat Fatkhullin #:

Tout cela apparaît dans le projet open source ONNX Runtime.

onnx.defs.onnx_opset_version() écrit que opset=17. A propos de la version dans le MT log, il est écrit 1.14.0, bien que je pense que la dernière version d'ONNX est 1.13.1.

 
Aleksey Nikolayev #:

onnx.defs.onnx_opset_version() écrit que opset=17. A propos de la version, le journal MT indique 1.14.0, bien qu'il semble que la dernière version d'ONNX soit 1.13.1.

Non, c'est exact. Il s'agit de la dernière version d' ONNX 1.13.1, et de la dernière version d'ONNX Runtime 1.14.1.

 
Renat Fatkhullin #:

L'ensemble des fonctions permettant d'accéder aux graphiques, aux encoches, aux positions de négociation et à l'historique des transactions est présenté ci-dessus. Il est suffisant pour le travail direct des scripts python.

Nous ajouterons peut-être l'accès aux indicateurs.

Le transfert d'indicateurs n'est pas une méthode universelle, bien qu'elle soit probablement suffisante pour la plupart des traders. Par exemple, je suis plus intéressé par la transmission de données non pas sur chaque barre, mais au moment où les niveaux sont cassés. Quelqu'un s'intéresse à autre chose, etc.

Il n'est guère possible de créer un mode d'échange idéal qui conviendrait à tout le monde, de sorte que les méthodes à béquille au stade du développement sont inévitables. L'essentiel est d'éviter les méthodes de béquille au stade du lancement dans un testeur ou sur un VPS.

 

J'ai testé le projet ONNX.Price.Prediction dans la nouvelle version de MT5 b3601. Tout semble fonctionner - entraînement et sortie en python, sortie dans MT5 (j'ai supprimé la dll pour onnx de la racine et redémarré le terminal).

Nous pouvons attendre la sortie de la nouvelle version et commencer à essayer avec nos propres modèles)

 
Aleksey Nikolayev #:

La transmission des indicateurs n'est pas une méthode universelle, bien qu'elle soit suffisante pour la plupart des traders. Par exemple, je suis plus intéressé par la transmission de données non pas sur chaque barre, mais au moment où les niveaux sont franchis. Quelqu'un s'intéresse à autre chose, etc.

Il n'est guère possible de créer un mode d'échange idéal qui conviendrait à tout le monde, de sorte que les méthodes à béquille sont inévitables au stade du développement. L'essentiel est d'éviter les méthodes de béquille au stade du lancement dans un testeur ou sur un VPS.

La question du passage d'indicateurs et de données arbitraires (par exemple, des chaînes) en python affecte les intérêts commerciaux de MetaQuotes.
. .

Si tout cela est résolu, MT se transforme d'un intermédiaire entre un courtier et un client en un simple outil pratique pour écrire des stratégies et des indicateurs.

MT fournit des cotations tout en étant très rapide et fiable - un excellent élément à intégrer dans un système de négociation. Permettre à une chaîne de caractères d'être transmise à Python signifie consolider ce rôle du terminal.

Par exemple, crypto a dépassé MT parce que le courtier dans crypto est un élément superflu et inutile, mais cela n'annule pas l'utilisation du terminal pour l'écriture et l'utilisation d'experts-conseils.

Pour faire simple : écrire un EA => l'exécuter sur BTCUSD => trader sur Binance via un script Python => remercier MetaTrader de l'avoir.

 

Je ne comprends pas pourquoi vous avez besoin de toutes ces choses avec ONNX.

Il y a un scénario de base évident pour faire de MT5 et MO des amis :
1. A partir de OnInit() démarrez le script python comme un processus séparé.
2. Vous avez besoin de quelques fonctions d'échange d'informations entre python et EA, dans le mode où EA peut attendre des informations.
3. Créez un dossier Models et mettez-y les modèles TensorFlow.

C'EST TOUT !!! L'intégration de MT et MO a eu lieu ! Tout le monde est content.

 
Evgeny Dyuka #:

Je ne comprends pas pourquoi toutes ces fantaisies avec ONNX en premier lieu.

Il y a un scénario de base évident pour faire de MT5 et MO des amis :
1. A partir de OnInit() le script python est démarré comme un processus séparé.
2. Nous avons besoin de quelques fonctions d'échange d'information entre python et EA, dans le mode où EA peut attendre que l'information arrive.
3. Nous créons un dossier Models et y plaçons des modèles TensorFlow.

C'EST TOUT ! !! L'intégration de MT et MO a eu lieu ! Tout le monde est content.

Il existe une telle intégration avec R. Seulement, il n'est pas clair pourquoi R est nécessaire sur VPS et pourquoi vous avez besoin de problèmes pour supporter son intégration avec MT (contrôle de version du langage et des paquets, etc.). Il en sera de même avec Python.

Il y a aussi un point lié à la vitesse, qui est très importante dans notre activité. Regardez comment fxsaber grappille des millisecondes dans une bataille constante avec les méta-citations qui se transforment en points de profit. Il est évident qu'une combinaison de n'importe quoi avec n'importe quoi fonctionnera plus lentement que les deux programmes pris isolément.

Il semblerait qu'il n'y ait rien de plus évident.....

 
Aleksey Nikolayev projet ONNX.Price.Prediction dans la nouvelle version de MT5 b3601. Tout semble fonctionner - entraînement et sortie en python, sortie dans MT5 (j'ai supprimé la dll pour onnx de la racine et redémarré le terminal).

Nous pouvons attendre la sortie de la version et commencer à essayer avec nos propres modèles)

Une béquille en moins, la gamme de modèles utilisés sera grandement élargie (avant cela, la plupart des gens optimisaient les poids à travers les entrées du terminal). Apparemment ça devrait fonctionner sur mac aussi, je vérifierai bientôt :) parfois il vaut mieux ne rien faire et attendre que la nourriture vole d'elle même dans la bouche
 
Aleksey Nikolayev #:

Une telle intégration existe avec R. Seulement, il n'est pas clair pourquoi R est nécessaire sur VPS et pourquoi nous avons des problèmes pour supporter son intégration avec MT (contrôle de la version du langage et des paquets, etc.). Il en sera de même pour Python.

Il y a aussi un point lié à la vitesse, qui est très importante dans notre activité. Regardez comment fxsaber grappille des millisecondes dans une bataille constante avec les méta-citations qui se transforment en points de profit. Il est évident qu'un paquet de n'importe quoi avec n'importe quoi fonctionnera plus lentement que les deux programmes seuls.

Il semblerait qu'il n'y ait rien de plus évident.....

J'entends tout le temps cette légende sur l'importance de la vitesse, mais je n'arrive pas à comprendre en quoi elle est importante.
En tenant compte du spread et des commissions des bourses/courtiers, il faut prévoir pour le temps mesuré en dizaines de minutes ou en heures. Quel est le rapport avec une différence de 50 millisecondes ?
En quoi le fait que MQ batte fxsaber de 5 millisecondes vous aide-t-il dans la vie réelle ?