Errores, fallos, preguntas - página 2099

[Andrey Khatimlianskii]

Vladimir Pastushak:
Chicos, estoy harto de introducir mi nombre de usuario y contraseña de www.mql5.com en android en mt5.
¿Por qué siguen perdiendo su nombre de usuario y contraseña?

A mí también me lo preguntan regularmente, pero no introduzco mi nombre de usuario/contraseña, simplemente pulso el botón Atrás y resulta que está conectado.

[fxsaber]

Nikolai Semko:

¿Por qué una función tan útil como ChartXYToTimePrice() es tan cara en tiempo de ejecución?

Escribí una función análoga a XYToTimePrice() y se ejecuta mucho más rápido. Hasta varios cientos de veces más rápido.

Pero también hay ChartID_in con SubWindow_out en la función original. Haz un análogo completo.

[Nikolai Semko]

fxsaber:

Así que también hay ChartID_in con SubWindow_out en el original. Haz un análogo completo.

Añadir ChartID_in y SubWindow_out no es nada difícil. Pero no pretendo crear un análogo completo, sólo he creado esta función para mostrar la lentitud de ChartXYToTimePrice().

void XYToTimePrice(long chart_id,int x,int y,int& sub_window,datetime &time,double &price,int id)
  {
   static int left_bar; // номер самого левого бара на экране
   static int WidBar;
   static int Wid;
   static int Hei;
   static double y_min;
   static double y_max;
   static int PerSec=PeriodSeconds();
   static bool ChartChange=true;
   if(id==CHARTEVENT_CHART_CHANGE) { ChartChange=true; return; } 
   if(ChartChange) // если было изменение чатра после последнего вычисления
     {
      left_bar=(int)ChartGetInteger(chart_id,CHART_FIRST_VISIBLE_BAR, sub_window);        // номер самого левого бара на экране
      Wid=(int)ChartGetInteger(chart_id,CHART_WIDTH_IN_PIXELS, sub_window);               // ширина экрана в пикселях
      WidBar=(int)ChartGetInteger(chart_id,CHART_WIDTH_IN_BARS, sub_window);              // ширина экрана в барах
      Hei=(int)ChartGetInteger(chart_id,CHART_HEIGHT_IN_PIXELS, sub_window);              // высота экрана в пикселях
      y_min=ChartGetDouble(chart_id,CHART_PRICE_MIN, sub_window);                         // макс. цена на экране
      y_max=ChartGetDouble(chart_id,CHART_PRICE_MAX, sub_window);                         // мин. цена на экране
     }
   if(x>Wid || x<0 || y<0 || y>Hei) return;  // выходим если точка (x,y) за пределами экрана
   price=y_min+(Hei-y)*(y_max-y_min)/Hei;
   int NrBar=left_bar-(int)((double)x/((double)Wid/(double)WidBar)); 
   datetime T[1];
   if(NrBar>=0) CopyTime(NULL,0,NrBar,1,T);
   else { CopyTime(NULL,0,0,1,T); T[0]+=fabs(NrBar)*PerSec;}
   ChartChange=false;
   time=T[0];
  }

Pero es cierto, mi función necesita un parámetro adicional id de evento. Y hasta ahora, esta función funciona más o menos igual con el grosor original de la vela de un píxel, pero se puede mejorar, si es necesario.

[Nikolai Semko]

Nikolai Semko:

Añadir ChartID_in y SubWindow_out no es nada difícil. Pero no pretendo crear un análogo completo, sólo he creado esta función para mostrar la lentitud de ChartXYToTimePrice().

Pero es cierto, mi función necesita un parámetro adicional id de evento. Y aunque esta función funciona más o menos igual con el grosor original de la vela de un píxel, pero se puede mejorar, si es necesario.

Y también he notado una extraña característica de ChartXYToTimePrice. Su tiempo de ejecución es directamente proporcional al número de barras del gráfico.

Esto indica un algoritmo "extraño" para su cálculo. En concreto, se trata de una suma cíclica que resulta bastante extraña para la solución óptima de un problema de este tipo.

La velocidad de la función XYToTimePrice es la misma independientemente del número de barras.

Y para ser sinceros, la velocidad de las funciones ChartGetInteger y ChartGetDouble también está claramente sobrevalorada y tiene características muy extrañas. Por ejemplo, la función

ChartGetDouble(0,CHART_PRICE_MAX);

es 20-100 veces más rápida que la función

ChartGetDouble(0,CHART_PRICE_MIN);          

si MAX está después de MIN:

pero si los intercambias, la situación se invierte.

Es decir, parece lógico: la misma función, que se calcula repetidamente, utiliza datos ya calculados y almacenados de una llamada de función anterior. Pero sólo muestra algunos cálculos locos y la creación de un montón de datos intermedios y tal vez incluso matrices para calcular un simple valor doble del precio máximo (o mínimo) del gráfico, que probablemente ya se encuentra en alguna variable y sólo necesita ser tomado.

Aunque no excluyo que este efecto se produzca debido a algunas peculiaridades de los perfiles y sea de naturaleza falsa. Pero la lentitud de estas funciones no es falsa.

[fxsaber]

Nikolai Semko:

puede refinarse, si es necesario.

Probablemente siga siendo válido decir que es correcto comparar las características de velocidad de las dos funciones cuando sus resultados coinciden. Por favor, complételo.

