Servicedesk: ¿pereza, autismo o falta de voluntad para admitir errores? Complementar los gráficos con velas no nativas.

 

Me puse en contacto con el Servicio de Atención al Cliente por un problema con la fijación de velas superiores a gráficos de TF bajos cuando no hay historial en TFs inferiores. Significa que cuando vamos al principio de la historia en el gráfico M1, vemos velas no desde M1, sino desde D1, o incluso desde W1. Debido a esta adhesión, la función SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x) no devuelve la fecha en la que termina el historial M1, sino la fecha de la primera barra fuera del marco temporal, es decir, el marco temporal especificado no afecta al resultado. Al preguntar, recibí la excusa de que es conveniente para los usuarios y que la fecha de corte de cada plazo de cada símbolo debe establecerse manualmente. Perdona, pero ¿no debería realizar esta función la función SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x), yen qué se diferenciaSERIES_FIRSTDATE deSERIES_FIRSTDATEen el TF M1 especificadosi el resultado es el mismo?

¿Qué es esta tontería? ¿A quién y por qué le conviene? Nadie quiere ver velas W1 en gráficos M1. Bueno, excepto para los masoquistas ...

Llego a la siguiente conclusión: o los desarrolladores son autistas (viven en su mundo, donde lo de arriba y lo de abajo es la norma, o más bien no es la norma, pero el trabajo es 5+), o son demasiado perezosos para arreglarlo, o el principio de "Cómo es que nunca nos equivocamos, todos somos buenos". También hay variantes: bromean, no saben cómo arreglarlo.

Aquí están las capturas de pantalla, se puede ver claramente la línea de unión de la historia de los diferentes TFs:

https://charts.mql5.com/1/26/eurusd-d1-metaquotes-software-corp-7.png

https://charts.mql5.com/1/26/eurusd-h4-metaquotes-software-corp.png

https://charts.mql5.com/1/26/eurusd-h1-metaquotes-software-corp-9.png

https://charts.mql5.com/1/26/eurusd-m30-metaquotes-software-corp-2.png

https://charts.mql5.com/1/26/eurusd-m15-metaquotes-software-corp-6.png

consulta 1:

Versión y tasa de bits del terminal

Compilación 712 x86

Descripción del problema.

Los datos históricos de los marcos temporales pequeños son continuados por los datos históricos de los marcos temporales más grandes. Significa, por ejemplo, que la historia del EURUSD en M1 termina el ~04.01.1999, y a la izquierda de éste se adjunta el gráfico D1 para el período anterior al 04.01.1999.

Puedes verlo en las capturas de pantalla adjuntas. Debido a esto, la función SeriesInfoInteger con el parámetro SERIES_FIRSTDATE funciona incorrectamente. La función devuelve la primera fecha de todo el historial (incluyendo los marcos temporales D1, W1 y MN1) en lugar de la primera fecha del período-símbolo.

La secuencia de acciones

Desplazamiento por el gráfico hasta el principio de la historia

El resultado obtenido

Continuación del gráfico con datos históricos de plazos más amplios.

Resultado esperado

Restricción del gráfico al final de los datos históricos en el marco temporal dado.

Información adicional

Solicitud 2:

Versión del terminal y tasa de bits

construir 712 x86

Descripción del problema

Descripción en la documentación:

SERIES_BARS_COUNT.

Número de barras por símbolo-período en este momento

largo

SERIE_PRIMERAFECHA

La primera fecha del período de símbolos actual

datetime

Debido a la adhesión de la historia para el TF inferior, en el caso de la ausencia de historia para un período de tiempo específico en el TF inferior, y la presencia de la historia para el mismo período en el TF mayor, el gráfico, por ejemplo, M1 muestra velas del gráfico de D1.

¿Se está preparando una solución a este problema? ¿Hay alguna solución a este problema por el momento, aparte de la restricción manual?

Secuencia de acciones

Utilizando estas funciones

El resultado obtenido

SERIES_BARS_COUNT en marcos temporales bajos (hasta D1) devuelve el número de velas (barras), pertenecientes al símbolo y al marco temporal, más el número de velas del marco temporal más grande más cercano, para el cual los datos históricos están disponibles

SERIES_FIRSTDATE en plazos bajos (hasta D1) devuelve la fecha de apertura de la primera vela (barra) del historial.

El resultado esperado

SERIES_BARS_COUNT devuelve el número de velas (barras), pertenecientes a un símbolo y un marco temporal determinados

SERIES_FIRSTDATE devuelve la fecha de la primera vela (barra) abierta, que pertenece a un símbolo y un marco temporal especificados.

Más información

...

Equipo de apoyo2012.11.20 14:38
Estado:AbiertoCerrado

Las funciones funcionan correctamente.

Lo que ve es una consecuencia de su solicitud de calidad de historial anterior.

La historia es la que es. No tenemos una historia minuciosa. Para su comodidad, el historial más profundo está representado por barras diarias.

Si no le conviene, limite el uso de este historial manualmente.

 
FiftyStars: Contacté con servicedesk...

¿Es esta la pregunta que planteó hace un mes? https://www.mql5.com/ru/forum/1111/page878#comment_344461

Cincuenta estrellas:

Equipo de apoyo2012.11.20 14:38

...La historia es la que es. No tenemos una historia profunda de minutos. Para su comodidad, el historial más profundo está representado por barras diarias.

Si no le conviene, limite el uso de este historial manualmente.

