L'apprentissage automatique dans la négociation : théorie, modèles, pratique et algo-trading - page 3151
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
la taille de la fenêtre d'historique est une limitation importante pour les modes opératoires classiques avec des données tabulaires
Les AS (asoc. rules) ne souffrent pas d'une telle maladie, ils digèrent parfaitement les données non structurées, de plus, chaque observation peut être de taille arbitraire.
Et la "fenêtre de vision" (fenêtre d'historique) elle-même ne peut être limitée que par la puissance de calcul. ou le bon sens.
Donc votre exemple avec la taille de la fenêtre historique est juste un vote pour AC et contre MO.
Donnez-moi d'autres arguments, je suis curieux de savoir si j'ai vraiment raté quelque chose.
Et une autre question, quel est votre degré d'implication dans l'AU ?
Je n'ai pas plongé dans les règles. J'ai déjà écrit que j'ai abordé l'application des grammaires formelles d'un autre point de vue - j'ai examiné le prix tel qu'il est construit par la grammaire stochastique. J'ai abandonné cette approche précisément à cause de sa lourdeur, qui est mauvaise avant tout parce qu'elle provoque un surentraînement.
Aujourd'hui, j'évite les modèles lourds. Pour moi, la principale règle informelle est que la lourdeur du modèle doit correspondre à la lourdeur de l'information contenue dans l'échantillon.
Votre modèle est suffisamment lourd pour un modèle de prix à part entière, mais l'échantillon réel de prix dont nous disposons (même si nous ajoutons d'autres informations) n'est pas suffisant pour un tel modèle.
Naturellement, IMHO
Comment l'AMO trouve-t-elle un modèle à partir de l'exemple ?
J'ai décrit tout cela très modestement par souci de clarté, mais en réalité, cela ressemble davantage à ceci.
Et votre modèle ne voit que cela : (les 5 dernières bougies non horaires).
Notez également qu'il n'y a pas de lien avec l'indice, si un événement important a eu lieu hier il y a 200 bougies, aujourd'hui le même événement peut avoir lieu il y a 1555 bougies ou 12 par exemple.....
AC trouvera un tel schéma, AMO ne le trouvera pas !
AMO a besoin que chaque caractéristique ait toujours la même colonne dans la table, de sorte qu'elle soit toujours déclenchée sous le même index.
ou comme ceci, qui est également très visuel.
et le modélisateur le voit.
Quoi qu'il en soit, j'espère que je me suis bien fait comprendre.
Au fait, comment se passe l'étude sur le python ?
Au fait, comment se passe l'étude sur le python ?
C'est un bon langage, mais à partir d'un certain niveau, il devient trop compliqué pour un non-programmeur. Par exemple, il est beaucoup plus difficile d'écrire des extensions en C qu'en R. J'ai beaucoup aimé les tableaux en numpy.
Je n'ai pas plongé dans les règles. J'ai déjà écrit que j'ai abordé l'application des grammaires formelles par l'autre côté - j'ai examiné le prix tel qu'il est construit par la grammaire stochastique. J'ai abandonné cette approche précisément à cause de sa lourdeur, qui est mauvaise avant tout parce qu'elle provoque un surentraînement.
Aujourd'hui, j'évite les modèles lourds. Pour moi, la principale règle informelle est que la lourdeur du modèle doit correspondre à la lourdeur de l'information contenue dans l'échantillon.
Votre modèle est suffisamment lourd pour être un modèle de prix à part entière, mais l'échantillon réel de prix dont nous disposons (même si nous ajoutons d'autres informations) n'est pas suffisant pour un tel modèle.
Naturellement, IMHO
100%
Notez également qu'il n'y a pas de lien avec l'index, si un événement important s'est produit hier il y a 200 bougies, aujourd'hui le même événement peut se produire il y a 1555 bougies ou 12 par exemple....
AC trouvera un tel schéma, AMO ne le trouvera pas !
AMO a besoin que chaque caractéristique ait toujours la même colonne dans la table, de sorte qu'elle soit toujours déclenchée sous le même index.
ou comme ceci, qui est également très visuel.
Curieux, je fais exactement ce que j'ai décrit il y a environ six mois.
Je ne comprends pas comment vos règles recherchent la valeur d'une caractéristique verticalement sans référence à l'index - dans mon concept, il devrait y avoir une plage de recherche acceptable - je ne comprends pas votre mise en œuvre.
Curieux, je fais exactement ce que j'ai décrit il y a environ six mois.
Je ne comprends pas comment vos règles recherchent la valeur d'une caractéristique verticalement sans référence à l'index - dans mon concept, il devrait y avoir une plage de recherche acceptable - je ne comprends pas votre mise en œuvre.
C'est un bon langage, mais à partir d'un certain niveau, il devient trop compliqué pour un non-programmeur. Par exemple, il est beaucoup plus difficile d'écrire des extensions en C qu'en R. J'ai beaucoup aimé les tableaux de numpy.
question sacrée)
pour les études de marché - R ou python ?
question de l'holivar)
pour les études de marché - R ou Python ?
Pour les études de marché que je réalise actuellement - R. Je ne suis pas prêt à me porter garant pour d'autres ou pour moi-même à l'avenir).
Les algorithmes habituels de règles associatives, différents selon le problème.
Je ne sais même pas de quel code nous parlons - apparemment, quelque chose n'a pas fonctionné. De quel code parlons-nous ?
Vous prétendez que la profondeur n'est pas un événement important dans le temps - et comment cela est écrit par la règle - je n'ai pas compris.