Discusión sobre el artículo "Órdenes, Posiciones y Transacciones en MetaTrader 5"
Después de leer, no he encontrado la mejor respuesta a esta pregunta.
Cómo cargar en la caché, por ejemplo, sólo 1 última orden del histórico (para complicar la tarea, que sea la última por símbolo).
Por ejemplo, el asesor tiene diferente frecuencia de órdenes. Puede hacer 30 órdenes al día y puede estar "en silencio" durante varios días o semanas.
Hay variantes después de enviar una orden al servidor para recordar su ticket en alguna parte y luego recuperar esta orden por ticket - no hay problema. Es posible memorizar tanto en variables globales como dentro de la lógica del EA. Pero aquí está el problema si, por ejemplo, el Asesor Experto se conecta a la cuenta desde otro terminal y no tiene ticket de la última orden.
Tengo que cargar el histórico mediante HistorySelect. La fecha final está más o menos clara, pero cómo calcular la fecha inicial.
Porque incluso en un rango pequeño puede obtener varios pedidos - no es un problema, pero no es óptimo en términos de carga de datos innecesarios. O no uno de ellos puede no caer en el rango.
Usted puede tomar aún más pequeño rango de fechas y el bucle (cambiar el rango en la historia) para llenar la memoria caché - no es óptimo en términos de lógica de trabajo - bucles adicionales, las consultas a la base de datos de la historia.
Propuesta - organizar la carga de la cantidad necesaria por órdenes/operaciones por instrumento.
Y más: si el objetivo del artículo era mostrar los algoritmos óptimos de acceso a las órdenes/operaciones/posiciones. Creo que: si vamos más allá en términos de optimización, sería bueno tener un modo de carga de datos de la historia en la memoria caché por campos por ejemplo, sólo los billetes y la hora de envío de la orden al servidor son necesarios, ¿por qué entonces cargar todos los demás datos de este rango a estas órdenes (magick, comentario y mucho más).
select * from HistiryOrder where a_fecha_envio>@fecha_inicio and a_fecha_envio<@fecha_fin
Los que desarrollan aplicaciones SGBD, creo que una consulta de este tipo no sería aprobada para su uso en producción. Es cierto que hay situaciones en las que todos los datos intervienen posteriormente en algunas acciones, pero se trata de una excepción y no de una regla.
Después de leer, no he encontrado la mejor respuesta a esta pregunta.
Cómo cargar en la caché, por ejemplo, sólo 1 última orden del histórico (para complicar la tarea, que sea la última por símbolo).
Por ejemplo, el asesor tiene diferente frecuencia de órdenes. Puede hacer 30 órdenes al día y puede estar "en silencio" durante varios días o semanas.
Hay variantes después de enviar una orden al servidor para recordar su ticket en alguna parte y luego recuperar esta orden por ticket - no hay problema. Es posible memorizar tanto en variables globales como dentro de la lógica del EA. Pero aquí está el problema si, por ejemplo, el Asesor Experto se conecta a la cuenta desde otro terminal y no tiene ticket de la última orden.
Tengo que cargar el histórico mediante HistorySelect. La fecha final está más o menos clara, pero cómo calcular la fecha inicial.
Porque incluso en un rango pequeño puede obtener varios pedidos - no es un problema, pero no es óptimo en términos de carga de datos innecesarios. O no uno de ellos puede no caer en el rango.
Usted puede tomar aún más pequeño rango de fechas y el bucle (cambiar el rango en la historia) para llenar la memoria caché - no es óptimo en términos de lógica de trabajo - bucles adicionales, las consultas a la base de datos de la historia.
Propuesta - organizar la carga de la cantidad necesaria por órdenes/operaciones por instrumento.
Y más: si el objetivo del artículo era mostrar los algoritmos óptimos de acceso a las órdenes/operaciones/posiciones. Creo que: si vamos más allá en términos de optimización, sería bueno tener un modo de carga de datos de la historia en la memoria caché por campos por ejemplo, sólo los billetes y la hora de envío de la orden al servidor son necesarios, ¿por qué entonces cargar todos los demás datos de este rango a estas órdenes (magick, comentario y mucho más).
select * from HistiryOrder where a_fecha_envio>@fecha_inicio and a_fecha_envio<@fecha_fin
Los que desarrollan aplicaciones SGBD, creo que una consulta de este tipo no sería aprobada para su uso en producción. Es cierto que hay situaciones en las que todos los datos intervienen posteriormente en algunas acciones, pero se trata de una excepción y no de una regla.
Cargar y procesar incluso un historial muy grande no llevará mucho tiempo. Otra cosa es que si dicha carga se realiza en cada tick, ya es un problema.
Incluso un historial muy grande se procesará en unos segundos. De ahí que la primera conclusión sea reducir el número de cargas completas.
Iniciar la carga completa del histórico en OnInit(). Recuerde las fechas necesarias. Luego puede girar la historia "como un gitano con el sol" en OnTicket().
Cargar y procesar incluso un historial muy grande no llevará mucho tiempo. Otra cosa es que si esa carga se realiza en cada tick, ya es un problema.
Incluso un historial muy grande se procesará en unos segundos. De ahí que la primera conclusión sea reducir el número de cargas completas.
Iniciar la carga completa del histórico en OnInit(). Recuerde las fechas necesarias. Después de eso puede girar la historia "como un gitano con el sol" en OnTicket().
Para ser más específicos, el historial debería cargarse completamente sólo en el bloque de inicialización y los fines de semana (los fines de semana también deberías optimizar los parámetros).
Una cosa que me confundió fue que el texto contiene un montón de advertencias sobre la necesidad de cargar el historial en la caché con moderación (reflexivamente), pero no hay ningún ejemplo real de cómo llevar a cabo esta tarea. Esto francamente me molestó:
//--- fijar el límite inicial en 3 días atrás datetime start=end-3*PeriodSeconds(PERIOD_D1);
¿Realmente se utilizará este código (enfoque) en cualquier Asesor Experto normal? A menos que estemos hablando de una tarea específica simple (por ejemplo, encontrar órdenes para varios días), y entonces - con reservas (en este ejemplo, los fines de semana no se tienen en cuenta, por lo que el código no es adecuado para el procesamiento de varios días de negociación ), el enfoque no resiste ninguna crítica.
Aunque, hay todas las herramientas para implementar la carga económica. Y, en lo que a mí respecta, un ejemplo de tal implementación debe estar en el artículo.
Por ejemplo, utilizando esta plantilla:
- OnInit() - cargar todo el historial en la caché, buscando la última orden significativa para el Asesor Experto (por ejemplo, por meijik o sólo por instrumento), guardando su tiempo en una variable.
- OnTrade() - actualizar el historial cargado en la caché (a partir de la hora memorizada), actualizar la hora de la última orden (si ha aparecido una nueva orden significativa).
- OnTick() - trabajar con la caché cargada actualmente o, si es necesario, cargar la caché desde la hora memorizada.
Este enfoque ya reclama estabilidad y universalidad. Además - en términos de utilización de recursos, puede resultar aún más económico que "seleccionar los últimos 3 días".
En cualquier caso, gracias de nuevo por el artículo. Estas "especificaciones de los desarrolladores" son necesarias, de lo contrario no habrá código normal.
El artículo da un ejemplo de carga del historial de operaciones de un día (un código tiene un ejemplo de carga del historial de 3 días). Sí, se trata de una limitación y el ejemplo no es universal. Pero si el lector entiende esta peculiaridad mientras lee el artículo, podrá decidir por sí mismo la cuestión: para qué intervalo y desde qué momento necesita cargar el historial de operaciones en la caché.
El lector ha recibido los ejemplos y algoritmos más simples y ahora puede aplicarlos independientemente en las funciones necesarias de procesamiento de eventos. Puede crear de forma independiente su propia base de historial de operaciones y realizar su inicialización y sincronización, etc.
Un intento de dar recetas y funciones específicas para el trabajo óptimo con el historial de operaciones para todos los casos requerirá al menos un artículo más. Más concretamente, no los ejemplos en sí, sino enfoques para resolver determinadas tareas. El objetivo de este artículo era comprender cómo funcionan las funciones de trading y a qué matices hay que prestar atención para no perder su propio tiempo en la investigación.
Estoy seguro de que después de leer este artículo, todo será sencillo.
¿Me podéis decir si hay alguna descripción del funcionamiento del terminal en modo OfLine en algún sitio? El caso es que no he podido cargar el terminal por falta de actualización de los datos de los gráficos. Quería probarlo en el trabajo (allí no hay internet), pero no he podido: los gráficos están esperando a actualizarse, y no hay ni un solo símbolo en el probador. El artículo dice que después de iniciar el terminal, se realiza la sincronización de datos con el servidor. Pero qué pasa si no hay conexión (en realidad no se supone). Tal vez tenga sentido decirle explícitamente al terminal que se supone que funciona en OfLine y no hacer girar esta desafortunada rueda. Quizás haya menos fallos en el trabajo del probador. Para ser justos, hay que decir que hace tiempo que no tengo este problema, pero la gente se queja de ello en el foro. Tal vez hay algunos trucos (bueno, hay algún archivo para eliminar) para resolver la situación (lo intenté - nada ayudó hasta que establecí conexión con el servidor en casa).
- www.mql5.com
Tras transferir el catálogo de terminales a un nuevo equipo, una parte de las bases de datos de configuración (símbolos, ajustes de cuenta, historial de transacciones, etc.) se elimina especialmente porque está cifrada mediante claves cableadas. El historial de gráficos no se ve afectado.
Esto significa que después de la migración es necesario conectarse a cualquier cuenta de operaciones al menos una vez para dejar que el terminal ajuste el entorno de mercado. Después puede borrar la contraseña, desconectarse de Internet y trabajar con el probador sin conexión.
Tras transferir el catálogo de terminales a un nuevo equipo, una parte de las bases de datos de configuración (símbolos, ajustes de cuenta, historial de transacciones, etc.) se elimina especialmente porque está cifrada mediante claves cableadas. El historial de gráficos no se ve afectado.
Esto significa que después de la migración es necesario conectarse a cualquier cuenta de operaciones al menos una vez para dejar que el terminal ajuste el entorno de mercado. Después puede borrar la contraseña, desconectarse de Internet y trabajar con el probador sin conexión.
Yo no he movido ni cambiado nada. Sólo vine a trabajar con mi portátil y quise probar el Asesor Experto. Tengo una cuenta y, naturalmente, traté de iniciar sesión, pero el registro dice que no hay conexión con el servidor. Tal vez fue sólo un fallo aleatorio, pero no pude hacer nada.
No he movido ni cambiado nada. Sólo vine a trabajar con mi portátil y quería probar el EA. Tengo una cuenta y, naturalmente, traté de iniciar sesión, pero el registro dice que no hay conexión con el servidor. Tal vez sólo un fallo aleatorio, pero no pude hacer nada.
Por favor, proporcione una captura de pantalla completa de toda la ventana del terminal, incluyendo todas las zonas de Market Watch, gráficos y tester.
Intente conectarse a la cuenta en casa, bombee los datos completamente y ejecute al menos una prueba. A continuación, desconéctese de Internet, reinicie el terminal y vuelva a intentarlo.
Por favor, proporcione una captura de pantalla completa de toda la ventana del terminal, incluyendo todas las zonas de Market Watch, gráficos y comprobadores.
Intente conectarse a la cuenta en casa, descargue completamente los datos y realice al menos una prueba. Después desconéctese de Internet, reinicie el terminal y vuelva a intentarlo.
Esto no requiere nada ya que todo funciona como antes. Al parecer ha sido un fallo accidental. Antes el terminal pedía autorización, ahora arranca sin ella. Comprobado unas 10 veces con y sin reiniciar el ordenador. Todo va bien, gracias.
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Usted acepta la política del sitio web y las condiciones de uso
Artículo publicado Órdenes, Posiciones y Transacciones en MetaTrader 5:
No se puede crear un robot de trading robusto sin un entendimiento de los mecanismos del sistema de trading del del MetaTrader 5. El terminal de cliente recibe la información sobre las posiciones, órdenes y transacciones del servidor de trading. Para gestionar esta propiedad de datos usando el MQL5 es necesario tener un buen entendimiento de la interacción entre el programa MQL5 y el terminal de cliente.
Autor: MetaQuotes Software Corp.