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

 
LeXpert:
...

À propos, il est beaucoup plus facile de vérifier la validité d'un fichier xml qu'une représentation binaire. Et la sauvegarde/restauration n'est essentiellement pas une question de temps.

Quelle est, selon vous, la difficulté du contrôle dans la représentation binaire des liens ?

Donnez-moi un exemple de cas où c'est difficile.

ZZZ non seulement je ne peux pas penser à un exemple, mais je ne peux même pas imaginer quel genre de topologie il s'agit, que lorsqu'on représente les liens par une table binaire, il est difficile de vérifier la validité de n'importe quel lien.

 
Urain:

Donnez-moi un exemple de cas où c'est difficile.

Regardez. Vous avez un peu modifié le format de stockage ou les données se sont mélangées et disons qu'au lieu d'une taille de tableau, vous obtenez la partie inférieure du double, c'est-à-dire un tableau de taille énorme.

Et dans le xml, vous avez la taille enveloppée dans une balise

 
MetaDriver:

1. pourquoi pas.

Parce qu'il n'y a pas de base universelle. C'est juste les trois grilles dont je me suis souvenu.

 
LeXpert:

Regardez. Vous avez un peu modifié le format de stockage ou les données ont été confondues et disons qu'au lieu d'une taille de tableau, vous obtenez le bas du dubble, c'est-à-dire un tableau de taille énorme.

Et dans le xml vous avez la taille enveloppée dans une étiquette

"Changer un peu le format de stockage", c'est comme changer le xml en avi sans s'en rendre compte.

Tout changement de format est géré par quelqu'un qui connaît bien les deux formats, + lors du changement de format, le débogage et les tests sont inévitables.

Un petit changement dans le format de stockage ne peut donc pas être considéré comme un argument.

À propos des données égarées (bien, stocker les dubles et les sunlongs ensemble, je déconseille et corrige), pour éviter l'égarement écrire la somme de hachage pour vérifier l'exactitude du fichier lu, d'autres options lorsque les données peuvent s'égarer ne prévoient pas.

Ainsi, nous disposons d'un format de stockage pour un réseau long avec des informations sur la grille :

[somme de hachage] [nombre de couches]

[type de couche] [nombre de neurones]

[type de couche] [nombre de neurones]

[type de couche] [nombre de neurones]

[type de couche] [nombre de neurones]

[type de couche] [nombre de neurones]

plus loin à la fin du fichier les ulong qui définissent la table binaire.

Comment convertir un ulong en tableau de caractères booléens [64] J'ai une fonction prête.

 
LeXpert:

Parce qu'il n'y a pas de base universelle. C'est juste les trois grilles dont je me suis souvenu.

Je ne suis pas d'accord, mais je ne vais pas argumenter maintenant, je répondrai plus tard (un jour ou deux) quand j'aurai les faits en main.

vous allez essayer de bombarder ma théorie en même temps :)

 
Urain:
Merde... Peut-être que je ne comprends pas. Pourquoi faire un casse-tête ?
 
TheXpert:
Merde... Peut-être que je ne comprends pas. Pourquoi dois-tu inventer ta propre douleur dans le cul ?

Vous n'êtes pas le seul à ne pas comprendre :)

À mon avis, le format binaire est la chaîne qui enchaîne les données à la mise en œuvre, quelque chose dont il faut se débarrasser dès que possible dans une conception compétente. Le format binaire est bon pour le conditionnement des données. Par exemple, dans MT4, les données étaient stockées de la manière suivante. Mais il a été raisonnablement fait là pour réduire la charge sur le réseau, et l'auteur/lecteur est un développement interne.

Mais pourquoi s'embêter avec une telle élaboration ? Afin d'écrire votre propre éditeur pour ce format et avoir plus de problèmes avec lui ? xml, json, ou même ini seraient plus corrects.

 
Vladix:

Vous n'êtes pas le seul à faire partie de la foule des malentendants :)

À mon avis, le format binaire est une entrave, enchaînant les données à l'implémentation, quelque chose dont il faut se débarrasser dès que possible dans une conception compétente. Le format binaire est bon pour le conditionnement des données. Par exemple, dans MT4, les données étaient stockées de la manière suivante. Mais c'est raisonnablement fait là pour réduire la charge sur le réseau, et l'auteur/lecteur est un développement interne.

Et pourquoi s'embêter avec une telle élaboration ? Afin d'écrire votre propre éditeur pour ce format et avoir plus de problèmes avec lui ? xml, json, ou même ini sera mieux.

Proposez une autre mise en œuvre, je ne suis pas contre, discutons, comparons, décidons de ce qui est mieux.

Pour l'instant, je n'ai vu qu'une seule proposition dans le fil de discussion (la mienne), les autres se contentent de dire "faisons du xml, du json, de l'ini", mais personne n'a dit comment le chargement de la grille sera implémenté dans tout cela.

Le tableau des liens binaires est assez simple à comprendre, en passant par les colonnes vous obtenez qui envoyer, en passant par les lignes vous obtenez qui envoyer à (ou vice versa, puisque le tableau est carré, il suffit de se mettre d'accord sur la façon de le prendre).

Et comment il sera mis en œuvre dans d'autres formats, personne ne dit rien.

Parlez.

 

À ce rythme, vos enfants seront d'accord et s'arrêteront à xml, les petits-enfants commenceront à mettre en œuvre.

Votez ou choisissez un ancien.

 
Mischek:

À ce rythme, vos enfants seront d'accord et s'arrêteront à xml, les petits-enfants commenceront à mettre en œuvre.

Vote ou choix d'un ancien .

Que voter si aucune alternative n'est proposée, j'ai une description de l'idée générale de l'algorithme de chargement de la grille, le meilleur format pour stocker cet algorithme dans le bac.

Autres suggestions pour le chargement des algorithmes nevidal, vu que des propositions pour le format de stockage, mais le format de stockage lui-même devrait être choisi en fonction de l'algorithme à charger, pour un algorithme un format est meilleur pour un autre.

Il y aura des suggestions d'algorithmes, mais aussi une discussion de fond sur ce qui est le mieux et dans quel format il est préférable de le stocker.