Utilisation des réseaux neuronaux dans le trading - page 39
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
C'est dommage qu'il n'y ait pas de "pionniers". Je vais continuer à creuser...
J'ai lu un article aussi divertissant.
Je m'intéresse au principe de la structuration du cerveau en réseau neuronal - on recrute d'abord un grand nombre de connexions de toutes sortes sans prêter beaucoup d'attention à leur qualité, puis la sélection commence sur le principe de "supprimer tout ce qui n'est pas nécessaire pour atteindre le résultat".
Il est tout à fait possible que cette approche aide à lutter à la fois contre le surentraînement et la "défaillance structurelle" pour ainsi dire.
A ce propos, une question : personne n'a rencontré d'études du principe similaire dans la théorie NS.
J'ai lu un article aussi divertissant.
Je m'intéresse au principe de la structuration du cerveau en réseau neuronal - on recrute d'abord un grand nombre de connexions de toutes sortes sans prêter beaucoup d'attention à leur qualité, puis la sélection commence sur le principe de "supprimer tout ce qui n'est pas nécessaire pour atteindre le résultat".
Il est possible que cette approche aide à lutter à la fois contre le surentraînement et la "défaillance structurelle" pour ainsi dire.
A ce propos, une question : personne n'a rencontré d'études du principe similaire dans la théorie NS.
J'ai vu quelque chose avec "net thinning" quand une petite valeur absolue est détectée dans les coefficients.
Mais je n'ai rien vu de tel dans les dizaines de fois, et comme principe de base "gros, gros surplus, puis réduction". Voulez-vous en faire un ?
Je suis intéressé. Seules les ressources informatiques seraient insuffisantes. // Je ne sais pas comment adapter le GPU - il est rentable de calculer seulement le même type de schémas, et ici chaque fois la topologie du réseau est différente.
MetaDriver:
Tu veux te faire brancher ?
Je le fais. Mais pour l'instant, je me dis que je dois y réfléchir pour trouver l'algorithme de réduction à utiliser. La première idée est d'éclaircir vraiment par valeur absolue, et de faire dépendre le seuil du nombre d'exemples déjà présentés : plus l'échantillon d'entraînement est grand, plus il devrait être difficile pour les liens de survivre.
Je ne sais pas comment adapter le GPU - il est avantageux de calculer uniquement le même type de schémas, mais ici, la topologie du réseau est différente à chaque fois.
Ils sont du même type et sont mis en œuvre par le matériel. L'efficacité du calcul parallèle en général est grandement exagérée, en fait (il y a des calculs réels et même des thèses de doctorat sont défendues à ce sujet) dans le cas général, il est même plus lent que le séquentiel ; la raison est le temps passé sur le transfert de données.
Je ne suis pas tout de suite d'accord. Si vous avez une bonne compréhension des spécificités, vous pouvez vous arranger pour obtenir des centaines de fois plus de vitesse de la part de un peu de des tâches. Ainsi, pour les calculs intensifs, il est toujours judicieux d'essayer de réduire le problème à une classe de ces "certains". Si cela fonctionne, le gain peut être énorme. Si ce n'est pas le cas, alors non - calculer séquentiellement sur un processeur ordinaire.
--
Par exemple, l'optimisation génétique de réseaux neuronaux de même type (avec la même topologie) avec un grand nombre d'exemples d'entraînement est extrêmement bénéfique (la vitesse d'exécution est des dizaines ou des centaines de fois plus élevée). Le seul problème est que chaque topologie nécessite un nouveau programme OpenCL. Cela peut être résolu en construisant des modèles ocl de base et en générant automatiquement (par programme) de nouveaux programmes ocl pour une topologie donnée.
Tiens, au fait. En écrivant ce qui précède, une idée m'est venue à l'esprit : comment réduire votre problème à une classe avantageuse pour les calculs GPU. Pour le faire étape par étape : à l'intérieur de chaque étape, nous devons tout lire dans un programme OCL, mais réduire à zéro les coefficients (en substance imiter). Et pour une nouvelle étape, générer un nouveau programme dans lequel les réductions de l'étape précédente ont déjà été "flashées" dans le programme. Et ainsi de suite. Mais c'est le cas si l'"apprentissage" génétique est utilisé.
Je ne peux pas être d'accord avec cela tout de suite. Si vous avez une bonne compréhension des spécificités, vous pouvez réussir à obtenir cent fois plus de vitesse de la part de l'ordinateur. un peu de des tâches. Par conséquent, dans le cas de calculs complexes, il est toujours judicieux d'essayer de réduire le problème à la classe de ces "certains". Si cela fonctionne, le gain peut être énorme. Si ce n'est pas le cas, alors non - comptez séquentiellement sur un processeur ordinaire.
Si je me souviens bien, la valeur critique est le rapport entre le temps d'exécution des tâches parallèles et celui des tâches non parallèles (préparation des données, transmission des données) dans la boucle principale. Plus le parallélisme est élevé, plus les exigences relatives à ce rapport sont strictes. C'est pourquoi nous ne devons pas seulement chercher à réduire l'algorithme à un "fichier parallèle", mais aussi à minimiser la partie non parallèle.
Par exemple, dans l'informatique en nuage (cloud computing), aujourd'hui en vogue (et, soit dit en passant, mise en œuvre dans Five), les limitations de gain sont très importantes du simple fait du temps de transfert. Pour être juste, il convient de noter que ces limitations n'apparaissent que lorsqu'un réseau en nuage est chargé au moins à quelques dizaines de pourcents.
Mais il ne s'agit pas de cela maintenant - il n'y a vraiment pas beaucoup de parallélisme dans cette tâche.
Il n'y aura pas de parallélisme : les modèles dépendent séquentiellement les uns des autres, il faut donc les générer tous à l'avance, mais il y en aura alors des trillions et la plupart du temps sera consacré à trouver le bon à ce moment-là).
Il n'y aura pas de parallélisme : les modèles dépendent séquentiellement les uns des autres, nous devons donc tous les générer à l'avance, mais il y en aura alors des trillions et la plupart du temps sera consacré à trouver celui qui est nécessaire à l'instant présent)
Ah, bien, je vais reproduire ça :
Tiens, au fait. En écrivant ce qui précède, j'ai eu une idée pour réduire votre problème à une classe de calculs avantageux pour le GPU. Pour le faire étape par étape : à l'intérieur de chaque étape, nous devons tout lire dans un programme OCL, mais réduire à zéro les coefficients (en substance imiter). Et pour une nouvelle étape, générer un nouveau programme dans lequel les réductions de l'étape précédente ont déjà été "flashées" dans le programme. Et ainsi de suite. Mais c'est le cas si l'"apprentissage" génétique est utilisé.