L'Apprentissage Automatique dans le trading : théorie, modèles, pratique et trading algo - page 2802
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
Vous avez réalisé un script que j'ai décidé d'utiliser à nouveau.
Je l'ai lancé sur un échantillon, et il donne une erreur - je n'arrive pas à comprendre où se trouve l'erreur et comment la corriger - peut-être le savez-vous, puisque vous utilisez ces bibliothèques/packages ?
Tout fonctionnait bien sur un échantillon binaire.
L'erreur indique que des valeurs non définies (NA) sont apparues dans la matrice de corrélation et que la fonction findCorrelation ne peut pas les utiliser. Ouvrez le paquet et lisez la description de la fonction.
Les scripts sont désordonnés et contiennent une multitude de résultats intermédiaires inutiles.
Explications dans l'ordre :
1. Il n'est pas nécessaire de charger le paquet "caret" dans le champ d'application global. Il est très lourd, il tire beaucoup de dépendances et de données. Vous n'avez besoin que d'une seule fonction. Vous l'importez directement dans la fonction get.findCor.
Le package "tidyft" est un package de manipulation de dataframes très rapide. Utilisez-le.
Pour le contrôle, j'ai testé sur mon kit en utilisant ce script. Résultat :
Le temps de comptage est assez long (12.9 min). Mais le cadre n'est pas petit non plus. Bien sûr, nous devons le paralléliser, chercher une fonction cor plus rapide.
A partir des 21 prédicteurs initiaux avec différents seuils, nous avons sélectionné différents nombres de prédicteurs.
Mais ce n'est pas la meilleure façon de procéder.
Bonne chance !
Vous n'avez pas prêté attention à la variabilité du sd
Je ferai attention la prochaine fois, je compterai les écarts par rapport aux écarts par rapport aux écarts par rapport aux écarts %)
Le fait de lier le décalage de la fenêtre de l'élément à un indicateur (par exemple, std) n'a rien donné
plus la valeur est grande, plus le multiple de décalage de cette valeur est grand.
ou vice versa. J'ai essayé les deux.
il existe également une variante de l'expansion-narrowing (+ offset ?), je ne l'ai pas encore essayée.
Je ne vois qu'une énumération de ces variantes dans le cadre des fractales.
1. Il n'est pas nécessaire de charger le paquet "caret" dans le champ d'application global. Il est très lourd, il tire beaucoup de dépendances et de données. Vous n'avez besoin que d'une seule fonction. Vous l'importez directement dans la fonction get.findCor.
Wow, c'est creux
Vladimir, sais-tu s'il existe un package pour backtest qui garde un journal des transactions et tout le reste (enfin, pas pour être primitif), sauf pour les lents "quantstrat" et "SIT"
Le fait de lier le décalage de la fenêtre de la caractéristique à un indicateur (par exemple std) n'a rien donné.
plus la valeur est grande, plus le multiple de décalage de cette valeur est grand.
ou vice versa. J'ai essayé les deux.
il y a aussi une option d'expansion-rétrécissement (+ décalage ?), je ne l'ai pas encore essayée.
Je ne vois qu'un dépassement de ces variantes dans le cadre des fractales.
Absolument.
Tout doit être recalculé à chaque étape.
Absolument.
Tout doit être recalculé à chaque étape.
Je trouve qu'il est plus facile de passer en revue les façons de recalculer les étiquettes par rapport aux caractéristiques sur un grand ensemble de données que de réentraîner chaque barre, car je serais bloqué pendant longtemps.
De plus, le réentraînement fréquent permet de déterminer un modèle général, si l'on considère la situation dans son ensemble. À moins que ce modèle ne soit coulant, bien sûr.Il est plus facile pour moi d'étudier les moyens de recalculer les étiquettes par rapport aux puces sur un grand ensemble de données que de réentraîner chaque barre, je serais bloqué pendant longtemps.
Tout à fait d'accord, c'est la raison pour laquelle je ne peux pas passer à EA.
Mais c'est une question de principe. J'ai opté pour le schéma "teach every step" en raison des problèmes cachés liés à la préparation de l'ensemble des données. J'ai exactement le même problème et je n'ai pas été en mesure de trouver des prédicteurs qui génèrent l'effet "looking ahead".
Tout à fait d'accord, c'est la raison pour laquelle il ne va pas vers l'EA.
Mais c'est une question de principe. J'ai opté pour le schéma "enseigner à chaque étape" en raison de la possibilité de voir ce qui se passe à l'avance en raison de la préparation de l'ensemble des données. J'ai exactement le même problème et je n'ai pas été en mesure de trouver des prédicteurs qui génèrent l'effet de "regard vers l'avant".
Le graphique Embargo est en quelque sorte appelé.
Une fois la formation réduite à 1 jour et le test à 1 jour. Et a regardé les prévisions pour le markup quelques jours à l'avance. C'est-à-dire qu'il a vu ce qui se passera pour les nouvelles barres. Les résultats ont été très bons.
En augmentant l'intervalle d'entraînement jusqu'à une semaine, les résultats ont également été supérieurs à 50/50. Eh bien, plus c'était, pire c'était, les lignes avec peeking ont été ajoutées aux lignes sans peeking et elles ont tout gâché))))
.
En général, ce tracé d'embargo ne devrait pas être moins qu'un coup d'œil en avant pour l'enseignant.
Wow, c'est une chose creuse
Vladimir, sais-tu s'il existe un package pour backtest qui garde un journal des transactions et tout (enfin, pas pour être primitif), sauf pour les lents "quantstrat" et "SIT".
Je ne sais pas. Je n'ai pas rencontré