¿Qué debería añadirse para el soporte adicional de los cálculos matemáticos universales en MQL5 y MQL5 Cloud Network? - página 7

[Viktor Bokov]

Ayuda para entender y arreglar. Ayer instaléMetaTrader 5 Agents Manager
utilizar mi PC en Cloud Computing en
Red en la nube MQL5. Pero aquí está el problema, mi cuenta enhttp://www.mql5.com no muestra agentes, lo que significa que no se me cobrará por usar mi PC. He introducido el nombre de mi cuenta en el propio gestor de agentes de MT5MetaTrader 5.

[Rashid Umarov]

Victuar:
Pero aquí está el problema en mi cuenta enhttp://www.mql5.com no se muestran los agentes, lo que significa que la cuota no goteará para el uso de mi PC. En el propio gestor de agentes de MT5MetaTrader 5, he introducido el nombre de mi cuenta.

¿Qué tal si lee las preguntas frecuentes? - https://cloud.mql5.com/ru/faq

[Yury Reshetov]

Renat:

De ahí la pregunta: ¿qué otras funciones deberían incluirse para mejorar las capacidades de la red de facturación?

Probablemente métodos de clases que pueden ser llamados remotamente y obtener sus valores de los agentes: Remote Procedure Call (RPC). Algo así:

remote:
   ...
   double f(int x);
   double y(doble a, double b, int[] &c);
   void z(double[] &arr);
   void func(SomeObject *so);
   ...

Junto con una llamada a un método, por supuesto, necesitamos pasar los valores de los campos actuales del objeto que llama al método de forma remota al agente.

La idea es que la instancia de la clase principal llama a algún método, y dentro del método se crean instancias de otras clases, que envían tareas a la nube. Se devuelven los resultados.

Por ejemplo, se crea una tarea en forma de cálculo de varias jugadas de ajedrez. En el método principal, que se ejecuta de forma remota, se crean varias combinaciones con una cuenta para un movimiento en forma de objetos de alguna clase y se envían. Estos a su vez, si la jugada no terminó con un resultado o la profundidad del cálculo no superó el límite, vuelven a llamar al mismo método. Y así sucesivamente.

[Renat Fatkhullin]

her.human:

Sin la participación del terminal, esto es algo bueno.

¿Quién generará los datos para este "uno de los agentes"? ¿Podrá hacerlo un script o un indicador?

Cualquiera de los agentes puede generar datos brutos para los demás. Puede enviarse por difusión a todos o a un agente seleccionado.

Cualquier agente podrá enviar tramas de datos a cualquier otro agente.

Para qué sirve la comunicación agente-agente, ilumina al ignorante si puedes.

Para tareas relacionadas en las que es necesario intercambiar datos/resultados de cálculos anteriores.

No tiene por qué estar en la nube. Puede crear una red de agentes de alta velocidad en su área local y ejecutar una tarea compleja con mucho intercambio de datos en ella.

Como resultado, se puede construir una red potente sin necesidad de superordenadores.

[Renat Fatkhullin]

Reshetov:

Probablemente los métodos de la clase que pueden ser llamados remotamente y obtener sus valores de los agentes. Algo así:

Aquí, por supuesto, junto con una llamada al método, tendríamos que pasar los valores de los campos actuales del objeto, que llama a este método de forma remota, al agente también.

No, la única opción viable y realista es intercambiar marcos de datos. La ejecución remota de funciones no es seria, porque nadie en su sano juicio replicaría el entorno de la información.

Como parte del trabajo del marco, la funcionalidad puede ser ampliada:

bool  FrameSend(const long    agent,       // номер агента, или BROADCAST
                const string  name,        // публичное имя/метка
                const long    id,          // публичный id
                const double  value,       // значение
                const string  filename     // имя файла с данными
               );

Por si acaso, a título informativo:

El coste de la latencia de la red es tal que, para optimizar el proceso global, hay que realizar una agrupación explícita de los resultados y transferir los datos con la menor frecuencia posible. Por ejemplo, si hay un problema matemático de alta velocidad (en fracciones de segundo) para 100.000.000 de pasadas, es mejor optimizar el proceso inmediatamente de forma algorítmica en porciones de 1.000-10.000 pasadas y escribir un código de procesamiento por lotes con resultados devueltos en un lote. Esto supondría una gran ventaja respecto a los 100.000.000 de devoluciones, en los que se invertiría mucho tiempo en la red.

