Errores, fallos, preguntas - página 3131

Nuevo comentario
 
x572intraday #:

Sólo puedo responder por &= inmediatamente:

Guía de referencia MQL5 / Conceptos básicos del lenguaje / Operaciones y expresiones / Operaciones de asignación:

Por analogía con la variable acumulativa y:


Pero esta es mi primera experiencia con &=, así que podría estar equivocado.

Primero, todas las condiciones lógicas se suman en h_plus acumulativo dentro de for y la suma bool resultante se inserta en if que no tiene nada que ver con el for interno.
Pero aún así, sería más correcto no 
h_plus&=high[i]>high[i+increment];
sino 
h_plus = h_plus && high[i]>high[i+increment];
 
Alexey Viktorov #:

En su caso no es así, ya que deben cumplirse ambas condiciones. Pero si pones esto

entonces, sí. Si se cumple la condición "a", no se comprobará la segunda condición. Se ha luchado por esto durante años, y ahora sugieres que volvamos al siglo pasado...

Aunque... me equivoco en esta afirmación mía. Parece que no entiendo bien lo que está escrito aquí.

x572intraday #:

No me atrevo a llamarlo "error". Por eso me limitaré a decir que he observado una peculiaridad del operador if. Sospecho que también puede ser relevante para otras lenguas escritas.

Si a resulta ser cierto, la comprobación salta a Array[over_index] y aquí el terminal empieza a colapsar por la parte de'array out of range', que es bastante cierta. Pero si a resulta ser falso, el terminal no comprobará la condición Array[over_index] y por tanto la redundancia de índices, y si saltará más allá y el codificador no sabrá que hay un array con un índice inexistente en su programa... o más bien una existente pero redundante.

¿Tal vez debería haber una solución para que la comprobación de "matriz fuera de rango" se lleve a cabo hasta el final del bucle if y se emita el mismo mensaje? ¿O reducirá significativamente la velocidad del operador?

Aunque la condición && y la primera no se cumplan, la segunda no se comprobará. Así que, disculpen si he engañado a alguien...

 
x572intraday #:

Ya intenté tanto romper como volver en el calor del momento, pero sólo empeoró las cosas. Intentaré simplificar un poco más el código y replantearlo con break...

for(int i=start; i<rates_total-n && !IsStopped(); i++)
{
   for(int increment=1, bool h_plus=true ; h_plus && increment<=n ; increment++)
     h_plus =  high[i]>high[i+increment]; // можно не накапливать, вылетим из цикла на первом false

   if(h_plus) {...}
   ...
}

Así.

 

Al escalar el gráfico moviendo el ratón a lo largo de la línea de tiempo, el gráfico se desplaza a la izquierda o a la derecha, dependiendo de la dirección del ratón, de modo que todo lo que está en el foco de visión del usuario suele desaparecer más allá de los límites del gráfico. Esto es terriblemente incómodo, porque entonces hay que buscar el lugar adecuado, y esto ha sido así desde que conozco MT.

Era lógico suponer que tal vez al hacer clic en el icono de la lupa se reescalaría el gráfico hacia el centro, pero no, el comportamiento es el mismo que con la escala del ratón: el gráfico se desplaza hacia la izquierda (compresión) o hacia la derecha (expansión).

Queridos desarrolladores Le pedimos encarecidamente que cambie el comportamiento de la escala del gráfico, es necesario dejar el centro del gráfico en el centro.

Todas las personas con las que he hablado de este inconveniente de trabajar con el gráfico están de acuerdo conmigo, así que tengo una buena oportunidad de ser objetivo sobre este problema.

Intenté acostumbrarme durante 14 años, pero no pude.

 
JRandomTrader #:
for(int i=start; i<rates_total-n && !IsStopped(); i++)
{
   for(int increment=1, bool h_plus=true ; h_plus && increment<=n ; increment++)
     h_plus = high[i]>high[i+increment]; // можно не накапливать, вылетим из цикла на первом false

   if(h_plus) {...}
   ...
}

Es algo así.

Una nueva idea, la probaré.

En cuanto a la opción anterior:

for(int i=start; i<rates_total-3 && !IsStopped(); i++)
{
   bool h_plus=true; //false?
   for(int increment=1; increment<=n; increment++)
     {
      h_plus&=high[i]>high[i+increment];
      if(!h_plus)break;
     }
   if(h_plus) {...}
   ...
}

sin siquiera probarlo, ya está claro que

if(!h_plus)break;

