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

 
joo:

Laquelle est la plus rapide est claire. Mais combien de fois dans toute la formation devrez-vous écrire dans le fichier ? - Une fois ?

Par conséquent, la vitesse n'est pas critique, mais le contrôle visuel est simplifié.

Je ne dirais pas qu'un fichier xml serait facile à contrôler visuellement.

Je peux toujours utiliser une sorte de modèle sous la forme d'un fichier xml, mais la visualisation d'une grille comportant 1500 neurones dans une seule couche serait un véritable calvaire, d'où la difficulté de créer un fichier xml, sans pour autant obtenir une bonne visualisation. Bien que je ne le rejette pas, lorsque vous l'enregistrez, vous pouvez également le dupliquer en xml.

MetaDriver:

Qu'est-ce que j'entends par initialisation? Si le chargement des poids, c'est une chose. Si configurer la grille + charger les poids, c'est autre chose.

--

Bien. Je vais chanter.

Il existe deux façons de transposer la configuration du réseau intermédiaire (structure, type) dans le code mql5.

Le premier : la configuration dynamique du réseau lors de l'initialisation à partir des classes de la bibliothèque. Un tel réseau regorge de tableaux dynamiques et de liens via des pointeurs. Cette approche a implicitement dominé jusqu'à présent.

Mais il existe un deuxième moyen : générer un maillage rigide (avec des tableaux statiques et des accès directs aux adresses (index) souhaitées) après une préconfiguration et un mappage en xml.

Un tel moteur peut être beaucoup plus attrayant pour les utilisateurs, en raison de la vitesse (sensiblement) plus élevée du réseau généré. Mais plus compliqué à mettre en œuvre. En fait, il faudrait faire un compilateur xml2mql.

Moi, en fait, pour la deuxième voie. J'espère que les méta-citations nous aideront, si nous sommes bloqués.

Premier moyen.

La deuxième solution a été écartée (je ne me souviens pas exactement, mais dans les premières pages), parce qu'à l'avenir, dans la catégorie des "utilisateurs", il y aura des gens qui ne savent pas ce qu'est F7.

En outre, le moteur est conçu pour être facilement extensible, et quiconque connaît l'objectif de F7 peut ajouter un autre type de grille ou inventer la sienne.

ZY comprend votre attachement au codage par gabarit, mais est d'accord avec la deuxième façon, nous aurons de gros problèmes avec l'implémentation des algorithmes d'apprentissage et l'extension des types de neurones, de plus cela devra toujours être optimisé pour le GPU. Il y a de sérieux problèmes avec la première variante, les choses les plus simples que tout le monde est capable de faire, et rien que de décrire le projet de moteur universel me fait griller le cerveau.

 

Demain, je copierai mon travail sur le stockage des prototypes de réseau, la mise en place des tâches de formation, le stockage des solutions trouvées ici depuis mon ordinateur de travail.

Tout en xml

Je pense que l'intensité des ressources nécessaires à l'analyse des fichiers xml est trop exagérée.

N'oubliez pas qu'il s'agit d'une procédure unique.

De plus, l'écriture d'un analyseur de fichiers xml natif pour MQL5 est une tâche triviale comparée à la complexité d'un projet de réseau neuronal.

 
Urain:

Le premier moyen.

La deuxième solution a été écartée (je ne me souviens pas exactement, mais dans les premières pages), car à l'avenir, les personnes qui ne savent pas ce qu'est F7 seront enrôlées dans la catégorie "utilisateur".

En outre, ce moteur est censé être facilement extensible, et quiconque connaît le but de F7, peut ajouter quelques maillages supplémentaires pour lui-même ou inventer les siens.

Je n'ai qu'une seule question à poser en raison de mon manque de compétence en matière de maillage.

Un type de maillage peut-il être défini de manière unique par une table de consultation, c'est-à-dire que l'on peut créer un maillage abstrait universel qui découle simplement d'une table de consultation donnée ? En d'autres termes, un réseau véritablement universel ?

Si la réponse est oui, alors le type de grille est défini par l'éditeur de configuration de grille AVANT la création de la vue intermédiaire, et aucune modification de la bibliothèque universelle n'est nécessaire. Je veux dire qu'il ne sera jamais nécessaire (s'il n'est pas défaillant), quelle que soit la structure de la grille. La seule chose que l'on puisse faire est de l'optimiser, d'élargir la bibliothèque de convertisseurs non linéaires, de méthodes d'entraînement, etc.

Si la réponse est "non", n'hésitez pas à m'envoyer des liens vers des exceptions qui ne correspondent pas à cette approche.

--

Si la représentation xml de la description du réseau est bien pensée et complètement abstraite de l'implémentation mql (ce qui est correct), alors les alternatives ne semblent pas contradictoires. Non seulement les deux peuvent être mises en œuvre, mais les alternatives peuvent également être croisées.

 
MetaDriver:
...

La réponse n'est pas binaire,

D'une part, la réponse est négative, la table de relation elle-même ne spécifie pas le typage des neurones.

D'autre part, la réponse est positive, il est possible de spécifier des types sous forme numérique (on crée un objet d'un type particulier hérité d'un ancêtre commun par le commutateur).

