L'Apprentissage Automatique dans le trading : théorie, modèles, pratique et trading algo - page 2623
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
et la réponse ne vous était pas destinée - vous ne savez toujours pas lire...
Vous n'avez même pas besoin d'un deuxième modèle ici, n'est-ce pas ? - Validation croisée et recherche sur grille pour la sélection de modèles ...
mais peut-être que la matrice de confusion répondra à votre 2ème question (le but du 2ème modèle de votre idée)...
.. . ou
... Je doute juste que vous ayez besoin du 2ème modèle ... imho
Voici juste l'amélioration de la matrice de confusion est revendiquée avec le deuxième modèle, si vous lisez le Prado, par exemple. Mais il utilise également des exemples de suréchantillonnage pour le premier modèle afin d'augmenter le nombre de vrais positifs ou autre chose. J'ai déjà oublié, malheureusement.
L'échantillonnage vers le haut et l'échantillonnage vers le bas sont destinés aux ensembles de données déséquilibrés et aux petits ensembles de formation - si c'est ce que vous voulez dire - c'est-à-dire donner des poids plus élevés aux petites classes et vice versa... Oui, probablement pour les augmenter (tru positif)...
***
et à propos de 2 modèles - eh bien, il est probablement possible de filtrer 2 fois - d'abord les signaux pour fixer les pondérations, puis les transactions sur ces signaux en fonction de ces pondérations (lancées par les entrées dans la deuxième pesée)... bien qu'il semble qu'il soit possible d'apprendre sur les transactions avec le contexte - et de garder le gradient pour les séries temporelles précédentes - bonne idée... MAIS l'implémentation lorsqu'on travaille avec le contexte est encore un peu différente en général - la tâche consiste à utiliser le codage "transaction et son contexte" et le 2ème RNN prend en charge le résultat du traitement du 1er pour le décoder en sortie -- mais cela n'a pas grand chose à voir avec le fait de faire travailler 2 réseaux sur 2 tâches différentes (par exemple, le contexte et les transactions), puisqu'en fait il est traité-passé par 2 réseaux "transaction et contexte" (en tant que paire !!!)... - cela ne résout que le problème de vitesse , mais pas (ou dans une moindre mesure) la validité de la sortie... imho...
mais si vous voulez vraiment séparer le traitement du contexte et de la transaction (contexte séparément, transactions séparément) -- jusqu'à présent, une telle construction me fait penser à un sandwich (ou à de l'huile et du beurre, lubrifiant les interrelations et dépendances des phénomènes les uns des autres - en 2 couches)... Je n'ai pas la prétention d'interpréter votre TechSuite, mais j'ai exprimé mes préoccupations et suggéré qu'il peut encore être utile de le préserver dans le processus de modélisation - à savoir les relations ... ! Je vous souhaite une belle (reflet de la réalité ! pas de l'huile de beurre) architecture de réseau !
p.s. ) comme un éternel problème de la "publicité contextuelle" - "l'essentiel n'est pas de s'éloigner de la réalité" (seulement la configuration de leurs balances est parfois tordue - je ne montrerai pas du doigt qui - ou avec de petits échantillons travaillés dans la mauvaise direction)
L'échantillonnage ascendant et l'échantillonnage descendant sont destinés aux ensembles de données déséquilibrés et aux petits ensembles de formation - si c'est ce que vous voulez dire - c'est-à-dire donner plus de poids aux petites classes... Oui, probablement pour les augmenter (tru positif)...
***
et à propos de 2 modèles - eh bien, il est probablement possible de filtrer 2 fois - d'abord les signaux pour fixer les pondérations, puis les transactions sur ces signaux en fonction de ces pondérations (lancées par les entrées à la 2ème pesée)... bien qu'il semble qu'il soit possible d'apprendre sur les transactions avec le contexte - et de garder le gradient pour les séries temporelles précédentes - bonne idée... MAIS l'implémentation lorsqu'on travaille avec le contexte est encore un peu différente en général - la tâche consiste à utiliser le codage "transaction et son contexte" et le 2ème RNN prend en charge le résultat du traitement du 1er pour le décoder en sortie -- mais cela n'a pas grand chose à voir avec le fait de faire travailler 2 réseaux sur 2 tâches différentes (par exemple, le contexte et les transactions), puisqu'en fait il est traité-passé par 2 réseaux "transaction et contexte" (en tant que paire !!!)... - cela ne résout que le problème de vitesse , mais pas (ou dans une moindre mesure) la validité de la sortie... imho...
mais si vous voulez vraiment séparer le traitement du contexte et des transactions (le contexte séparément, les transactions séparément) - jusqu'à présent, une telle construction me fait penser à un sandwich (ou à de l'huile et du beurre, lubrifiant les interrelations et les dépendances des phénomènes les uns des autres - en 2 couches)... Je n'ai pas la prétention d'interpréter votre TechSuite, mais j'ai exprimé mes préoccupations et suggéré qu'il peut encore être utile de le préserver dans le processus de modélisation - à savoir les relations ... ! Je vous souhaite une belle (reflet de la réalité ! pas de l'huile de beurre) architecture de réseau !
p.s. ) comme un éternel problème de la "publicité contextuelle" - "l'essentiel n'est pas de s'éloigner de la réalité" (seule la configuration de leurs échelles est parfois tordue - je ne pointerai pas du doigt qui - ou avec de petits échantillons travaillés dans la mauvaise direction)
Le concept de régularité implique la répétabilité, c'est important !
les statistiques sont linéaires, quelle que soit la façon dont on les regarde... les réseaux neuronaux sont des pondérations muettes (ou intelligentes - cela dépend du développeur)... l'utilisation de 2 ou plusieurs couches de ns denses pour la pondération donne des dépendances non linéaires (conventionnellement parlant, car la dépendance est OU corrélation muette est encore une très grande question)... mais tant qu'une corrélation, même stupide, fonctionne, vous pouvez essayer de gagner de l'argent avec... - le moment où il cesse de fonctionner doit être détecté à temps (vous devez remarquer une sorte d'anomalie - aléatoire ou systématique - c'est une autre question - et ensuite, comme d'habitude, décider de votre question de risque/profitabilité)
la commodité de ns réside dans sa flexibilité - vous pouvez obtenir/fournir une "nomenclature" tout à fait différente de celle que vous souhaitez. Il est flexible - vous pouvez obtenir/fournir une "nomenclature" très différente de l'entrée - c'est-à-dire que vous pouvez faire les transformations dont nous avons besoin dans le réseau lui-même... et le faire en mode multithread (dépend de la bibliothèque)... pas seulement des statistiques...
Que vous ayez besoin ou non de statistiques pour trouver une entrée est une autre question...
la connaissance et l'expérience aident plus souvent que le traitement statistique - car le premier se concentre sur les spécificités, le second sur la réduction à un dénominateur commun ...
Chaque chose a sa place - les statistiques aussi...
***
le fait est que pour un robot - il n'y a pas d'autre moyen d'expliquer (et il ne vous expliquera pas d'une autre manière), sauf via des probabilités dérivées de nombres... - C'est ainsi que l'ECONOMIE a fonctionné pendant des siècles - avec les nombres 0 et 1... nous devons donc numériser les entrées pour obtenir des probabilités de sortie et fixer les conditions des intervalles de confiance (auxquels nous faisons confiance, pas nécessairement les statistiques)... et nous pouvons faire confiance à n'importe quoi (c'est subjectif) - soit la logique binaire, soit le résultat pondéré de cette logique binaire (c'est-à-dire les probabilités en % de l'ensemble des solutions potentielles)... -- ... c'est juste une question de goût et d'habitudes, pas un sujet de discussion sur la recherche du Graal...
(et entrer dans une forêt ou entrer dans un réseau neuronal est déjà un détail)
personne n'a interdit l'utilisation conjointe d'arbres/forêts et de réseaux neuronaux dans un même projet... - la question est de savoir où appliquer quoi et quand (la vitesse et la mémoire sont importantes), et non de savoir lequel est le meilleur... - mieux vaut ne pas perdre de temps - équivalent à "le timing en dehors d'une transaction est du temps perdu, tout comme une transaction en dehors du timing est une transaction inconnue".
Aucun modèle ne peut obtenir plus que des probabilités (ce qui est un avantage et un inconvénient de toute numérisation), même si ces probabilités ne sont pas pondérées... Je ne m'empoisonne pas avec des sandwichs et ne conseille personne - personne n'a annulé Bayes (même si on ne le met pas dans le code, et surtout - si on le met dans le code)...
p.s. Et vous devez être un fan de McDonalds... - Hypothèse, je ne vais pas la tester...
L'algorithmique est plus chère que vos conclusions
Aucun modèle ne peut obtenir plus que des probabilités (ce qui est un avantage et un inconvénient de toute numérisation), même si ces probabilités ne sont pas pondérées... Je ne m'empoisonne pas avec des sandwichs et ne conseille personne - personne n'a annulé Bayes (même si on ne le met pas dans le code, et surtout - si on le met dans le code)...
p.s. Et vous devez être un fan de McDonalds... - Hypothèse, je ne vais pas la tester...
L'algorithme est plus cher que vos conclusions.