"New Neural" est un projet de moteur de réseau neuronal Open Source pour la plateforme MetaTrader 5. - page 49
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
Qui a l'expérience du travail en équipe sur un grand projet ?
Je veux aussi dire l'expérience avec VCS.
En général, pour autant que je puisse comprendre, il y a une sorte d'impasse - ici, dans l'ensemble, tous les oiseaux indépendants, capables de résoudre n'importe quel problème par eux-mêmes (de l'auto-apprentissage de la langue à la description d'une logique commerciale complexe). Et un cygne, une écrevisse et un brochet avec toutes leurs qualités dans un seul chariot, bien sûr, peuvent être harnachés, mais il n'en faut pas plus pour 50 pages de discussions actives dans cette branche du forum...
Maintenant, le point est que le projet doit avoir un leader qui :
Si les MC ne sont pas actifs au cours des deux prochaines semaines, le projet peut être abandonné, ou déplacé vers un emplacement commercial ailleurs.
Sans le contrôle des CM, le projet en tant qu'opsource n'a aucun sens.
En général, d'après ce que je peux comprendre, il y a une sorte d'impasse - ici, en général, tous les oiseaux indépendants, capables de résoudre n'importe quel problème par eux-mêmes (de l'auto-apprentissage de la langue à la description de la logique complexe du commerce). Et un cygne, une écrevisse et un brochet avec toutes leurs qualités dans un seul chariot, bien sûr, peuvent être harnachés, mais il n'en faut pas plus pour 50 pages de discussions actives dans cette branche du forum...
Maintenant, le point est que le projet doit avoir un leader qui :
Dans l'ensemble, ce qu'il a dit est vrai. Chacun d'entre nous est capable de réaliser ce projet par lui-même.
Mais comme d'habitude, le diable se cache dans les détails.
Sur les matériaux de 50 pages d'assaut nous pouvons résumer qu'il y a des idées et à partir d'elles vous pouvez faire un plan d'attaque assez raisonnable.
Bien que la plupart soient des individus, personne ne résiste au travail d'équipe. Après tout, le travail en équipe permet de paralléliser les tâches, ce qui accélère l'ensemble du projet.
Et voici les détails : le travail d'équipe au sens classique suppose que l'exécutant reçoit la tâche et la réalisera dans le temps imparti. Il sera alors possible de planifier l'avancement du projet à partir d'un centre unique et de distribuer les tâches aux exécutants. En effet, les exécutants sont occupés à faire leurs propres choses et ne peuvent pas concentrer tout leur temps sur le projet externalisé. Il y aura donc inévitablement un déséquilibre dans le développement du projet.
Je pense que la solution pourrait être un tableau d'annonces où le manager fixerait les tâches et où les exécutants prendraient ce qu'ils peuvent et rendraient compte des progrès et des délais. Si les termes de référence sont clairement formalisés, le projet sera achevé avant même de commencer :)
Et encore un détail, il serait bien d'avoir une liste de noms de variables et de méthodes couramment utilisés, non pas que ce soit fondamental, mais ce sera plus facile si c'est standardisé. Bien sûr, il est difficile de dresser une telle liste, mais on peut élaborer (ou emprunter) quelques principes généraux de création de noms.
Si les MC ne sont pas actifs au cours des deux prochaines semaines, le projet peut être abandonné, ou déplacé vers un emplacement commercial ailleurs.
Car sans contrôle MK, le projet en tant qu'opsource perd son sens.
C'est ce que tu dis.
Au moins deux d'entre nous, toi et moi, pouvons tout faire nous-mêmes.
ZZY et comme vous l'avez bien dit, le développement personnalisé est déjà un développement commercial.
Puisque du temps est dépensé et qu'un seul possède le code source, la conclusion est simple.
Ok, pendant qu'on cherche le Père Noël,
Je vais poster toutes les bêtises que je déterre dans mon cerveau, peut-être qu'à partir de cela il sera possible de composer au moins quelques TOR.
Moteur de grille
1. initialisation de la grille
2. workflow de la grille
3. formation de la grille
1) la topologie de la grille peut être définie par des champs binaires
plus de détails ici http://cgm.computergraphics.ru/content/view/25 section 7.Direct coding
La séparation en grammaires ou le codage direct est déjà une superstructure par rapport à la méthode d'initialisation, de toute façon à la fin tout se résume au codage direct.
Ainsi, les topologies elles-mêmes (qui représentent l'essentiel des difficultés de spécification d'un réseau) sont réduites à l'écriture de méthodes permettant de réaliser une table de codage direct.
L'article dit qu'il est impossible de spécifier des liens inverses, mais si pour chaque rang de retard l'opérateur crée sa propre matrice de liens alors le problème disparaît (bien que la matrice sera pleine et non triangulaire comme dans le retard zéro).
Il s'avère que la superstructure sur la méthode de codage direct doit savoir quel rang de retard le réseau utilise.
Les types de neurones doivent également être spécifiés dans la superstructure (sur ce point, je n'ai pas encore trouvé de solution, je ne sais pas si je dois écrire et surcharger les types de neurones ou les définir par des méthodes plus libérales) ?
On peut s'arrêter à la surcharge des types durs pour l'instant et s'il y a une méthode de codage souple, on l'ajoutera à la liste des surcharges.
2) Le coup de travail est conditionné par les liens prescrits (en utilisant l'agrégation de données) et les types de neurones, je l'ai exposé à la page 5. Il devrait y avoir 4 tableaux de données à l'extérieur : Entrées de la grille, sorties des neurones, poids, sorties de la grille. L'accès externe aux entrées et sorties du réseau est nécessaire pour l'alimentation par exemple et pour l'utilisation opérationnelle du réseau. L'accès externe aux poids est nécessaire pour l'apprentissage. Un accès externe aux sorties des neurones est nécessaire pour les envoyer au GPU pour le calcul. En principe, je pense que les tableaux de données devraient initialement être externes, et que ces données externes devraient déjà être agrégées dans le réseau.
3) Formation. Je penche pour l'entraînement avec GA comme méthode qui ne dépend pas de la topologie du réseau, je suggère de le prendre comme base et si possible/besoin de le surcharger à la bonne.
Trois tâches sont à l'ordre du jour.
Une couche est une union de neurones qui ne dépendent pas de la même itération et qui ont le même type.
La séparation est en fait très réaliste.
Par exemple, il existe l'interface IEvolvable. Une interface pour le côté génétique de la grille. Ainsi, par exemple, vous et Andrei pouvez tranquillement voir la génétique, en utilisant uniquement cette interface.
C'est ici que l'héritage multiple serait vraiment utile, d'ailleurs.
________________
D'accord, je vais essayer d'écrire les interfaces aujourd'hui.
Au fait. Le chef de projet peut être gpwr. J'en serai partiellement responsable.
En principe, nous pouvons commencer le projet.
Il s'agit d'un rappel pour vous-même et pour les autres des types de liaison de données.
Il y a une nuance dans le problème du workflow, puisque les méthodes de traitement des données dépendent du type de neurone, elles doivent faire partie d'un objet du type de neurone.
La nuance réside dans ce qu'il faut considérer comme une couche. Si une telle formulation, que j'ai donnée, il serait difficile d'organiser le calcul dans le GPU.
Si on s'en tient à la formulation de TheXpert , il y aurait des problèmes de charge sur le GPU.
Dans l'ensemble, je penche pour la formule de compromis (combinaison), elle présente moins de problèmes, bien qu'elle hérite du problème de la charge du GPU.
La couche est une union de neurones qui ne dépendent pas de la même itération et qui ont le même type.
Des idées ?
PS : des objections ?