"New Neural" es un proyecto de motor de red neuronal de código abierto para la plataforma MetaTrader 5. - página 63

 
TheXpert:
...

Por cierto, el xml es mucho más fácil de comprobar su validez que la representación binaria. Y guardar/restaurar no es esencialmente una cuestión de tiempo.

¿Cuál es, en su opinión, la dificultad de comprobar la representación binaria de los enlaces?

Dame un ejemplo de cuándo es difícil.

ZZZ no sólo no se me ocurre un ejemplo, sino que ni siquiera puedo imaginar qué tipo de topología es, que al representar los enlaces mediante una tabla binaria, es difícil comprobar la validez de cualquier enlace.

 
Urain:

Dame un ejemplo de cuándo es difícil.

Mira. Has cambiado un poco el formato de almacenamiento o los datos se han confundido y digamos que en lugar de un tamaño de array obtienes la parte inferior del duble, es decir, un array de tamaño enorme.

Y en el xml tienes el tamaño envuelto en una etiqueta

 
MetaDriver:

1. por qué no.

Porque no hay una base universal. Son sólo las tres rejillas que recordaba.

 
TheXpert:

Mira. Has cambiado un poco el formato de almacenamiento o los datos se han confundido y digamos que en lugar de un tamaño de array obtienes el fondo del doblaje, es decir, un array de tamaño enorme.

Y en el xml tienes el tamaño envuelto en una etiqueta

"Cambió un poco el formato de almacenamiento" suena como cambiar xml a avi y no darse cuenta.

Cualquier cambio de formato es manejado por alguien bien versado en ambos formatos, + cuando se cambia el formato la depuración y las pruebas son inevitables.

Así que un pequeño cambio en el formato de almacenamiento no puede considerarse un argumento.

Sobre los datos extraviados (bueno, almacenar dubles y sunlongs juntos lo desaconsejo y lo corrijo), para evitar el extravío escriba la suma hash para verificar la corrección del archivo leído, otras opciones cuando los datos pueden extraviarse no las preveo.

por lo que tenemos un formato para almacenar una matriz flotante con información de la cuadrícula:

[suma de hash] [número de capas]

[tipo de capa] [número de neuronas]

[tipo de capa] [número de neuronas]

[tipo de capa] [número de neuronas]

[tipo de capa] [número de neuronas]

[tipo de capa] [número de neuronas]

al final del archivo ulong's que definen la tabla binaria.

Cómo convertir ulong en [64] matriz de caracteres booleanos Tengo una función preparada.

 
TheXpert:

Porque no hay una base universal. Son sólo las tres rejillas que recordaba.

No estoy de acuerdo, pero no voy a discutir ahora, contestaré más tarde (un día o dos) cuando tenga los datos en la mano.

intentarás bombardear mi teoría al mismo tiempo :)

 
Urain:
Mierda... Tal vez no lo entiendo. ¿Por qué hacer una molestia?
 
TheXpert:
Mierda... Tal vez no lo entiendo. ¿Por qué tienes que inventarte tu propio dolor de cabeza?

No eres el único que no entiende :)

En mi opinión, el formato binario es un grillete que encadena los datos a la implementación, algo de lo que debería deshacerse cuanto antes en un diseño competente. El formato binario es bueno para empaquetar datos. Por ejemplo, MT4 almacena los datos de esa manera. Pero se hizo razonablemente allí para reducir la carga de la red, y el escritor/lector es un desarrollo interno.

Pero, ¿por qué molestarse en hacer tal elaboración? ¿Para escribir su propio editor para este formato y tener más problemas con él? xml, json, o incluso ini sería mejor

 
Vladix:

No eres el único de los malentendidos :)

En mi opinión, el formato binario es un grillete que encadena los datos a la implementación, algo de lo que hay que deshacerse cuanto antes en un diseño competente. El formato binario es bueno para empaquetar datos. Por ejemplo, en MT4 los datos se almacenaban así. Pero se hace razonablemente allí para reducir la carga de la red, y el escritor/lector es un desarrollo interno.

¿Y por qué molestarse en tal elaboración? ¿Para escribir su propio editor para este formato y tener más problemas con él? xml, json, o incluso ini será mejor.

Sugiere otra implementación, no estoy en contra, discutamos, comparemos, decidamos qué es mejor.

Hasta ahora he visto una propuesta en el hilo (la mía), los demás sólo dicen "hagamos xml, json, ini", pero nadie ha dicho cómo se implementará la carga de la red fuera de todo esto.

La tabla de enlaces binarios es bastante sencilla de entender, yendo por columnas obtienes a quién enviar, yendo por filas obtienes a quién enviar (o viceversa, ya que la tabla es cuadrada, sólo hay que ponerse de acuerdo en cómo tomarla).

Y de cómo se aplicará en otros formatos nadie dice nada.

Habla.

 

A este paso sus hijos estarán de acuerdo y se detendrán en xml , los nietos comenzarán a implementar .

Votar o elegir a un anciano.

 
Mischek:

A este paso sus hijos estarán de acuerdo y se detendrán en xml , los nietos comenzarán a implementar .

Votar o elegir a un anciano .

Qué votar si no se propone ninguna alternativa, tengo una descripción de la idea general del algoritmo de carga de la red, el mejor formato para almacenar este algoritmo en bin.

Otras sugerencias para la carga de algoritmos nevidal, visto sólo propuestas para el formato de almacenamiento, pero el formato de almacenamiento en sí debe ser elegido en función del algoritmo para cargar, para un algoritmo de un formato es mejor para otro.

Habrá sugerencias de algoritmos, también habrá un debate de fondo sobre qué es lo mejor y en qué formato es mejor almacenar.