L'apprentissage automatique dans la négociation : théorie, modèles, pratique et algo-trading - page 665
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Absolument la bonne approche.
Absolument la mauvaise approche en ce moment. Votre approche était correcte lorsque le MT et le Quick fonctionnaient aux mêmes vitesses.
Maintenant, MT dépasse Quick de 100 fois.
Et d'ailleurs, les programmes qui fonctionnent sur toutes sortes de paquets sont optimisés pour un calcul unique, alors que MT utilise plus souvent des calculs en continu.
Par exemple, R calcule R comme la somme de N points divisée par N. Alors qu'en MT, seul le premier point est compté de cette manière, les autres sont comptés en deux étapes, le dernier non inclus dans le nouveau calcul est soustrait, un nouveau calcul est ajouté.
Donc R n'est utile que pour le développement, beaucoup de possibilités, et qui sait quoi appliquer. Et lorsque le développement sera terminé (même pas, lorsque les expériences seront terminées) et que les algorithmes de CT seront décidés, tout devrait être transféré à Mql.
Moins de passerelles, moins de problèmes.
.... et les algorithmes de CT ont été décidés, tout doit être traduit en Mql.
Lorsque les gens écrivent de telles choses, cela signifie une chose : ils n'ont pas la moindre idée du problème.
Lorsque les gens écrivent de telles choses, cela signifie une chose : ils n'ont pas la moindre idée du problème...
Le problème est que les gens d'aujourd'hui sont tellement habitués aux langages de haut niveau qu'ils ne comprennent même pas comment implémenter la même fonction de densité de probabilité dans des opérations arithmétiques.
Le problème, c'est que les gens d'aujourd'hui sont tellement habitués aux langages de haut niveau qu'ils ne comprennent même pas comment mettre en œuvre la même fonction de densité de probabilité dans des opérations arithmétiques.
Eh bien, disons que je le fais. Supposons. Je peux ne pas le comprendre - cela n'a pas d'importance.
Je ne comprends pas pourquoi il est nécessaire de mettre en œuvre.... ? Et, en principe, il n'est pas nécessaire de comprendre - il n'est absolument pas nécessaire de connaître la structure et la théorie des circuits d'une bouilloire électrique pour y faire bouillir de l'eau et l'utiliser.
Disons que je comprends. Disons que je le fais. Je peux ne pas comprendre - cela n'a pas d'importance.
Je ne comprends pas pourquoi il est nécessaire d'implémenter.... ? Et, en principe, il n'est pas nécessaire de comprendre - il n'est absolument pas nécessaire de connaître la structure et la théorie des circuits d'une bouilloire électrique pour y faire bouillir de l'eau et l'utiliser.
Pour faire bouillir de l'eau au même endroit tout le temps, il vaut mieux brancher la prise jusqu'à la table ou utiliser une douzaine de rallonges connectées les unes aux autres et installées derrière le réfrigérateur, derrière la chaise ou à travers la salle de bains, avec plein d'autres appareils branchés, etc. J'espère que l'idée est claire.
Option 1 : EA écrit en mql, exécuté sur un VPS et oublier les problèmes.
Option 2 : Avoir assemblé l'intégration du hérisson et de l'horrible, mis sur un ordinateur à domicile (c'est généralement un homme dur), bien, sur un VPN à distance pour trois fois le prix, et chaque jour tremblant échoué ou non.
Option 2 : Construire une intégration de hérisson, la mettre sur votre ordinateur à la maison (ce qui est une douleur dans le cul), ok sur un VPN à distance pour trois fois le prix, et chaque jour vous secouez et secouez pour voir si elle échoue ou non.
C'est bon. Il y a ça aussi. Je ne peux pas vraiment m'absenter lorsque le système fonctionne et qu'un contrôle est nécessaire. Et c'est un problème. Il peut y avoir des problèmes avec l'UPU aussi, mais moins - c'est entendu.
Mais je préfère avoir un hérisson avec un hérisson. Je n'ai pas une bonne idée de la manière de réaliser le système au moyen d'un seul MKUL et du temps et des efforts que cela demanderait. Il y a beaucoup de logiciels externes - de la base de données aux clients IP, sans parler de la fonctionnalité de tapis externe. Et il n'est tout simplement pas réaliste de tout faire avec un seul MCL, ni même possible avec une UPU.
SZY Je devrais dire que ce n'est pas un problème de l'épingler au même C++/C#.
C'est bon. Il y a aussi ça. Je ne peux pas vraiment m'absenter quand le système fonctionne et qu'il faut contrôler. Et c'est un problème. Avec l'UPU, il peut y avoir des problèmes aussi, mais moins - c'est d'accord.
Mais je préfère avoir un hérisson avec un hérisson. Je n'ai pas une bonne idée de la manière de réaliser le système au moyen d'un seul MKUL et du temps et des efforts que cela demanderait. Il y a beaucoup de logiciels externes - de la base de données aux clients IP, sans parler de la fonctionnalité de tapis externe. Et il n'est tout simplement pas réaliste de faire tout cela avec un seul MCL, enfin, ce n'est même pas possible avec l'UPU.
Mais je ne nie pas que c'est difficile.
Option 1 : écrire l'EA en mql, l'exécuter sur le VPS et oublier les problèmes.
C'est la principale chose qui fait que vous faites tout avec mql seulement.
R à utiliser pour la vitesse, car l'alglib sera des dizaines de fois plus lent à apprendre.