está después de la suma, lo que significa que el terminal verá primero la línea anterior y entenderá que hay un array con un índice excesivo y dará el mismo mensaje de'array fuera de rango'. Esto es lo segundo. Y la primera es que deberíamos comprobar no por !h_plus sino por ArraySize(high)<=i+incremento y escapar del bucle en caso de que se supere el índice. Ayer intenté todo esto, pero fallé en algunas sutilezas. Sí, no había ningún mensaje, pero el indicador también empezó a hacer un lío.

 
x572intraday #:

En cuanto a la opción anterior:

sin siquiera probarlo, ya está claro que

está después de la suma, lo que significa que el terminal verá primero la línea anterior y entenderá que hay un array con un índice excesivo y dará el mismo mensaje de'array fuera de rango'. Esto es lo segundo. Y la primera es que deberíamos comprobar no por !h_plus sino por ArraySize(high)<=i+incremento y escapar del bucle en caso de que se supere el índice. Ayer intenté todo esto, pero fallé en algunas sutilezas. Sí, el mensajero se ha ido, pero el indicador también ha empezado a hacer aguas.

Así que el problema aquí es

i<rates_total-3
Escribí 
i<rates_total-n
por una razón, y la salida anticipada del bucle es precisamente para simular el cálculo de if()
 
x572intraday #:

No me atrevo a llamarlo "bug". Así que sólo diré que me he dado cuenta de una peculiaridad de la sentencia if. Sospecho que esto puede aplicarse también a otros idiomas.

Si a resulta ser cierto, la comprobación salta a Array[over_index] y aquí el terminal empieza a colapsar por la parte de'array out of range', que es bastante cierta. Pero si a resulta ser falso, el terminal no comprobará la condición Array[over_index] y por tanto la redundancia del índice, y si saltará más allá y el codificador no sabrá que hay un array con un índice inexistente en su programa... o más bien una existente pero redundante.

¿Tal vez debería haber una solución para que la comprobación de "matriz fuera de rango" se lleve a cabo hasta elfinal del bucle if y se emita el mismo mensaje? ¿O reducirá significativamente la velocidad del operador?


Si pones la variable a en false, el control se pasa y no afecta al array ni al código entre paréntesis después de if, porque en tu caso

if(a && Array[over_index]>val) {...}

el control pasará a la parte derecha de la condición sólo si la parte izquierda (a) es verdadera

si, por ejemplo, hace

if(check(over_index) && Array[over_index]>val) {...}

donde la función check comprueba el array, nunca obtendrá "array fuera de rango". Así que, puede comprobar el índice del array y dirigirlo en un if. Pero pasar el control a la segunda parte del if con el operador &&, si la primera parte es falsa, difícilmente es posible en cualquiera de los lenguajes de programación existentes...

 

Hay un problema, aparece de forma aleatoria y ocasional.

Aparece cuando se trabaja en el probador con varias monedas.

En cada ciclo solicito los precios reales de los símbolos. Si por alguna razón el comprobador no recibe cotizaciones para un símbolo concreto, utiliza las cotizaciones obtenidas anteriormente para otro símbolo.

Debería abrir una posición si el precio es superior al especificado. Debería abrir la posición si tengo datos erróneos de otro símbolo.

El símbolo EURCAD se abre si el precio está por encima de 1,45117. 1,74425>1,45117? Sí, es más alto pero es el precio de otro símbolo.

Hemos detectado 7 pedidos erróneos de un total de 500.

 
Yury Lemeshev #:

Hay un problema, aparece de forma aleatoria y ocasional.

Aparece cuando se trabaja en el probador con varias monedas.

En cada ciclo solicito los precios reales de los símbolos. Si por alguna razón el comprobador no recibe cotizaciones para un símbolo concreto, utiliza las cotizaciones obtenidas anteriormente para otro símbolo.

Debería abrir una posición si el precio es superior al especificado. Estoy utilizando datos erróneos de otro símbolo para la apertura.

Símbolo EURCAD si el precio está por encima de 1,45117 entonces se abre. 1,74425>1,45117? Sí, es más alto pero es el precio de otro símbolo.

Hemos detectado 7 pedidos erróneos de un total de 500.

El problema está en el código, pero los telépatas ya están celebrando y cuando salgan de su sueño, dirán que el error está en la línea 123652

 
Alexey Viktorov #:

Problemas en el código, pero los telépatas ya lo están celebrando, y cuando salgan de su juerga, dirán que el error está en la línea 123652

No hay ningún error en el código, el código fue reescrito para eliminar el error, y el error no aparece regularmente, es completamente caótico

1...312431253126312731283129313031313132313331343135313631373138...3187
Nuevo comentario