Errores, fallos, preguntas - página 2180

 
Nikolai Semko:

Claramente, cero.

¿Está bien que se tomen 22 segundos para decidir que hay cero barras en un marco temporal determinado?

Claramente un error algorítmico en la implementación interna de Bares.

Y no entiendo cómo se distingue entre cero barras en un plazo determinado y este cero:

De la documentación: Si los datos de una serie temporal con los parámetros especificados al llamar a la función Bars() no se han generado aún en el terminal, o los datos de la serie temporal no están sincronizados con el servidor de operaciones en el momento de la llamada a la función, ésta devolverá un valor cero.

En otras palabras, ¿cómo puedo distinguir entre un resultado nulo y un error nulo?
 
A100:

Y no entiendo cómo distingues entre barras cero en un marco temporal determinado y este cero:

De la documentación: Si los datos de una serie temporal con los parámetros especificados cuando se llama a la función Bars() aún no se han generado en el terminal, o los datos de la serie temporal no están sincronizados con el servidor de operaciones en el momento en que se llama a la función, entonces la función devolverá un valor cero.

El origen del cero no es importante en esta cuestión, lo importante es que este cero nace por la función Bars para siempre en forma de un par de decenas de segundos.

 
A100:

Lo que no entiendo es cómo se distingue entre barras cero en un marco temporal determinado y este cero:

De la documentación: Si los datos de una serie temporal con los parámetros especificados al llamar a la función Bars() no se han generado todavía en el terminal, o los datos de la serie temporal en el momento de la llamada a la función no están sincronizados con el servidor de operaciones, la función devolverá cero.

En otras palabras, ¿cómo puedo distinguir entre un resultado nulo y un error nulo?

Piensa en ello. Si tuvieras la tarea de crear un análogo de la función Bars y te dieran un array datetime, los valores de cuyos elementos disminuyen con el aumento del número, en otras palabras, el array está ordenado.

¿Crees que sería difícil implementar un algoritmo que busque el número de elementos de una matriz así ordenada en un intervalo de tiempo determinado? Y si no hay una sola barra en el intervalo de tiempo dado o el array no ha sido inicializado todavía, deberíamos devolver cero.

No, el algoritmo es bastante sencillo. ¿Qué puede correr durante 22 segundos?

 
Nikolai Semko:

En esta cuestión, el origen del cero no es importante, lo importante es que este cero nace por la función de Bares durante años, en forma de un par de decenas de segundos.

Precisamente el origen es importante, porque si ::Bars() devolviera -1 en lugar de 0 (como ahora) en caso de error de la historia, no tendríamos ningún retraso. Pero ahora el 0 se interpreta como un error y el retraso se debe a las repeticiones internas https://www.mql5.com/ru/forum/1111/page2200#comment_6955559

Además, supongamos que introducimos una comprobación adicional y el retraso desaparece. Entonces, ¿qué pasó? Tienes cero. ¿Es un resultado o un error?

Ошибки, баги, вопросы
Ошибки, баги, вопросы
  • 2018.03.31
  • www.mql5.com
Общее обсуждение: Ошибки, баги, вопросы
 
Vitaly Muzichenko:

Lo más probable es que esto se deba a la carga de la historia

Lo curioso es que la primera Impresión se procesa sin demora, es decir, el historial por H4 ya está cargado.

Y si cambias CopyTime H4 a W1, no habrá ningún retraso. Significa que el historial de W1 ya está cargado también.

Es que Bars se inhibe por el intervalo de tiempo entre CurrentTime() y el tiempo de apertura de la barra cero.

 
A100:

Es el origen lo que importa, porque si ::Bars() devolviera -1 en lugar de 0 (como hace ahora) en caso de error en el historial, no habría ningún retraso. Pero ahora el 0 se interpreta como un error y se produce un retraso debido a las repeticiones internas https://www.mql5.com/ru/forum/1111/page2200#comment_6955559.

Además, supongamos que se introduce un control adicional y el retraso desaparece. Entonces, ¿qué pasó? Tienes cero. ¿Es un resultado o un error?

No importa en todos mis algoritmos si el resultado de cero es una barra que no golpea en el intervalo dado o la ausencia de matriz como tal.

