Librerías: Calendario - página 2
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
En todos los calendarios HTML (incluido el estándar y en Terminal) la triple (Actual, Previsión, Anterior) = (Actual, Previsión, Revisado). Por lo tanto, no puede utilizar el campo Revisado en el historial hasta que se produzca el siguiente evento correspondiente. Los demás sí pueden utilizarse.
No he trabajado con la API de calendario local - su documentación deja mucho que desear (por lo que se necesitaría una biblioteca más lógica). ¿No es posible consultar una matriz de cambios de eventos a partir del change_id especificado? Por alguna razón no está basado en el tiempo. Desafortunadamente, estas preguntas son más para el calendario en sí y no para la librería, pero como la librería está encima del calendario, quedan abiertas también para él. El problema con los cambios es que en mi práctica pasada de usar calendarios externos me di cuenta de que algunos campos se pueden ajustar retroactivamente, por así decirlo, y por eso necesitamos hacer pruebas teniendo en cuenta la cronología de los cambios.
No entiendo cómo previous=revised(la estructura MqlCalendarValue tiene los 4 campos: actual, prev, revised, forecast) y por qué no se puede usar revised en el historial - en mi opinión, revised puede aparecer (si previous es revised) en cualquier momento entre la publicación del último evento y el siguiente, es decir, sólo en el historial.
No he trabajado con la API del calendario local - su documentación deja mucho que desear (de ahí que se necesitaría una biblioteca más lógica). ¿No es posible consultar una matriz de cambios de eventos a partir del change_id especificado? Por alguna razón, no es temporal.
Cada cambio en el calendario tiene su propio change_id. Así que puede consultar todos los cambios desde un change_id específico hasta el change_id actual.
No entiendo cómo previous=revised(la estructura MqlCalendarValue tiene los 4 campos: actual, prev, revised, forecast) y por qué no puedes usar revised en el historial - en mi opinión, revised puede aparecer (si previous es revised) en cualquier momento entre la publicación del último evento y el siguiente, es decir, sólo en el historial.
En los calendarios sólo se pueden ver tres campos para un evento. En la API hay cuatro. Revisado es el valor de refinamiento más reciente, que puede llegar incluso una semana después de que se reciba el Actual. Esta es la razón de la prohibición, un tanto lógica, de utilizar Revised en backtests.
Veo bastante estrechos escenarios de uso conveniente del calendario. Si usted tiene sus propias opciones - expresarlas. Tal vez la biblioteca tiene una API que no es óptima para sus escenarios. Entonces pensaremos en ello.
El tema parece ser bastante nuevo.
Las funciones GMT están ahí, pero no parece que se utilicen. No sé si son necesarias.
Se dejan para el futuro. Ya que el calendario está ligado a la hora del servidor, y se puede tomar desde fuera.
Veo con bastante estrechez de miras los escenarios de uso conveniente del calendario. Si usted tiene sus propias variantes - expresarlas. Tal vez la biblioteca tiene una API que no es óptima para sus escenarios. Entonces pensaremos en ello.
El tema parece ser bastante nuevo.
A juzgar por la descripción de las características del calendario MT, deberíamos escribir algo como Observador con el seguimiento de todos los cambios, y la llegada de nuevos eventos por suscripción, y los cambios en Actual, Revisado.
Entonces creo que podría ser conveniente.
A juzgar por la descripción de las características del calendario MT, deberíamos escribir algo como Observador con monitorización de todos los cambios, y la llegada de nuevos eventos a la suscripción, y cambios en los valores de Actual, Revisado.
Terminológicamente no lo entiendo.
Terminológicamente, no lo entiendo.
https://refactoring.guru/ru/design-patterns/observer
https://refactoring.guru/ru/design-patterns/observer
Gracias. Si estamos hablando de OnCalendar, algún tipo de simulación a través de change_id mecanismo será.
Es mejor demostrar los escenarios de aplicación con código esquemático, por supuesto.
Gracias. Si estamos hablando de OnCalendar, habrá alguna simulación a través de change_id-mechanism.
Estás hablando de simulación de eventos de calendario, que puede ser introducido en MT5 en el futuro.
Yo me refería al mecanismo de suscripción a los eventos de interés, incluyendo el cambio de Revisado, ya que puede cambiar en cualquier momento.
Si no estás familiarizado con el patrón Observador, te recomiendo que estudies el enlace de Andrei.
La esencia de la idea es brevemente que, por ejemplo:
Necesito conocer todos los eventos EUR con importancia superior a 3 para operar. Solicito a un proveedor (un objeto de la clase que gestiona las suscripciones y alertas, también llamado editor, puede ser uno solo), suscribirme.
Y entonces el propio proveedor monitoriza todos los cambios en los eventos que me interesan y me avisa (llamando al método de tratamiento de eventos con la información correspondiente).
La esencia de la idea es brevemente que, por ejemplo:
Necesito conocer todos los eventos EUR de importancia superior a 3 para operar. Me pongo en contacto con un proveedor (objeto de la clase que gestiona las suscripciones y alertas, también llamado editor, puede ser único), suscribir.
Y entonces el propio proveedor monitoriza todos los cambios en los eventos que me interesan y me avisa (llamando al método de tratamiento de eventos con la información correspondiente).
Ningún objeto personalizado puede controlarse a sí mismo sin la correspondiente llamada. Es decir, debe ser escrito por el usuario en su código. Si él lo ha escrito, entonces él mismo hace el procesamiento.
El mecanismo change_id es muy sencillo: se ejecuta el método Refresh. Después de eso obtienes los datos, qué y dónde se actualizó en la lista de eventos que has creado.