Réunir une équipe pour développer un OI (arbre/forêt de décision) en relation avec les stratégies de tendance. - page 18
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
L'équipe est donc annulée. )
Et il y aura un groupe administré. )
Administrer même une équipe déjà établie a 95% de chances de tuer le résultat.
Et pour administrer quelque chose qui n'existe pas encore, il faut avoir un atout très puissant. ))
Il est temps de montrer des atouts.
Il y a une offre, mais aucune expression de la demande sous quelque forme que ce soit.
Si, à ce stade, les membres potentiels de l'équipe ne sont pas disposés à être proactifs, je ne suis pas sûr de leur motivation.
C'est très malheureux.
Sans administration, on ne peut pas avancer - j'ai proposé un système où les participants choisissent eux-mêmes la direction du voyage, il est difficile d'imaginer les conditions les plus confortables.
De cette liste, même les républicains de GitLab ne se sont pas inscrits...
L'équipe aurait dû être construite sous la licence Apache 2.0 dès le départ, et vous vouliez forcer des étrangers à se conformer à l'éthique coopérative.
Eh bien, le patron ne connaît rien du tout au développement de logiciels.
L'inscription est une question de minutes, ce n'est qu'une formalité.
L'équipe doit travailler dans son intérêt et dans celui de tous ses membres, et non pas se moquer de l'humeur.
Développer des idées et les coder sont des choses différentes.
L'enregistrement est une question de minutes ; ce n'est qu'une formalité.
L'équipe doit travailler dans son intérêt et dans celui de tous ses membres, et non pas faire la fine bouche quand elle en a envie.
Développer des idées et les coder sont des choses différentes.
S'il s'agit d'un "travail minutieux", pourquoi n'est-il pas fait ? Il n'y a pas d'espace de travail parce qu'il n'y a pas d'équipe. Il n'y a pas d'équipe parce qu'il n'y a pas d'espace de travail...
Et dans ce domaine, l'idée doit être mise en œuvre immédiatement, au moins en pseudo-code.
Si c'est une "affaire de minute", pourquoi n'est-ce pas fait ? Il n'y a pas d'espace de travail parce qu'il n'y a pas d'équipe. Il n'y a pas d'équipe parce qu'il n'y a pas d'espace de travail...
Et dans ce domaine, l'idée doit être mise en œuvre immédiatement, au moins en pseudo-code.
L'équipe n'existe pas parce que les gens ne veulent pas travailler ensemble ; tout le monde (la plupart d'entre eux) est intéressé à entendre les idées des autres, et le format proposé par Maxim - le salon de discussion - est parfait pour cela.
Peut-être qu'au stade actuel de la méfiance et de la peur de révéler leurs propres idées est une variante de la communication d'intérêt.
Avant de faire quelque chose, vous devez comprendre à quoi cela ressemblera au final - il devrait y avoir un plan. J'ai suggéré que les gens expriment leurs opinions sur l'organisation du processus de travail - comment ils le veulent, comment ils le voient, et qu'ils organisent ensuite l'espace de travail en tenant compte de ces souhaits.
Citoyens - tout est entre nos mains !
Le marché n'est pas un lieu pour résoudre des problèmes psychologiques personnels, mais un champ pour générer des revenus !
Tu ne peux pas déplacer ce truc tout seul.
Alors, tout est mélangé - le moteur du forum est-il multifonctionnel ? J'ai lu des articles sur REST, mais il s'agit d'une architecture nue, dois-je chercher le code source d'un forum ?
Comment ça, vous pouvez jouer d'autres scripts, où pouvez-vous les jouer ? Imaginez que vous voulez vendre le produit à un utilisateur ordinaire et expliquer en termes humains ce qu'il apporte et ce qui va avec, s'il vous plaît. Je pense que c'est nécessaire et important, mais je ne vois pas pourquoi, merci.
Qu'est-ce qu'il y a à expliquer ? Plus haut, je vous ai montré un exemple de la façon d'accéder, à partir d'un script MQL, à Python installé sur l'ordinateur local, de former un modèle de réseau neuronal, de le sauvegarder dans un fichier, de le charger et de l'utiliser en appelant la méthode Predict.
https://www.mql5.com/ru/forum/261479/page16#comment_8011085
Vous pouvez utiliser le même modèle pour créer l'un des centaines de modèles IO disponibles dans les bibliothèques python et l'entraîner sur vos données. En utilisant le même exemple, vous pouvez créer une partie client dans un EA ou un indicateur, qui chargera le fichier modèle lors de l'initialisation, puis l'interrogera en appelant la méthode Predict avec vos propres données actuelles.
La prise en charge des protocoles NamedPipes et REST permet aux scripts, conseillers experts ou indicateurs spécifiés de fonctionner sans DLL avec les modèles MO, tant sur l'ordinateur local qu'à distance sur le réseau.
Contrairement à NamedPipes, lors de l'utilisation du script REST, le texte de MQL ne doit pas être envoyé par FileWriteString, mais par WebRequest vers une URL publique, par exemple sur le VPS où le moteur tourne, sinon c'est pareil.
Qu'est-ce qu'il y a à expliquer ? Plus haut, je vous ai montré un exemple de la façon d'appeler un script MQL vers Python installé sur l'ordinateur local, de former un modèle de réseau neuronal, de le sauvegarder dans un fichier, de le charger et de travailler avec lui en appelant la méthode Predict.
https://www.mql5.com/ru/forum/261479/page16#comment_8011085
En utilisant le même modèle, vous pouvez créer n'importe lequel des centaines de modèles MO disponibles dans les bibliothèques Python et les entraîner sur vos données. En utilisant le même modèle, vous pouvez créer une partie client dans un conseiller expert ou un indicateur, qui chargera le fichier modèle pendant l'initialisation, puis l'interrogera en appelant la méthode Predict avec ses propres données actuelles.
La prise en charge des protocoles NamedPipes et REST permet aux scripts, conseillers experts ou indicateurs spécifiés de fonctionner sans DLL avec les modèles MO, tant sur l'ordinateur local qu'à distance sur le réseau.
Contrairement à NamedPipes, lors de l'utilisation du script REST, le texte de MQL ne doit pas être envoyé par FileWriteString, mais par WebRequest vers une URL publique, par exemple sur le VPS où le moteur tourne, sinon c'est pareil.
En général, c'est clair, un outil pour activer un modèle calculé.
Mais je ne comprends toujours pas comment gérer l'optimiseur de stratégie...
Je vais laisser mes réflexions sur les arbres, au cas où elles seraient utiles.
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading
L'apprentissage automatique en trading : théorie et pratique (Trading and Beyond)
Aleksey Vyazmikin, 2018.07.10 14:18
Hier, une réflexion m'a traversé l'esprit : pourquoi recherchons-nous des arbres de décision, c'est-à-dire un modèle décrivant une entité ? Par exemple, pourquoi avons-nous besoin de décrire l'entité dans son ensemble ? Peut-être devrions-nous simplement chercher les parties de cette entité qui sont les plus compréhensibles et prévisibles ? J'ai pensé que puisque je collecte des feuilles d'arbres, je devrais peut-être utiliser une méthode pour trouver ces feuilles sans construire un arbre de décision complet, ce qui devrait, si je comprends bien, donner une augmentation de la qualité pour le même temps de calcul passé.
J'ai cherché sur Internet et je ne vois pas cette méthode nulle part. Peut-être quelqu'un connaît-il de tels développements ?
Pendant que je travaille sur l'algorithme, je pense que je dois d'abord sélectionner les prédicteurs, qui montrent la capacité prédictive d'une des classes, à cela les prédicteurs doivent être rendus binaires (pour cela je dois former mon propre échantillon pour chaque prédicteur ou former des marges d'exclusion de l'échantillon général (ce qui est plus raisonnable ?)). Ensuite, on utilise déjà les prédicteurs sélectionnés (et leurs combinaisons) pour construire des stubs pour une classe particulière (dans mon cas 3 classes), puis on utilise ces stubs pour construire les prédicteurs restants. En même temps, nous pouvons aussi vérifier s'ils sont préférés à une certaine classe. Ensuite, selon l'idée, nous trouverons les zones qui se prêtent le mieux à la classification pour les classes cibles spécifiques. Et la zone restante sera juste un champ d'inactivité/attente.
Bien sûr, nous pouvons alors voir où les feuilles sont superposées et faire un résultat moyen dans ces cas. Et nous pouvons construire un arbre comme cela, mais avec des éléments de vote en raison de la densité dans différentes zones de différentes cibles.
Que pensez-vous de cette idée ?
Je vais laisser mes réflexions sur les arbres au cas où elles seraient utiles.
Beaucoup expriment ici des pensées - des idées, certains proposent des mécanismes - des algorithmes et même parfois des réalisations - des programmes prêts à l'emploi, mais malheureusement il n'y a pas de progrès, pas de résultats pratiques, tout se termine essentiellement par des inondations et des déclarations non fondées.
C'est peut-être parce que nous ne disposons pas d'une présentation unifiée des outils d'OI - le format des données, les modèles et l'évaluation objective des résultats, ce qui ne nous permet pas de communiquer entre nous de manière constructive, de partager les résultats des expériences et de tirer des conclusions raisonnables.
Et quel est l'intérêt d'une telle situation si nous ne disposons pas de méthodes d'évaluation objective, même d'un exécutant individuel - un développeur).
Peut-être devrions-nous commencer par créer et nous mettre d'accord sur de telles méthodes ; il y a eu une tentative de soulever cette question dans le fil de discussion MoD, mais jusqu'à présent il n'y a pas eu de compréhension mutuelle ; peut-être que vous, en tant que passionné de ce sujet, pouvez faire quelque chose ?
De nombreuses personnes expriment ici leurs pensées - des idées, certaines proposent des mécanismes - des algorithmes et parfois même en viennent à la mise en œuvre - des programmes prêts à l'emploi, mais malheureusement il n'y a pas de progrès, pas de résultats pratiques, tout se termine le plus souvent par des inondations et des déclarations sans fondement.
C'est peut-être parce que nous ne disposons pas d'une présentation unifiée des outils d'OI - le format des données, les modèles et l'évaluation objective des résultats, ce qui ne nous permet pas de communiquer entre nous de manière constructive, de partager les résultats des expériences et de tirer des conclusions raisonnables.
Et quel est l'intérêt d'une telle situation si nous ne disposons d'aucune méthode d'évaluation objective d'un exécutant, même individuel - un développeur).
Peut-être devrions-nous commencer par créer et nous mettre d'accord sur de telles méthodes. Une tentative a été faite pour soulever cette question dans le fil de discussion MoD, mais jusqu'à présent, il n'y a pas eu de compréhension mutuelle ; peut-être pouvez-vous, en tant que passionné de ce sujet, faire quelque chose ?
Je suis d'accord pour dire que les évaluations standard ne sont pas adaptées, j'ai déjà écrit à ce sujet. Cela est particulièrement évident si nous parlons d'une stratégie de tendance. Il est préférable de rechercher des critères d'évaluation optimaux sur une stratégie de base, puis de les porter sur d'autres stratégies. D'après moi, la branche MO essaie surtout de prédire comment le bar va fermer à son ouverture. Et la métrique supposé/non supposé peut encore être appropriée dans ce cas, mais même dans ce cas, sans parler des stratégies de tendance, les points doivent également être pris en compte dans l'estimation.
Dans l'image ci-dessous, les points d'entrée dans le carré 1 seront bien meilleurs (apporteront plus de profit) que dans le carré 2 où il y aura un profit, tandis que dans le carré 3 nous fermerons avec une perte lorsque l'actif est vendu, mais il n'apportera pas de profit lorsque l'actif est acheté jusqu'à ce que le prix minimum soit formé.
Vous pouvez donc voir que le pourcentage d'erreur d'entrée peut être important, mais si cette valeur importante est plus concentrée dans la deuxième case que dans la première, la valeur plus faible des erreurs peut recouvrir la totalité du bénéfice.
C'est pourquoi je veux maintenant prendre en compte dans mon évaluation du modèle la concentration des signaux, dans quelle zone ils donnent plus de profit ou de perte et en tenir compte lors de la construction de l'arbre de décision.