[Alexander]

Vladimir Pastushak:
Chicos, estoy cansado de introducir mi nombre de usuario y contraseña de www.mql5.com en android en mt5.
¿Por qué siguen perdiendo su nombre de usuario y contraseña?

Escribe a servicedesk. Por favor, adjunte los registros. Lo siento. Gracias.

[Anatoli Kazharski]

Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading

Bichos, errores, preguntas

fxsaber, 2017.10.04 09:13

Se ha escrito sobre esto muchas veces. No se ha corregido por alguna razón.

Parece que ya lo han arreglado. Ya no tengo este problema en la build 1730.

[Slava]

Nikolai Semko:

También he notado una extraña característica de ChartXYToTimePrice. Su tiempo de ejecución es directamente proporcional al número de barras del gráfico.

Esto demuestra la "rareza" de su algoritmo de cálculo. En concreto, se trata de una suma cíclica que resulta bastante extraña para la solución óptima de un problema de este tipo.

La velocidad de la función XYToTimePrice es la misma independientemente del número de barras.

Y para ser sinceros, la velocidad de las funciones ChartGetInteger y ChartGetDouble también está claramente sobrevalorada y tiene características muy extrañas. Por ejemplo, la función

es 20-100 veces más rápida que la función

si MAX está después de MIN:

pero si los intercambias, la situación se invierte.

Es decir, parece lógico: la misma función, que se calcula repetidamente, utiliza datos ya calculados y almacenados de una llamada de función anterior. Pero sólo muestra algunos cálculos locos y la creación de un montón de datos intermedios y tal vez incluso matrices para calcular un simple valor doble del precio máximo (o mínimo) del gráfico, que probablemente ya se encuentra en alguna variable y sólo necesita ser tomado.

Aunque no excluyo que este efecto se produzca debido a algunas peculiaridades de los perfiles y sea de naturaleza falsa. Pero la lentitud de estas funciones no es falsa.

La lentitud de las funciones de solicitud de datos de los gráficos radica en la forma en que se envía y recibe la información, no en la implementación en sí. La implementación de estas funciones en sí es primitiva y no depende del número de barras del gráfico.

Pero como el gráfico es un objeto cuya información se distribuye entre muchas fuentes, todo el control se basa en colas de mensajes. Hasta que se procese la solicitud anterior, la siguiente espera.

Pero si tiene varias solicitudes para el mismo gráfico en una fila, entonces estas solicitudes posteriores se ejecutan muy rápidamente. Esto se debe a que nadie ha tenido tiempo de interponerse entre ellos y la primera solicitud.

[Nikolai Semko]

Slava:

El cuello de botella de las funciones de solicitud de datos del gráfico reside en la forma de enviar y recibir la información, no en la implementación en sí. La implementación de estas funciones en sí es primitiva y no depende del número de barras del gráfico.

Pero como el gráfico es un objeto cuya información se distribuye entre muchas fuentes, todo el control se basa en colas de mensajes. Hasta que se procese la solicitud anterior, la siguiente queda en espera.

Pero si tiene varias solicitudes para el mismo gráfico en una fila, entonces estas solicitudes posteriores se ejecutan muy rápidamente. Esto se debe a que nadie ha tenido tiempo de interponerse entre ellos y la primera consulta.

Que así sea. Pero el darse cuenta de esto no lo hace más fácil. Slava, no malinterpretes a un simple programador. Mi ejemplo de un indicador de prueba de los mensajes anteriores muestra claramente que el tiempo medio de ejecución de una petición deChartXYToTimePrice() es de 5000 - 10000 microsegundos (con el grosor de una vela de 1 píxel y la ventana MT estándar en la pantalla FullHD). ¿Qué se puede hacer en ese tiempo?

Por ejemplo, durante este tiempo puedes formar una imagen en la misma pantalla de 500 círculos sombreados y mostrarlos en la pantalla:

Aunque haya cola, ¿pero por qué es tan larga la cola?
En un lado de la ecuación hay una generación píxel a píxel de 500 círculos con su salida en la pantalla, y en el otro lado hay una simple consulta de dos dígitos. Y pesa lo mismo.
Un simple programador se sienta allí, rascándose la cabeza y no puede armar los rompecabezas.

[Slava]

Nikolai Semko:

Que así sea. Pero darse cuenta de eso no lo hace más fácil. Slava, no malinterpretes a un simple programador. Mi ejemplo de indicador de prueba de los mensajes anteriores muestra claramente que el tiempo medio de ejecución de la peticiónChartXYToTimePrice() es de 5000 - 10000 microsegundos (con un ancho de vela de 1 píxel y una ventana estándar MT en pantalla FullHD). ¿Qué se puede hacer en ese tiempo?

Por ejemplo, durante este tiempo es posible formar una imagen en la misma pantalla de 500 círculos sombreados y mostrarlos en la pantalla:

Aunque haya cola, pero ¿por qué hay una cola tan larga?
En un lado de la balanza está la formación píxel a píxel de 500 círculos y su visualización en la pantalla, y en el otro lado una simple consulta de dos dígitos. Y pesa lo mismo.
Un simple programador se sienta y se rasca la cabeza y no puede armar rompecabezas.

Ha percibido la diferencia entre el comando sincrónico y el comando asincrónico.