Por nuestra parte, nosotros mismos ayudamos seriamente en los casos de tareas de alta velocidad, al dosificar la salida en docenas o cientos de pasadas a cada agente y también al dosificar las respuestas. Esto supone un gran ahorro en la transmisión de la red y mantiene la latencia de la misma al mínimo.

[Yury Reshetov]

Renat:

No, la única opción viable y realista es intercambiar marcos de datos. La ejecución remota de funciones no es seria, porque nadie en su sano juicio replicaría un entorno de información.

No se pueden empaquetar todas las tareas, ya que en algunas tareas de aplicación y muy intensivas en recursos el resultado puede ser el único o no ser detectado en absoluto y las tareas inútiles se descartan por el camino, es decir, los resultados que faltan ni siquiera deberían devolverse.

Entonces hay otra forma de hacerlo. Es decir, la tarea principal genera tareas por su parte, informa a los agentes sobre ello. Y los agentes llaman a métodos remotos con tareas, calculan y si obtienen resultados, llaman a métodos remotos para devolver los resultados.

Por ejemplo, la tarea: buscar los divisores primos de los números de Fermat. Tal vez no haya ningún resultado, o uno, o varios. La cuestión es que la búsqueda de estos divisores tan potenciales es una tarea que consume muchos recursos, porque primero hay que crear un objeto en forma de número grande (en la tarea sólo se pueden especificar dos números como enteros: primo y mantisa, para reducir el coste de la transferencia de información). A continuación, el número para comprobar si es primo (ejecutar una prueba simplificada, que revelará que el número en más del 90% no es primo). Y luego, si la prueba de simplicidad se pasa con éxito, en el bucle, cuadrando el módulo se busca una coincidencia. Si la condición antes del final del bucle no coincide, entonces no habrá resultado y no habrá nada que devolver. En este caso, el agente debe solicitar remotamente el siguiente trabajo llamando remotamente al método apropiado desde la aplicación anfitriona. Si encuentra el resultado, debe llamar a otro método y pasar el mismo resultado.

Es decir, las tareas son diferentes y las estructuras del marco no son adecuadas para todas. Y el coste de latencia de la red en el ejemplo anterior también es insignificante, ya que una tarea consiste en pasar dos enteros a un agente.

[Renat Fatkhullin]

Reshetov:

No todas las tareas pueden agruparse, ya que en algunas tareas de aplicación y muy intensivas en recursos puede haber un solo resultado o ninguno, y las tareas no concluyentes se descartan a medida que avanza la reproducción, es decir, los resultados que faltan ni siquiera tienen que devolverse.

Si se utiliza un esquema de trama, simplemente no devuelva resultados vacíos al "agente servidor" o simplemente devuelva la bandera "paquete calculado, sin datos".

¿Sabes cómo funciona el modo de fotogramas? La cabecera EA se inicia en la ventana del terminal y espera las respuestas (tramas de datos) de los agentes remotos. Es decir, la parte del servidor se sitúa en el gráfico, recibe los datos y puede visualizar cualquier cosa.

Lea y pruébelo usted mismo: https://www.mql5.com/ru/code/914

ATENCIÓN: Hay que volver a cargar el vídeo

[Yury Reshetov]

Renat:

Si se utiliza un esquema de marcos, simplemente no devuelva resultados vacíos al "agente servidor".

Bueno, eso es sólo la base. Las principales tareas, que son muy intensivas desde el punto de vista computacional, son recursivas. Y la nube no está pensada para este tipo de tareas porque está diseñada sólo para la búsqueda completa. En muchas tareas aplicadas no utilizamos la fuerza bruta ya que no tiene perspectiva. Se necesitan tareas recursivas para buscar en profundidad y en anchura y en profundidad con anchura. Por ejemplo, la síntesis de moléculas. Es decir, se construye un árbol de soluciones potenciales en el transcurso de la obra, cada rama es intensiva en recursos computacionales. Pero no todas las ramas son eficaces. Es decir, la búsqueda se detiene en algún lugar, pero al mismo tiempo, la búsqueda continúa para otras ramas potenciales en profundidad o anchura.

La búsqueda completa no se utiliza prácticamente en ningún sitio, ya que para la mayoría de las tareas de aplicación no se tarda lo suficiente en encontrar una solución (por ejemplo, el problema de analizar las jugadas de ajedrez). Sin embargo, los métodos recursivos con corte de ramas de solución no prospectiva dan una gran velocidad, especialmente en los cálculos distribuidos. Por eso, si quiere atraer a los ingenieros de aplicaciones a la nube, debe ajustar la nube a sus tareas, en lugar de pensar que lo dejarán todo y que probarán todas las variantes seguidas, independientemente de sus perspectivas. Será más fácil para ellos crear su propia red de computación distribuida, aunque sea menos rápida en términos de gigaflops y tenga menos ordenadores, pero será más eficiente, porque buscará sólo en direcciones prometedoras y encontrará la solución necesaria mucho más rápido que la red en la nube. Y muchos lenguajes de programación tienen un conjunto de herramientas para ello, es decir, implementaciones RPC ya hechas.

