L'Apprentissage Automatique dans le trading : théorie, modèles, pratique et trading algo - page 3348
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
Non, il n'y a pas de problème. La marge bénéficiaire importe peu. Ce qui compte, c'est l'erreur de classification. Elle augmente lorsque l'on ajoute de la diffusion à la formation ou reste inchangée.
Mais le modèle ne commence pas à mieux fonctionner lorsque le spread est pris en compte dans la majoration, il ne donne pas de bénéfice, mais sans le spread, il fonctionne de la même manière que s'il avait été entraîné sans lui. C'est pourquoi j'ai ajouté l'écart, de manière conditionnelle, à l'erreur de classification. C'est-à-dire que la réponse du modèle ne vous permet pas de le battre.
La prise en compte de l'écart dans la majoration signifie la longueur des transactions qui le dépassent. En d'autres termes, j'allonge les transactions, puis je les entraîne, et le résultat du test sur l'écart accru est presque le même que le résultat d'un autre modèle entraîné sur des transactions plus courtes.
Il s'avère que c'est une conclusion assez claire que sur mes signes, disons, MO ne peut pas battre l'écart.
Mais parfois, c'est possible, avec certaines machinations liées au kozul. En d'autres termes, s'il existe un indicateur statistique de la "fiabilité" déduite des signaux, ceux-ci fonctionnent également lorsque le spread augmente.
Lecalcul des bénéfices n'a pas d'importance,ce qui compte, c'est l'erreur de classification.
Grâce à cette approche, vous classez "correctement" les transactions potentiellement perdantes. En réalité, la situation est bien pire, et pas seulement à cause du spread. Dans un véritable EA, passer d'une classification "correcte" à un système rentable reste un problème, ce qui n'est pas surprenant.
Peu importela marge bénéficiaire, ce quicompte, c'estl'erreur de classification qui s'ensuit.
Grâce à cette approche, vous classez "correctement" les transactions potentiellement perdantes. En réalité, la situation est bien pire, et pas seulement à cause du spread. Dans un véritable EA, passer d'une classification "correcte" à un système rentable reste un problème, ce qui n'est pas surprenant.
Tout d'abord, la majoration est rendue aussi rentable que possible. Ensuite, les exemples "fiables" sont rééchantillonnés et filtrés sur la base des erreurs de modèle, le reste étant considéré comme des déchets. Car il est clair qu'il n'y aura jamais de transaction aussi idéale qu'avec la majoration initiale du graal (sans spread, il s'agira presque d'un graal). La rentabilité baisse à un certain niveau, la stabilité sur les nouvelles données augmente. Un équilibre entre ceci et cela est choisi.
Cela semble logique et pas si vague que d'autres justifient leur TS.
J'ai décrit la variante la plus facile à comprendre dans l'article, vous pouvez la vérifier vous-même, le cœur de l'algorithme est simple.
Tout d'abord, la majoration est rendue aussi rentable que possible. Ensuite, les exemples "fiables" sont rééchantillonnés et filtrés sur la base des erreurs de modèle, le reste étant considéré comme des déchets. Car il est clair qu'il n'y aura jamais de transaction aussi idéale qu'avec la configuration initiale du graal (sans spread, il s'agira presque d'un graal). La rentabilité baisse à un certain niveau, la stabilité sur les nouvelles données augmente. Un équilibre entre les deux est choisi.
Cela semble logique et pas si vague que d'autres justifient leur TS.
La variante la plus facile à comprendre est décrite dans l'article, vous pouvez la vérifier vous-même, le cœur de l'algorithme est simple.
J'ai jeté un coup d'œil rapide à l'article.
Dès le début, j'ai mis l'accent sur une certaine prémisse de base, sur laquelle tout le reste repose :
Si nous entraînons le modèle plusieurs fois sur des sous-échantillons aléatoires, puis testons la qualité de la prédiction sur chacun d'entre eux et additionnons toutes les erreurs, nous obtenons une image relativement fiable des cas où il se trompe réellement beaucoup et des cas où il devine souvent.
Pas du tout d'accord.
Toute validation croisée ne peut, par définition, améliorer la qualité du modèle. La validation croisée vous permet de calculer une valeur d'erreur plus VALIDE au détriment d'un ensemble de statistiques. La validation croisée permet de calculer une valeur d'erreur plus VALIDE au détriment d'un ensemble de statistiques, et l'erreur de classification qui en résulte peut ou non avoir un rapport avec la prédiction sur le fichier externe, c'est-à-dire dans le commerce réel.
La qualité de la prédiction par un modèle est déterminée par l'ensemble des prédicteurs pour un ensemble particulier d'étiquettes et n'a rien à voir avec le modèle. Avant de modéliser, il faut répondre à la question suivante : les prédicteurs et leurs étiquettes sont-ils compatibles ? Il est impossible de répondre à cette question à l'aide d'un modèle, et c'est ce que vous essayez de faire.
Il est impossible de répondre à cette question avec un modèle, et vous essayez de le faire.
Avec quoi voulez-vous y répondre ?
et par quoi voulez-vous répondre ?
C'est un vieux sujet qui a déjà été abordé à maintes reprises.
C'est un vieux sujet et il a été écrit à maintes reprises.
support de visualisation, vernissage, abonnement du développeur du paquet R rusquant
C'est la même chose
Dans votre article, il n'y a pas de graphique pour le mode "avant" du testeur, par lequel on peut vraiment juger le modèle.
D'ailleurs, vous utilisez des mashki, peu importe la différence avec le prix, et vous devriez faire attention avec eux, parce que dans certaines conditions de test des modèles par vos propres testeurs, comme ce n'est pas drôle et contredit l'ensemble de l'AT, les mashki regardent en avant. En utilisant le mode "forward", s'il y a un "looking ahead", vous obtiendrez un grand écart dans les résultats entre le "forward" et le "main plot".
rusquant
Le site indique que l'interaction avec les API Tinkoff, Finam et Alor est prise en charge. Quelqu'un a-t-il vérifié ?