"New Neural" est un projet de moteur de réseau neuronal Open Source pour la plateforme MetaTrader 5. - page 50

[Andrey Dik]

Urain:

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.

1) La nouveauté réside dans ce qu'il faut considérer comme une couche. Si une telle formulation, comme je l'ai donnée, il serait difficile d'organiser le calcul dans le GPU.

2) Si je m'arrêtais à la formulation de TheXpert , il y aurait des problèmes avec le chargement du GPU.

1) Pourquoi ?

2) Pourquoi ?

[TheXpert]

Urain:

Une couche est un amalgame de neurones ne dépendant pas de la même itération et du même type.

Comment ça ? Comment allez-vous extraire le jus d'un GPU sans représentation vectorielle ? C'est l'une des choses que j'envisage.

[Mykola Demko]

LeXpert:
Comment faites-vous ? Comment allez-vous extraire le jus du GPU sans représentation vectorielle ? C'est l'une des choses que je prends en compte.

Pourquoi sans vecteur ? Les tableaux de données sont externes, il ne reste plus qu'à préciser quelles données font quoi avec lesquelles.

Ainsi, vous disposez de données sur les neurones présents dans une couche, et vous les envoyez au GPU pour qu'il calcule le vecteur de cette couche et ainsi de suite à travers les couches.

ZS ah oui dans le modèle de neurones que j'ai dessiné, il faut introduire le concept de données pour stocker les calculs intermédiaires (enfin pour travailler avec le GPU elles doivent être externes aussi).

[Mykola Demko]

joo:

1) Pourquoi ?

2) Pourquoi ?

1) Parce que dans ma formulation, une couche peut contenir différents types de neurones, et qu'il s'agit de tâches atypiques qui ne peuvent être transmises au GPU.

2) Parce que dans la formulation d'Andrew, un neurone peut être une couche et que cela risque de sous-charger le GPU.

ZS en général, on choisit le moindre mal, la sous-charge du GPU n'est pas aussi terrible que l'incapacité potentielle d'utiliser le GPU.

[Mykola Demko]

c'est dommage que mql n'ait pas de pointeurs sur les données, sinon nous pourrions simplement agréger les données des vecteurs aux neurones directement.

Halte, pourquoi avons-nous besoin de l'agrégation, si nous pouvons simplement passer l'index du vecteur de données à la place ? ce serait la même liaison d'accès direct.

ZZI Créez un objet de référence de données dans un neurone au lieu d'un objet de données.

[TheXpert]

Urain:

2) parce que dans la formulation d'Andrei, un seul neurone peut être une couche et cela risque de sous-charger le GPU.

Si elle peut être fusionnée... Alors il devrait être fusionné.

[Mykola Demko]

LeXpert:
Si elle peut être fusionnée... Alors il devrait être fusionné.

C'est le problème si elle le peut, et cela dépend de deux conditions, l'indépendance à une itération et la similitude avec les neurones des autres couches (c'est-à-dire la façon dont elle traite les données en interne).

[Mykola Demko]

J'ai des bribes d'idées sur la façon d'organiser un gaz de neurones en expansion avec un tel moteur, mais elles ne sont pas encore formulées en mots.

Une seule thèse : la réinitialisation du réseau sera nécessaire. Ces initialisations doivent être disponibles pour l'algorithme d'apprentissage.

[Vladimir]

TheXpert:

Le chef de projet peut être gpwr. Une partie de ça pourrait être moi.

Je vous remercie de votre confiance, mais je ne pense pas que je serais un bon candidat pour le poste de chef de projet. Je vais vous expliquer pourquoi.

1. La programmation n'est pas ma spécialité. Je le fais comme un hobby. Je ne suis pas familier avec les nombreuses nuances de la coordination d'un groupe de programmeurs.
2. Au cours des 15 dernières années, j'ai géré plusieurs projets au travail. J'ai constaté que le projet que je gère est mis en œuvre avec succès dans une atmosphère où les membres sont obligés d'exécuter mes ordres (dictature) de peur de perdre leur emploi et leur salaire. Dans une atmosphère démocratique, comme c'est le cas ici, où les membres du projet ne sont pas payés et n'ont aucun moyen de pression pour les garder dans l'équipe de projet, la diktatura n'est pas une méthode appropriée et il est très difficile de progresser sans eux.
3. Le dirigeant lui-même doit être intéressé par le projet. Jusqu'à présent, je m'intéresse à la question en tant qu'observateur. Comme je l'ai déjà mentionné, les réseaux de neurones classiques ne m'intéressent plus, notamment la question de leur codage dans MQL5. Je m'intéresse maintenant aux méthodes de transformation des informations d'entrée. Lorsque j'aurai terminé mon auto-formation à ces méthodes et que je les aurai expérimentées aux prix du marché, mon intérêt se portera sur autre chose.
4. La gestion de ce projet (ainsi que de tout autre projet) nécessite du temps et du dévouement, que je n'ai pas pour le moment (j'ai déjà un projet au travail).

De tout ce qui précède, ma recommandation est la suivante.

1. Les MC devraient être des participants au projet bien rémunérés afin qu'il y ait un intérêt financier à participer à ce projet et à le mener à bien. Comme je vis aux États-Unis, mes normes de rémunération sont plus élevées (c'est probablement la raison pour laquelle les MC ne m'ont jamais demandé d'écrire un article, même lorsque je le proposais moi-même). Par exemple, je pense que ce projet sera une réussite si chaque participant se voit offrir au moins 10 000 dollars à la fin du projet.
2. Le chef de projet doit être représentatif du MC. Il doit également fixer les exigences, les délais et leur paiement. De nombreux codes open source sont créés dans les universités, par des étudiants, dont les superviseurs utilisent le diplôme comme motivation. Vous ne pouvez pas vous en passer.

[TheXpert]

gpwr:

Le PM n'a pas besoin d'être un programmeur. C'est une honte que vous refusiez.