Estás alejando el problema.

 
Nikolai Semko:

Le quitas importancia al problema.

Estoy exponiendo la esencia del problema, tú te fijas en tu caso particular. A juzgar por tu post anterior, sigues sin entender cuándo se produce un retraso (eso es además de la causa), aunque en la página anterior se explica todo con detalle.

Tal vez esta secuencia de comandos puede ayudar a entender

void OnStart()
{
        Print( "begin" );
        ::Bars( _Symbol, PERIOD_W1, D'2018.03.20', D'2018.03.23' );
        Print( "end" );
}
 
A100:
Yo expongo la esencia del problema, mientras que tú te centras en tu caso particular. A juzgar por tu mensaje anterior, sigues sin entender cuándo se produce un retraso (esto es además de la razón), aunque la página anterior lo explica con detalle.

Ya he formulado mi opinión más arriba sobre cuándo se produce el retraso.

Una vez más:
Bars se cuelga si start_time está en el rango desde la hora de apertura de la barra cero del TF solicitado hasta TimeCurrent(). (Es sólo una hipótesis, pero se comprueba con la práctica)
Sí, el error se produce en un caso especial. Pero los casos privados no deberían estar en las funciones estándar incorporadas al lenguaje de programación.

Y tu "punto" no es el punto, porque simplemente estás citando la referencia del comando Bars, que conozco perfectamente. No hay código de error en la función Bares porque no es necesario.

Más aún cuando en este caso se trata de matrices de series temporales totalmente formadas.

Esto puede verse claramente en el código ligeramente modificado de mi script:

void OnStart()
  {
   datetime Arr[];
   if(CopyTime(_Symbol,PERIOD_W1,0,1,Arr)<0) Print("Ошибка");
   Print("Время открытия нулевого бара W1 = "+TimeToString(Arr[0]));
   ArraySetAsSeries(Arr,true);
   if(CopyTime(_Symbol,PERIOD_H4,0,100,Arr)<0) Print("Ошибка");
   Print("1 "+"CurrentTime = "+TimeToString(TimeCurrent()));
   int Res=Bars(_Symbol,PERIOD_W1,Arr[99],TimeCurrent());  // выполняется быстро   
   Print("2 Время открытия 99 бара H4 = "+TimeToString(Arr[99])+"  Номер бара W1= " +IntegerToString(Res)); 
   Res=Bars(_Symbol,PERIOD_W1,Arr[0],TimeCurrent());       // выполнение происходит более 10 секунд!!!   
   Print("3 Время нулевого бара H4 = "+TimeToString(Arr[0])+"  Номер бара W1= " +IntegerToString(Res));
  }

Resultado:

2018.03.30 23:39:31.079 BagBars (EURUSD,H4)     Время открытия нулевого бара W1 = 2018.03.25 00:00
2018.03.30 23:39:31.079 BagBars (EURUSD,H4)     1 CurrentTime = 2018.03.30 23:54
2018.03.30 23:39:31.079 BagBars (EURUSD,H4)     2 Время открытия 99 бара H4 = 2018.03.08 20:00  Номер бара W1= 3
2018.03.30 23:39:47.176 BagBars (EURUSD,H4)     3 Время нулевого бара H4 = 2018.03.30 20:00  Номер бара W1= 0
 
A100:

Tal vez esta secuencia de comandos ayudará a entender

Su script demuestra este problema - colgando.

porque el rango de tiempo start_time - stop_time está dentro de la barra semanal.

Si se sale de la barra semanal, entonces no hay congelación:

Bars( _Symbol, PERIOD_W1, D'2018.03.12', D'2018.03.23' );

Gracias por el ejemplo más claro

 

En MT4 las funciones CopyHigh, CopyLow (no miré otras) causaron un error crítico cuando no había historia en el probador. El EA fue probado en H1 y la solicitud fue de M1

1 15:14:35.410 2017.01.04 19:54:24  Access violation read to 0x0A971FE8 in 'C:\Users\Halyna\AppData\Roaming\MetaQuotes\Terminal\287469DEA9630EA94D0715D755974F1B\MQL4\Experts\____________.ex4'

3 15:14:35.465 2017.01.04 19:54:24 El pase de prueba se detuvo debido a un error crítico en el EA