FORTALEZAS Por favor, ayuda - página 9

Nuevo comentario
 
komposter:

¿Cuál es la diferencia entre "no" y "no listo" para el programa (y el programador)?

Si los datos no están listos, habrá un error.

O tal vez esta información tampoco está disponible al instante, y por eso no se muestra.

Y para evitar "entrar" en el servidor.

Además, usted es nuestro "lector"... Pregunta:

Por qué construyen las series de tiempo si los datos están listos ( CopyTime(símbolo,periodo,primera_fecha+PeriodoSegundos(periodo),1,tiempos) )?

Если мы успешно прошли все проверки, то сделаем последнюю попытку обойтись без обращения к торговому серверу. Сначала узнаем начальную дату, для которой доступны минутные данные в формате HCC.
Запросим это значение функцией SeriesInfoInteger() с модификатором SERIES_TERMINAL_FIRSTDATE и опять сравним со значением параметра start_date.

   if(SeriesInfoInteger(symbol,PERIOD_M1,SERIES_TERMINAL_FIRSTDATE,first_date))
     {
      //--- there is loaded data to build timeseries
      if(first_date>0)
        {
         //--- force timeseries build                                            
         CopyTime(symbol,period,first_date+PeriodSeconds(period),1,times);
         //--- check date
         if(SeriesInfoInteger(symbol,period,SERIES_FIRSTDATE,first_date))
            if(first_date>0 && first_date<=start_date) return(2);
        }
     }
 
MigVRN:
Así es: carga y prepara lo que hay. Pero debido al hecho de que cualquier retraso en el indicador ralentiza la charla con todo lo que cuelga de ella - lo hicimos así en los indicadores si la serie no está listo en el momento de la llamada - la función devolverá un error e INICIALIZAR la preparación de datos. Después de un tiempo ya no devolverá un error. Esto es lo que ocurre en sus registros.

¡MigVRN!

Chukcha ha releído la ayuda y tiene que NO estar de acuerdo contigo.

"Así es:carga y prepara lo que hay".

Esta es su especulación....

Pero la referencia dice que la función SeriesInfoInteger con el identificadorSERIES_TERMINAL_FIRSTDATE

Debería volver:

SERIE_TERMINAL_PRIMERAFECHA

Primera fecha en el historial por símbolo en el terminal del cliente, independientemente del periodo

¡No debe preparar nada!

Hay datos en el historial de la terminal - obtenga la fecha.

No - devuelve "0".

 
Un nuevo día y vuelta a empezar.
 
barabashkakvn:
Un nuevo día y vuelta a empezar.
Mostrar en la referencia, algo OTRO
 
papaklass:
Prepara los datos y trabaja con ellos. Puedes decir 150 veces que algo va mal y obtener 150 respuestas sobre lo que hay que hacer. Es tu trabajo, así que cuídate.

Gracias, pero sabes muy bien que TODO tiene que ser probado.

SD piensa que devolver 0, cuando los datos están presentes, no es un error de su función.

Si es así, ¡debe estar escrito en la documentación!

 

Mikalas:

Debería, no debería - es todo lo que hablamos. Bueno, puedes ver por ti mismo cómo funciona :)

Lo único en lo que puedo estar de acuerdo es en que no queda muy claro qué datos están listos A LA VEZ (disponibles en cualquier momento) y qué datos prepara el terminal cuando se accede a ellos.

Yo(!) entiendo que cuando se accede a cualquier dato de las series temporales (tiempo y precio, número de barras, enumeraciónENUM_SERIES_INFO_INTEGER, o tal vez se me olvida algo más), los datos no están listos de inmediato.

Para evitar estas situaciones, está escrito en la ayuda:

Dado que el programa mql5 puede acceder a los datos por cualquier símbolo y marco temporal, existe la posibilidad de que los datos de un marco temporal requerido no se hayan generado aún en el terminal, o que los datos de precios requeridos no estén sincronizados con el servidor de operaciones. En este caso, el tiempo de espera de la disponibilidad de datos es difícil de predecir.

Los algoritmos que utilizan ciclos de espera para la disponibilidad de datos no son la mejor solución. La única excepción en este caso - los scripts, porque no tienen otra opción de algoritmo, debido a la falta de procesamiento de eventos. Para los indicadores personalizados, tales algoritmos, así como cualquier otro bucle de espera, no se recomiendan en absoluto, ya que conducen a la detención del cálculo de todos los indicadores y otros procesamientos de datos de precios para este símbolo.

Para los Asesores Expertos y los indicadores personalizados es mejor utilizarel modelo de procesamientobasado en eventos. Si el procesamiento de los eventos OnTick() o OnCalculate() no ha conseguido obtener todos los datos necesarios de la serie temporal requerida, debe dejar el manejador de eventos, esperando tener acceso a los datos durante la siguiente llamada del manejador.

 
MigVRN:

Debería, no debería - es todo lo que hablamos. Bueno, puedes ver por ti mismo cómo funciona :)

Lo único en lo que puedo estar de acuerdo es en que no queda muy claro qué datos están listos A LA VEZ (disponibles en cualquier momento) y qué datos prepara el terminal cuando accedes a él.

Yo(!) entiendo que cuando se accede a cualquier dato de las series temporales (tiempo y precio, número de barras, enumeraciónENUM_SERIES_INFO_INTEGER, o tal vez se me olvida algo más), los datos no están listos de inmediato.

Para evitar estas situaciones, está escrito en la ayuda:

Dado que el programa mql5 puede acceder a los datos por cualquier símbolo y marco temporal, existe la posibilidad de que los datos de un marco temporal requerido no se hayan generado aún en el terminal, o que los datos de precios requeridos no estén sincronizados con el servidor de operaciones. En este caso, el tiempo de espera de la disponibilidad de datos es difícil de predecir.