Donc, dans l'ensemble, un tableau paramétrique et une table de relation sont parfaits.

Mais d'un autre côté, même l'éditeur de configuration comporte des paramètres (nombre de couches, nombre de neurones dans chaque couche, types de neurones dans la couche) et ce, avant de créer des liens.

 
MetaDriver:

En d'autres termes, un réseau véritablement universel ?

De l'alimentation en amont, oui. Pour les autres, il faut regarder la topologie.
 
LeXpert:
De l'alimentation, oui. Pour les autres, il faut regarder la topologie.

La topologie est définie par la table de liaison.....

?

 
MetaDriver:

La topologie est définie par la table de liaison .....

Et la fonctionnalité des pièces à relier.
 
LeXpert:
Et la fonctionnalité des pièces à relier.

OK, entrons un peu plus dans les détails ici.

Cette fonctionnalité peut-elle être donnée par une (petite) table finie ? Quelle est la différence entre les neurones de différents types (en dehors des fonctions d'activation) ?

 
MetaDriver:

OK, entrons un peu plus dans les détails ici.

Cette fonctionnalité peut être donnée par une (petite) table finie ? Quelle est la différence entre les neurones de différents types (en dehors des fonctions d'activation) ?

A proprement parler, non.

D'abord un cas simple. Disons que nous avons des neurones linéaires, sigmoïdes et tangents. Si nous voulons ajouter un nouveau type d'activation, nous devons étendre l'énumération des types d'activation.

En gros, on s'en fout. Mais d'abord, pourquoi, par exemple dans le réseau de Kohonen, la couche de sortie aurait-elle besoin d'un signe de certaines=certaines fonctions d'activation ? Ce sont des informations superflues et redondantes.

Deuxièmement, cette liste est théoriquement illimitée.

Troisièmement, chaque réseau peut présenter des particularités dans son fonctionnement et son agencement. Par exemple, un réseau de Kohonen (SOM) peut disposer d'un paramètre de fonction de voisinage et d'un indicateur permettant de déterminer s'il convient d'afficher les résultats en tant que sortie ou seulement le leader (en mettant à zéro tous les non leaders).

Dans les modèles logiques, par exemple, les paramètres configurables se trouvent dans la fonction d'activation. Est-ce également le cas dans le modèle général ?

Dans la couche MLP, il peut s'agir d'un drapeau de présence d'un seul neurone.

____________________________

D'ailleurs, il est beaucoup plus facile de vérifier la validité du xml que de la représentation binaire. Et la sauvegarde/restauration n'est essentiellement pas une question de temps.

 
TheXpert:

1. à proprement parler, non.

D'abord un cas simple. Disons que nous avons des neurones linéaires, sigmoïdes et tangents. Si nous voulons ajouter un nouveau type d'activation, nous devons étendre l'énumération des types d'activation.

En gros, on s'en fout. Mais d'abord, pourquoi, par exemple dans le réseau de Kohonen, la couche de sortie aurait-elle besoin d'un signe de certaines=certaines fonctions d'activation ? Il s'agit d'informations inutiles et superflues.

Deuxièmement, cette liste est théoriquement illimitée.

Troisièmement, chaque réseau peut avoir ses propres particularités de fonctionnement et de structure. Par exemple, un réseau de Kohonen (SOM) peut disposer d'un paramètre de fonction de voisinage et d'un indicateur permettant de déterminer s'il convient d'afficher les résultats en tant que sortie ou seulement le leader (en mettant à zéro tous les non-leaders).

Dans les modèles logiques, par exemple, les paramètres configurables se trouvent dans la fonction d'activation. Est-ce également le cas dans le modèle général ?

Dans la couche MLP, il pourrait s'agir d'un drapeau pour avoir un seul neurone.

____________________________

2 . d'ailleurs, le xml est beaucoup plus facile à vérifier que la représentation binaire. Et le sauvetage n'est essentiellement pas une question de temps.

1. Pourquoi pas. Mon idée est la suivante : créer une "base d'éléments" universelle à partir de laquelle des réseaux neuronaux de tout type peuvent être "soudés" (et qui peut être extensible). Les éléments de cette base sont définis par des définitions exactes et non ambiguës - des formules. Si nécessaire avec application du pseudocode. Mais pas sous la forme de code mql, afin de se détacher des implémentations - elles peuvent être améliorées avec le temps. Après la création de la base d'éléments abstraits (si possible), vous pouvez formater un fichier xml, capable de décrire toutes les connexions entre les éléments. Après l'approbation de la description xml, le projet peut être facilement mis en parallèle : écrire séparément

1) Mise en œuvre des composants. => le résultat est une bibliothèque de composants.

2) configurateur(s) de type/structure de réseau => sortie - graphique, pas à pas ou tout autre configurateur, sauvegarde de la configuration dans un fichier xml.

3) traducteur(s) en code mql. => la sortie est soit (1) un réseau mql-neuronal super-duper auto-configurant, prenant un fichier xml comme paramètre, soit (2) un compilateur dans un réseau rigide particulier basé sur mql.

Quelque chose comme ça. Ça semble logique.

2. Oui.

Raison: