"New Neural" est un projet de moteur de réseau neuronal Open Source pour la plateforme MetaTrader 5. - page 68
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
"Reverse" est nécessaire pour trouver les dérivées partielles d'une fonction de fitness par des arguments adaptatifs, donc toute méthode de gradient (par exemple BackProp dans toute modification) nécessite "reverse".
D'autres méthodes ne nécessitent pas
Laissez-moi ajouter quelque chose.
En tant qu'utilisateur final, j'ai besoin des éléments suivants de la boîte noire.
J'y ai mis les 20-1000 dernières mesures, quelques symboles.
En réponse, la boîte noire dit. L'état stable de la grappe (plat) est observé aux 15 dernières mesures .
Ces clusters sont dans la période historique du 1.01.1995 au 20.01.95 etc. Nous pouvons mettre en évidence le graphique.
La durée de vie minimale de l'amas est de 20 bars, maximale de 74 bars, moyenne de 47 bars, observée 125 fois au cours de l'histoire.
La stratégie recommandée est de trader depuis la bordure du canal, les niveaux du canal sont 1.2567-1.2687.
Ou.
L'état stable du cluster (plat) est observé aux 65 dernières mesures.
Ces clusters sont dans la période historique du 1.01.1995-20.01.95 etc, nous pouvons mettre en évidence le graphique.
La durée de vie minimale de l'amas est de 20 barres, la durée de vie maximale est de 74 barres, la moyenne est de 47 barres, l'ensemble de l'histoire a été observé 125 fois.
La stratégie recommandée est de casser le canal, les niveaux du canal sont 1.2567-1.2687.
Je suis en train de réfléchir à tout ça. Cela peut être fait sur le NS.
"Reverse" est nécessaire pour trouver les dérivées partielles d'une fonction de fitness par des arguments adaptatifs, donc toutes les méthodes de gradient (par exemple BackProp dans toute modification) nécessitent "reverse".
Les autres méthodes ne nécessitent pas
Ai-je raison de supposer qu'il n'existe pas de mouvement vers l'avant pour ajuster les poids ?
et les algorithmes utilisant un déplacement vers l'avant dans la formation utilisent en fait plusieurs tableaux de poids (existant en parallèle),
En choisissant la meilleure d'entre elles.
ou existe-t-il encore de tels algorithmes qui utilisent un coup direct pour ajuster les poids ?
Ai-je raison de supposer qu'il n'existe pas d'ajustement simple de la course des échelles ?
Les algorithmes qui utilisent les déplacements vers l'avant utilisent en fait plusieurs tableaux de pondération (existant en parallèle) lors de la formation,
en choisissant le meilleur d'entre eux.
Oui, c'est vrai.
J'ose même dire que c'est encore plus difficile - il n'y a pas non plus d'ajustement de la balance en arrière.
Le "coup inverse" est notre perception visuelle du processus de recherche de la dérivée d'une fonction complexe, qui est en fait un réseau de neurones.
L'apprentissage est un processus externe au réseau lui-même
Les différentes méthodes de formation imposent des exigences différentes à la topologie du réseau et à la forme de la fonction estimée.
Les méthodes de gradient sont les plus exigeantes et les méthodes stochastiques sont omnivores.
Une pensée à voix haute...
Il m'est apparu qu'un projet dans ce format est quasiment voué à l'échec.
D'abord, parce que chacun tire dans sa propre direction. Quelqu'un veut que le projet fasse tout pour lui, quelqu'un veut que le projet assemble lui-même la topologie, quelqu'un veut que tout vole sur le troisième espace comme cible.
Ensuite, en raison de malentendus sur les contrôles.
Troisièmement, et probablement le plus important, en raison du manque d'objectifs clairs du projet jusqu'à présent.
___________________________
Bref, j'ai compris - en ai-je vraiment besoin ? Je ferais mieux de me séparer et de promouvoir les réseaux d'écho comme un projet séparé.
Pas un plan pour conquérir le monde, mais fonctionnel et efficace.
Alors bonne chance et bonne chance. J'espère que le projet ne disparaîtra pas pour de bon.
___________________________
Désolé si quelque chose ne va pas.
Pensées à voix haute...
Une pensée à voix haute...
Il m'est apparu qu'un projet dans ce format est quasiment voué à l'échec.
D'abord, parce que chacun tire dans sa propre direction. Quelqu'un veut que le projet fasse tout pour lui, quelqu'un veut que le projet assemble lui-même la topologie, quelqu'un veut que tout vole sur le troisième espace comme cible.
Ensuite, en raison de malentendus sur les contrôles.
Troisièmement, et probablement le plus important, en raison du manque d'objectifs clairs du projet jusqu'à présent.
___________________________
Bref, j'ai compris - en ai-je vraiment besoin ? Je ferais mieux de me séparer et de promouvoir les réseaux d'écho comme un projet séparé.
Pas un plan pour conquérir le monde, mais fonctionnel et efficace.
Alors bonne chance et bonne chance. J'espère que le projet ne disparaîtra pas pour de bon.
___________________________
Désolé si quelque chose ne va pas.
En général, comment les projets de logiciels libres sont-ils mis en œuvre ?
Tout vient généralement d'un évangéliste (notional Torvalds), qui écrit le moteur et développe l'idéologie de base du projet. Puis, à mesure que le projet prend de l'ampleur, de nouvelles forces intéressées par le résultat final se joignent à eux. Et là, il s'avère que vous devez repartir de zéro, donc vous ne pouvez pas voir la direction, car il n'y a pas de direction. La meilleure option est d'essayer de développer le projet seul, ou au sein d'une équipe très soudée, non séparée géographiquement. Et puis, si le moteur est intéressant, les gens vont décrocher. Je pense que c'est la seule option qui peut survivre dans ces conditions.
Réflexions à voix haute...
Andrei, personne ne vous empêche de réaliser trois projets dans une même branche.
Comme toutes les branches traitent en fait de la même chose, il serait utile de publier et de partager des solutions au sein d'une même branche.
Nous avons maintenant trois directions, la génération de code, le branchement de différentes implémentations, et un moteur universel.
La connexion de différentes implémentations (c'est ce que vous voulez faire) serait très utile tant pour le générateur de code que pour le moteur universel.
Le moteur universel est utile pour le générateur de code. Et un générateur de code (comme le maître MQL) sera inutile dans les deux sens, bien qu'il combine la simplicité pour l'utilisateur final et la rapidité (ce sont toutes les meilleures qualités des branches parallèles).
Pour éviter toute confusion, nous pouvons utiliser des abréviations, GC RR UD, et mettre une abréviation pour chaque message dans son titre ou, par exemple, distinguer les messages par catégorie et utiliser les couleurs GC RR UD.
J'aimerais qu'ils crachent, mais ils m'ignorent. On vous a demandé un avis - oui ou non.
Si (OUI), je vais aller lire des livres intelligents ;
sinon allez en chercher un autre et vous mettre dans la bonne direction ;
Urain:
Nous avons maintenant trois directions, la génération de code, la connexion de différentes implémentations, et un moteur universel.
Je préfère m'occuper d'une seule mise en œuvre et essayer de l'améliorer jusqu'à la perfection.
Je ne pourrai peut-être pas concurrencer la génétique par l'échelle (ces classes de tâches, qui n'ont pas de fonction cible clairement spécifiée), mais par l'efficacité d'utilisation et d'apprentissage...