Por ejemplo, la misma búsqueda de los divisores primos de los números de Fermat puede dividirse en subtareas. La aplicación principal genera las tareas. La siguiente capa crea objetos y realiza una rápida comprobación de la simplicidad de las tareas restantes. La siguiente capa busca las condiciones, es decir, si se encuentra un divisor de un número de Fermat o no. Los puestos de trabajo se generan de nuevo a partir de los números encontrados. La siguiente capa realiza una comprobación de simplicidad completa, y si el número no es primo, genera trabajos. Si es primo, devuelve el resultado a la aplicación principal. La siguiente capa factoriza los divisores no simples de los números de Fermat y genera trabajos para la capa anterior a partir de ellos.

Esto crea una cinta transportadora, donde los agentes de cada capa realizan sus tareas. No está claro si se encontrará el resultado. Lo importante es que, a sabiendas, los números sin solución se descartan en el transportador. En otras palabras, ahorra muchos recursos computacionales, en lugar de intentar amontonar miles de agentes en tareas poco prometedoras e intentar machacarlas.

[Renat Fatkhullin]

Reshetov:

Eso es sólo la base. Las tareas principales son recursivas y consumen muchos recursos para los cálculos. Y la nube no está pensada para este tipo de tareas porque está diseñada sólo para la búsqueda completa. En muchas tareas aplicadas no utilizamos la fuerza bruta ya que no tiene perspectiva. Las tareas recursivas son necesarias para la búsqueda en profundidad y en anchura y en profundidad con anchura. Por ejemplo, la síntesis de moléculas. Es decir, se construye un árbol de soluciones potenciales en el transcurso de la obra, cada rama es intensiva en recursos computacionales. Pero no todas las ramas son eficaces. Es decir, en algún lugar la búsqueda se detiene, pero al mismo tiempo, la búsqueda continúa para otras ramas potenciales en profundidad o anchura.

Cálculos por lotes en 1.000-10.000 pases, y devuelve sólo los resultados significativos. Se trata de una técnica algorítmica muy eficaz.

Escribí sobre ello específicamente más arriba.

La búsqueda completa casi nunca se utiliza, porque para la mayoría de los problemas aplicados no se tarda lo suficiente en encontrar una solución (por ejemplo, un problema de análisis de movimientos de una partida de ajedrez). Pero los métodos recursivos con corte de ramas de solución no prospectiva dan una gran velocidad, especialmente en los cálculos distribuidos. Por eso, si quiere atraer a los ingenieros de aplicaciones a la nube, debe ajustar la nube a sus tareas, en lugar de pensar que lo dejarán todo y que probarán todas las variantes seguidas, independientemente de sus perspectivas. Les resultará más fácil crear su propia red de computación distribuida, aunque sea menos rápida en términos de gigaflops y tenga menos ordenadores, pero será más eficiente, porque buscará sólo en áreas prometedoras y encontrará la solución adecuada mucho más rápido que la red en la nube. Y muchos lenguajes de programación tienen un conjunto de herramientas para ello, es decir, implementaciones de RPC ya hechas.

Por ejemplo, la misma búsqueda de los divisores primos de los números de Fermat puede dividirse en subtareas. La aplicación principal genera las tareas. La siguiente capa crea objetos y realiza una rápida comprobación de la simplicidad de las tareas restantes. La siguiente capa busca las condiciones, es decir, si se encuentra un divisor de un número de Fermat o no. Las tareas se forman de nuevo a partir de los números encontrados. La siguiente capa realiza una comprobación de simplicidad completa, y si el número no es primo, genera trabajos. Si es primo, devuelve el resultado a la aplicación principal. La siguiente capa factoriza los divisores no primos de los números de Fermat y genera trabajos para la capa anterior.

Lea más arriba sobre el intercambio de datos y el ejemplo de demostración:

1. Ya tiene un proceso maestro que controla el trabajo de los agentes. Se asienta sobre un gráfico y acepta marcos (de gran tamaño a medida) de los agentes.
2. El proceso maestro ya puede recuperar, visualizar, procesar y guardar los datos personalizados resultantes
   