Lo esencial de la respuesta ya se conocía en ese momento(https://www.mql5.com/ru/forum/1111/page878#comment_344518):

Pero me temo que (la respuesta) será algo así: "El propio programador puede calcular la fecha límite y limitar la profundidad del historial solicitado.

 
FiftyStars:

Me puse en contacto con el Servicio de Atención al Cliente por un problema con la fijación de velas más altas a gráficos de TF bajos cuando no hay historial en los TF más bajos. Es decir, cuando vamos al principio de la historia en el gráfico M1, vemos velas no desde M1, sino desde D1, o incluso desde W1. Debido a esta adhesión, la función SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x) no devuelve la fecha en la que termina el historial M1, sino la fecha de la primera barra fuera del marco temporal, es decir, el marco temporal especificado no afecta al resultado.

...


SERIES_BARS_COUNT devuelve el número de velas (barras), pertenecientes a un determinado símbolo y marco temporal

SERIES_FIRSTDATE devuelve la fecha de la primera vela (barra) abierta, que pertenece a un determinado símbolo y marco temporal.

Más información

...

Equipo de apoyo2012.11.20 14:38
Estado:AbiertoCerrado

Las funciones funcionan correctamente.

Lo que ve es una consecuencia de su solicitud de calidad de historial anterior.

La historia es la que es. No tenemos una historia minuciosa. Para su comodidad, el historial más profundo está representado por barras diarias.

Si no le conviene, limite el uso de este historial manualmente.

Esta es una excusa franca, el programador no puede prever todas las variantes de la historia que muerden, por lo que no puede prescribir la función de búsqueda de la primera fecha de la TF. Hoy son así, y mañana tendrán nuevos giros, y sin que MQ se entere, por ejemplo repartiendo meterá la pata en algo.

Y para qué lo necesitamos si hay una función estándar, pero el hecho de que dé el tiempo de antes de ayer ya es un auténtico bug.

Aquí está el quid del problema para el programador:

Tenemos que buscar variantes de los criterios según los cuales esta barra puede considerarse la primera barra de la TF seleccionada, y todas las anteriores - la adición de la TF más antigua. Puede haber lagunas en los compases como un compás perdido (esto es una consecuencia directa del formato de grabación de compases elegido por MQ) o lagunas en los compases como fin de semana/vacaciones. Y en tal cacofonía de signos no está claro cómo determinar que este bar es el correcto.

Cuál es la esencia del problema para MQ: (si queremos decir que lo van a resolver)

Cuando la historia se cose a un archivo de cifrado de datos en los puntos de costura (no son muchos, un máximo de 21 por el número de TF, en la práctica, hay 2-3), la cuestión se resuelve. A continuación, escriba una función para leer esta información protegida y enviarla al usuario a través de una solicitud.

 
Para su comodidad, el historial más profundo está representado por barras diarias.

Gracias, no decidas por los comerciantes.

¿Qué cabeza fresca fue para hacer tal movimiento después del viernes - para insertar las barras más antiguas en el marco de tiempoM1 ?

¿Quién te ha dado el derecho - de revertir muchos años de principios bien establecidos?



Si no te sientes cómodo con ello, limita el uso de esta historia manualmente.

¿pero cómo?
 
sergeev:



Gracias, no decidas por los comerciantes.

¿Qué cabeza fresca era para hacer tal movimiento después del viernes - para insertar las barras superiores en el marco de tiempoM1 ?

¿Quién te ha dado el derecho de revertir muchos años de principios establecidos?



¿pero cómo?

Alex, no exageres, el pegado del TF era necesario para calcular correctamente todos los demás TFs, después de que decidieran calcular todos los TFs a partir del M1.

Si lo recuerdas, nos permitía calcular hasta 21 TFs (incluyendo las no estándar).

No se ha dicho más de una vez sobre eso. No volveremos al antiguo sistema de almacenar cada TF por separado, ya lo entiendes.

Pero el hecho de que la implementación añade más problemas a los programadores es un hecho. Y la pregunta es sencilla de resolver, pero no, sabemos mejor lo que necesitas :(

 

así que eso es lo que me pregunto.

Если вам это не удобно - ограничивайте использование этой истории вручную.

¿Cómo?
 
Urain:

Alex no exagere, el pegado de la TF era necesario para calcular correctamente todas las demás TFs, después de que se decidiera calcular todas las TFs a partir de la M1.

Se soluciona poniendo el identificador en el historial y al leer si los datos de la barra no pertenecen a M1 entonces no salen a M1, no pertenecen a M5 entonces no salen a M5. O sí....escribir en FirstDate la fecha de fusión de las barras del periodo actual con las barras del periodo superior y el usuario tendrá una oportunidad real de saber a partir de qué fecha empezar a procesar para no coger las barras más antiguas.
 
FiftyStars:
Se soluciona poniendo un identificador en el historial y al leer, si el dato de la barra no pertenece a M1, no saldrá en M1, y si no pertenece a M5, no saldrá en M5. O sí... deberíamos escribir la fecha de unión de las barras del periodo actual con las del periodo superior en FirstDate y el usuario tendrá la posibilidad real de saber a partir de qué fecha empezar a procesar para no pillar barras más antiguas.
Ya lo escribí más arriba, me da pereza volver a pulsar el teclado.
 

La situación es ciertamente imbécil.

No se pueden dibujar esos gráficos ni devolver esos valores desde las funciones.

Si quieres construir desde M1, constrúyelo. No hay suficiente M1: hay que averiguar cómo salir de él, pero no a nuestra costa.

(todo dirigido, por supuesto, a MQ)

Документация по MQL5: Стандартные константы, перечисления и структуры / Константы индикаторов / Стили рисования
Документация по MQL5: Стандартные константы, перечисления и структуры / Константы индикаторов / Стили рисования
  • www.mql5.com
Стандартные константы, перечисления и структуры / Константы индикаторов / Стили рисования - Документация по MQL5
 
Maldita sea.
 

Estoy de acuerdo, es una basura.

Y si hay separadores de puntos, es una belleza.

¡mis ojos!

Y hay que retorcerlo en el código ((.