Los algoritmos que utilizan ciclos de espera para la disponibilidad de datos no son la mejor solución. La única excepción en este caso - los scripts, porque no tienen otra opción de algoritmo, debido a la falta de procesamiento de eventos. Para los indicadores personalizados, tales algoritmos, así como cualquier otro bucle de espera, no se recomiendan en absoluto, ya que conducen a la detención del cálculo de todos los indicadores y otros procesamientos de datos de precios para este símbolo.

Para los Asesores Expertos y los indicadores personalizados es mejor utilizarel modelo de procesamientobasado en eventos. Si durante el procesamiento de los eventos OnTick() o OnCalculate() no se ha conseguido obtener todos los datos necesarios de las series temporales requeridas, se debe salir del manejador de eventos, esperando tener acceso a los datos durante la siguiente llamada del manejador.

¡Andrew!

No sé ustedes, pero yo llevo muchos años trabajando con documentación.

Mira, de la documentación se desprende, como yo(!) entendí.

1. Comprobemos si existen datos históricos del símbolo en el terminal (SeriesInfoInteger con el identificadorSERIES_TERMINAL_FIRSTDATE)

Tal vez, no lo discuto, tanto construye como inicializa algo.

2. No hay datos (devuelve una fecha de inicio del historial vacía) - va al servidor para obtener datos.

Si hay una fecha, construimos el marco temporal especificado utilizando la funciónCopyTime(símbolo,periodo,primera_fecha+PeriodoSegundos(periodo),1,tiempos);

4. Comprobamos el inicio de la serie temporal con la fecha dada(SeriesInfoInteger(símbolo,periodo,SERIES_FIRSTDATE,first_date).

Está escrito en la documentación.

Pero cuando yo(!) pido los datos del historial por símbolo(no por series de tiempo!!!!) en el terminal, que están EXACTAMENTE ahí

devuelve "0".

¿Crees que esto es correcto?

 
Mikalas:

PERO, cuando yo(!) pido los datos del historial por símbolo(no por serie temporal!!!!) en el terminal, que está EXACTAMENTE ahí

la función devuelve "0".

¿Crees que esto es correcto?

Los datos (no preparados) están en el disco. Los datos (preparados) pueden estar en el chat adyacente. Pero no hay datos preparados en el chat que está ejecutando la indirección. Por lo tanto, hay un error. Es correcto. Pero no es conveniente :)

Aunque a mí tampoco me gustan estas preguntas, ¿es crítico para ti pedir los datos del indicador de los caracteres adyacentes? (teniendo en cuenta lo que está escrito en la ayuda y mi ejemplo - cómo un indicador puede ralentizar la ejecución del Asesor Experto y el chat). Puedes evitar todas estas dificultades...

 
papaklass:

Está pidiendo "FIRSDDATE", no datos. Es probable que la fecha esté ahí, pero los datos pueden faltar debido a la economía. Por qué bombear datos para todos los personajes si no se utilizan en este momento. Los desarrolladores han tomado el camino racional de bombear los datos sólo cuando el usuario accede a ellos. Este es el enfoque normal. Usted, que trabaja con el terminal, debe SABER esto y actuar en consecuencia.

En lugar de perder el tiempo en el comercio, te quedas en cosas elementales y pierdes el tiempo. Ahorra tiempo. :)

Los robots están operando por mí, no estoy en casa en este momento...

Y necesito indicador sólo para mejorar mi comercio :)

 
Mikalas:

¡Andrei!

No sé ustedes, pero yo llevo muchos años trabajando con documentación.

Mira, de la documentación se desprende, como yo(!) entiendo.

1. Veamos si hay datos históricos sobre el símbolo en el terminal (SeriesInfoInteger con el identificadorSERIES_TERMINAL_FIRSTDATE)

Tal vez, no lo discuto, tanto construye como inicializa algo.

2. No hay datos (devuelve una fecha de inicio del historial vacía) - va al servidor para obtener datos.

Si hay una fecha, construimos el marco temporal especificado utilizando la funciónCopyTime(símbolo,periodo,primera_fecha+PeriodoSegundos(periodo),1,tiempos);

4. Comprobamos el inicio de la serie temporal con la fecha dada(SeriesInfoInteger(símbolo,periodo,SERIES_FIRSTDATE,first_date).

Está escrito en la documentación.

Pero cuando yo(!) pido los datos del historial por símbolo(no por series de tiempo!!!!) en el terminal, que están EXACTAMENTE ahí

devuelve "0".

¿Crees que esto es correcto?

Lea la documentación con más atención, no de forma selectiva. La presencia de datos del historial en el disco no significa que "esté definitivamente ahí" para el terminal. En este caso (cuando se accede desde el indicador), las funciones sólo funcionan con la caché de series temporales en memoria. Significa que se realiza un acceso sincrónico a la memoria y si no hay ninguna serie de tiempo preparada allí, no se devolverá la fecha SERIES_FIRSTDATE (del primer elemento del array). Pero, por supuesto, la solicitud inicia la preparación-carga de las series temporales en la memoria.

La solicitud SERIES_TERMINAL_FIRSTDATE está conectada con la inicialización de la base de datos y la sincronización con el servidor, por lo que la primera llamada no funcionará inmediatamente de todos modos.

En principio, la capacidad de obtener el historial requerido se comprueba mediante SERIES_SERVER_FIRSTDATE . Es decir, por supuesto que se puede contar con X iteraciones de solicitud de historial, pero si el terminal confirma la presencia de historial a través de SERIES_SERVER_FIRSTDATE, entonces la disponibilidad de los datos de las series temporales relevantes es sólo cuestión de tiempo (sincronización de la base de datos m1 con el servidor y generación de las series temporales).

12345678910111213141516...31
Nuevo comentario