Se propone una ampliación del intercambio de datos para que el proceso maestro pueda pasar adicionalmente cualquier dato personalizado adicional a cualquier agente. Como resultado, es posible leer por partes, repartiendo nuevas condiciones personalizadas a los agentes remotos. Como resultado, puede leer como quiera, cambiando las condiciones cada vez.

Otra posible ampliación, cuando los agentes no sólo pueden recibir tareas del maestro, sino también intercambiar datos entre ellos. Por supuesto, puedes hacerlo a través del asistente (que puede ser muy lento si hay muchos datos), pero es aún más eficiente y rápido hacerlo directamente a través de los servidores de la nube.

[Yury Reshetov]

Renat:

Otra posible ampliación es que los agentes no sólo reciban tareas del asistente, sino que también se transfieran datos entre ellos. Por supuesto, puedes hacerlo a través del asistente (que puede ser muy lento si hay muchos datos), pero es aún más eficiente y rápido hacerlo directamente a través de los servidores de la nube.

Esto es lo que se necesita, es decir, la transferencia recursiva de datos de un agente a otro sin asistente, pero con garantía de retorno de los resultados al maestro. Para que el agente no pueda tomar una tarea y dejar de trabajar sin completarla, por ejemplo, porque el ordenador se apagó y se rompió la rama potencialmente efectiva de la solución.

Es decir, por ejemplo, la tarea de analizar una partida de ajedrez. El asistente ordena las piezas y genera asignaciones para el color de las piezas que deben moverse ahora, es decir, una pieza - una asignación. Cada agente, tras recibir una tarea para su pieza, descarta las variantes poco prometedoras para su posterior análisis, cuando una pieza no puede moverse, y forma nuevas formaciones que se pasan como tareas para las piezas enemigas. Y así sucesivamente, hasta que se produzca el empate o se supere la profundidad de búsqueda.

Si dicha tarea se confía a la implementación actual de la nube, entonces sólo puede generar paquetes de tareas para la búsqueda completa. Y la nube no tiene suficientes agentes para eso, y es poco probable que el asistente tenga suficiente memoria para agrupar todos esos trabajos. Porque no hay ningún mecanismo para filtrar las variantes poco prometedoras. Pues con cada nuevo movimiento analizado de piezas, el número de tareas crece exponencialmente, pero también una parte considerable de ellas se descarta y no genera tareas sin sentido, como en el sobreesfuerzo completo. Y sólo se puede averiguar con perspectiva después de bucear hasta cierta profundidad o anchura del árbol de decisión. Y la profundidad en esta implementación de la nube es de 1, es decir, del maestro al agente y viceversa.

Lo que quiero decir es esto. Para el comercio, también es necesaria la implementación de la búsqueda recursiva con el recorte de los callejones sin salida. Es mejor buscar no sólo un único extremo, sino un conjunto de extremos locales (de hecho, hay muchos). Y el espacio de búsqueda de todas las variantes posibles es astronómico, es decir, ningún agente tomado de todas las redes informáticas distribuidas será suficiente. Para ello, en cada paso enumeramos las vecindades más cercanas de un punto (coordenadas del punto - parámetros de entrada del EA) a cierta distancia del mismo y separadas por algún valor angular, para ver si mejoran los resultados en comparación con el actual o no. Si alguno de ellos es peor o supera la profundidad de búsqueda, lo descartamos. Si mejoran, buscamos recursivamente y formamos un conjunto de tareas adicionales a partir de los puntos mejorados que distribuimos a los agentes. Si se encuentra un extremo localmente (todos los puntos de la vecindad sólo empeoran el resultado actual), devolvemos el resultado a la aplicación principal. Una vez identificados los extremos, se entregan al asistente y se analizan más a fondo mediante pruebas de avance.

Esta tarea no puede resolverse directamente, ya que el número de variantes es astronómico. Un algoritmo genético tampoco busca los extremos locales (se detiene cerca del global también en la vecindad inmediata) y sólo muestra los resultados intermedios, independientemente de su extremo. No quiere decir que el espacio de búsqueda del algoritmo genético y del algoritmo de fuerza bruta sea limitado y discreto. Se trata de la búsqueda del máximo número de extremos locales pero de forma rápida, es decir, con el corte de las generaciones no prospectivas de tareas del maestro a los agentes y del agente a otros agentes y con un alcance ilimitado (pero de forma que se puedan establecer restricciones si es necesario, por ejemplo, la profundidad de búsqueda en dichos algoritmos siempre está limitada). Si la nube implementara la transferencia recursiva de trabajos, el problema estaría resuelto.