L'apprentissage automatique dans la négociation : théorie, modèles, pratique et algo-trading - page 2699
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
Le temps cyclique (nombre d'heures, etc.) est facile à utiliser, par exemple, dans KNN, si la métrique est écrite correctement. Ou dans certains développements de cette méthode, comme la régression locale.
Je vois une familiarité, je l'ai vu 3-4 fois maintenant dans vos messages.
2 fois 0,5 par tour.)))))))
2 fois, c'est comme ça :
2 fois 0,5 est au centre :-) Une moyenne de deux, ce qui tout à coup décrit bien les tics
0) oui, je le suis...)
Ma méthode fixe le nombre d'espaces dans lesquels la régularité est recherchée et limite le pas des coordonnées dans ces espaces, il ne devrait donc pas y avoir d'explosions. De plus, il existe des idées pour réduire immédiatement le nombre de combinaisons à rechercher en analysant les espaces au préalable.
Je ferai la recherche dans MQL5 à travers le mode "calcul mathématique", l'avantage ici est le système débogué de support d'agent, qui permettra de gérer des tâches de calcul parallélisées. J'ai pas mal de cœurs faibles sur mes serveurs, c'est donc important pour moi.
Une règle est un analogue d'une feuille d'arbre, si je me souviens bien de votre recherche. La feuille contient les conditions qui décrivent le modèle, et l'événement est la source qui permet de trouver le modèle.
L'événement est peut-être la souche de l'arbre, qui sera construite en interagissant avec d'autres prédicteurs.
La construction, même s'il est possible de dire la croissance, si l'on utilise la représentation d'un arbre, est déjà la deuxième étape, pour réaliser qu'il est possible soit à travers l'algorithme (en faisant des croquis sur un papier) ou sur R à travers les arbres génétiques (c'est simplement une méthodologie déjà élaborée, à vous de lancer le script), ou comme vous le faites - mais en travaillant déjà avec un petit tableau en général - en recherchant des régularités relatives, et il est possible de penser à quelque chose d'autre. Et à ce stade, CatBoost peut déjà digérer les données avec joie, comme une solution intermédiaire. Il est possible d'en tirer des feuilles et des règles, mais elles sont généralement faibles.
la probabilité de franchissement d'une ligne par le prix (et le déclenchement des signaux de l'indicateur) dépend de l'heure de la journée et du jour de la semaine.
Il est nécessaire d'ajouter un temps cyclique à NN et DL. La manière la plus simple est une onde sinusoïdale. Les dépendances n'étant pas linéaires, il suffit de l'élever au carré, en tenant compte du signe. Deux entrées supplémentaires sont responsables des références temporelles. Minuit/midi est différent partout, il est donc préférable de calculer et de donner la phase à l'avance. Il s'agit de la connexion du modèle avec le monde réel et son heure.
Si elles ne sont pas explicitement données, vous obtiendrez une citrouille ou l'ensemble du système essaiera de les obtenir et de les restituer par lui-même.
Oui, le temps est l'une des échelles les plus importantes, et je l'utilise bien sûr.
Comment la question du passage à l'heure d'été/d'hiver est-elle résolue, pensez-vous qu'une correction soit nécessaire ?
Disons que nous négocions Euro/Ruble - sur l'historique, nous avons différents moments de transition vers l'heure d'hiver/d'été, puis l'absence de transition pour le rouble, mais la présence de l'euro, disons que les événements prévus sont importants, mais avec le décalage horaire, ils seront sur le graphique à des moments différents, et comment faire ? Peut-être est-il judicieux d'utiliser les échelles de temps de deux monnaies à la fois, voire plus ?
Oui, le temps est l'une des échelles les plus importantes, et je l'utilise bien sûr.
Comment est résolue la question du passage à l'heure d'été/hiver, pensez-vous qu'une correction soit nécessaire ?
Supposons que nous fassions du commerce euro/rouble - sur l'historique, nous avons différents moments de transition vers l'heure d'hiver/d'été, puis l'absence de transition pour le rouble, mais la présence de l'euro, disons que les événements prévus sont importants, mais avec le décalage temporel, ils seront sur le graphique à des moments différents, et comment faire ? Peut-être est-il judicieux d'utiliser les échelles de temps de deux monnaies à la fois, voire plus ?
Il s'agit d'un problème bien connu... qui ne cesse de tout embrouiller, quel que soit le type de transaction:-) dans deux grands centres - les États-Unis et l'Angleterre, les aiguilles de l'horloge sont déplacées à des jours différents. Jusqu'à plus d'une semaine d'écart. Les intervalles entre les événements les plus importants changent et deux ou trois semaines en six mois peuvent être exclues de l'analyse. Et nos collaborateurs font n'importe quoi : "nous changeons les horloges, nous ne changeons pas les horloges".
Je ne connais pas de solution universelle ou même plus ou moins efficace à ce problème. Soit on ignore ces "jours critiques", soit on enseigne séparément l'heure d'hiver et l'heure d'été. Cette dernière solution semble plus raisonnable, mais nous manquons déjà cruellement de données à l'heure actuelle
Ma méthode fixe le nombre d'espaces dans lesquels un motif est recherché et limite le pas des coordonnées dans ces espaces, de sorte qu'il ne devrait pas y avoir d'explosions. De plus, il existe des idées pour réduire immédiatement le nombre de combinaisons à explorer en analysant les espaces au préalable.
Je ferai la recherche dans MQL5 à travers le mode "calcul mathématique", l'avantage ici est le système débogué de support d'agent, qui permettra de gérer des tâches de calcul parallélisées. J'ai pas mal de cœurs faibles sur mes serveurs, c'est donc important pour moi.
Une règle est un analogue d'une feuille d'arbre, si je me souviens bien de votre recherche. La feuille contient les conditions décrivant le modèle, et l'événement est la source permettant de trouver le modèle.
L'événement est peut-être la souche de l'arbre, qui grandira en interagissant avec d'autres prédicteurs.
En construisant, il est même possible de dire la croissance, si d'utiliser la représentation d'un arbre, - c'est la deuxième étape déjà, pour réaliser qu'il est possible soit par l'algorithme (tout en esquissant sur un papier) ou sur R à travers les arbres génétiques (c'est simplement la méthodologie déjà élaborée, à vous jeté le script), ou comme vous le faites - mais en travaillant déjà avec un petit en général tableau - la recherche des régularités relatives, et il est possible de penser à quelque chose d'autre. Et à ce stade, CatBoost peut déjà digérer les données avec joie, comme une solution intermédiaire. Il est possible d'en tirer des feuilles et des règles, mais elles sont généralement faibles.
Existe-t-il des outils dans votre approche pour prendre en compte l'invariance des données ?
https://en.wikipedia.org/wiki/Affine_transformationVotre approche comporte-t-elle des outils permettant de tenir compte de l'invariance des données ?
https:// en.wikipedia.org/wiki/Affine_transformationC'est peut-être pertinent pour des points multiples, par exemple pour trouver des modèles similaires, mais dans mon cas, il n'y a essentiellement qu'un seul point à la première étape. Le point est converti/normalisé en différents systèmes de mesure relatifs - échelle de temps et prix, plus un troisième espace - tout prédicteur discret décrivant continuellement le marché. Vous obtenez 3 dimensions dans la représentation initiale. Chacune a sa propre table quantique.