¿Es el asesor adecuado para la vida real? - página 30

 
FOReignEXchange:

Definitivamente seguiré adelante cuando llegue el momento.

Buena suerte
 
dentraf:

Buena suerte.

Gracias.
 
FOReignEXchange:

La idea es operar en un mercado desordenado con alta volatilidad. Todos los principales pares de divisas son así ahora. La volatilidad es alta, la lógica y los sistemas no funcionan. Es un caos. ....
Vamos. Todo funciona como antes.
 

Después de la volatilidad de hoy, he comparado los resultados del probador con los resultados reales. Desgraciadamente, en dicho mercado se revelaron importantes discrepancias.

He desmontado los registros de la terminal por minutos y he visto algo bueno. Todos los pips fueron puestos exactamente en un punto. El robot ha recogido todo el beneficio que podía en este sector. Pero toda esta ganancia fue desperdiciada, ya que había un problema. El problema tiene solución, pero no puedo entender por qué es un problema. Es decir, no podemos eliminar los pedidos innecesarios. Creo que hay dos razones para ello.

Primero: En el registro dice esto

22:23:30 '882613': eliminar la orden pendiente #26344474 comprar stop 4,00 EURUSD a 1,3787 sl: 1,3773 tp: 1,3799
22:23:30 '882613': borrar orden pendiente #26344474 comprar stop 4,00 EURUSD a 1,3787 sl: 1,3773 tp: 1,3799 falló [Parámetros no válidos].

22:37:27 '882613': eliminar la orden pendiente #26347980 vender stop 4,00 EURUSD a 1,3668 sl: 1,3682 tp: 1,3656
22:37:27 '882613': borrar orden pendiente #26347980 vender stop 4.00 EURUSD a 1.3668 sl: 1.3682 tp: 1.3656 falló [Parámetros inválidos]
22:37:27 '882613': eliminar la orden pendiente #26347980 vender stop 4,00 EURUSD a 1,3668 sl: 1,3682 tp: 1,3656
22:37:28 '882613': borrar orden pendiente #26347980 vender 4,00 EURUSD a 1,3668 sl: 1,3682 tp: 1,3656 falló [Parámetros no válidos]

Estas dos órdenes no se borraron y ambas causaron pérdidas. La segunda orden intentó ser eliminada dos veces. No entiendo por qué no se borran. Todo funciona bien durante todo el día, pero aquí no, incluso poniendo RefreshRates() antes de la función de borrado.

Y en segundo lugar:

Creo que es un error. Parece que el terminal no tiene suficiente memoria ni cerebro. Se olvida que seleccionamos un orden. Estas son las piezas que no funcionan.

if (//Тут условие//)
   {
   if (OrderSelect(ticket_buy,SELECT_BY_TICKET)==true)
     {
     if (OrderType()==OP_BUYSTOP && Ask>(OrderOpenPrice()-4*Point)) 
        {
        i=0;
        while (i<10)
              {
              if (i>0) Sleep(500);      
              RefreshRates(); OrderDelete(ticket_buy); 
              err=GetLastError();
              if (err==0)
                 {
                 ticket_buy=0; return;
                 }
              i++;
              }
        }
     }
   }

Se cumplen todas las condiciones, las he comprobado con los comentarios. En la fase de comprobación del tipo de pedido todo se atasca. La función de borrado no se utiliza más. Aunque deberían, ya que todas las condiciones se cumplen y todos los comentarios las comprueban. No es la primera vez que observo que cuando seleccionamos una orden y luego introducimos algún parámetro de la orden seleccionada en la condición, a veces no se lee correctamente esta condición. Cuanto mayor sea el número de parámetros de orden en la condición, más a menudo fallará la condición. En este caso, tenemos los parámetros OrderType() y OrderOpenPrice(). Creo que muchos de nosotros hemos notado esta cosa extraña. ¿Cómo podemos deshacernos de él? ¿O tal vez el problema radica en otra cosa? Se me olvidó decir, que no hay errores en el registro en este caso, sólo que la condición no se cumple, aunque debería.

Creo que no puede haber un problema en el otro, porque la condición no se cumple rara vez, por lo general todo funciona bien en esta parte, pero a veces no funciona y trae pérdidas.

No juzgues duramente por un código tan analfabeto, soy autodidacta.

¿Por qué exactamente la retirada de pedidos se produce con tantos problemas? Mis pedidos se colocan exactamente como se necesita y el robot recoge todos los beneficios. Pero todo se complica porque no podemos eliminar los pedidos innecesarios. Si te deshaces de estos problemas, todo funcionará como debería.

 
FOReignEXchange:

A juzgar por el registro, el código no llegó a tiempo.

Es decir, la eliminación ya estaba en curso cuando se activó la orden.

 
TheXpert:

A juzgar por el registro, el código no llegó a tiempo.

Es decir, la eliminación ya estaba en curso cuando se activó la orden.


Y las órdenes pendientes se fijan exactamente a la misma hora y no se pierden. ¿Por qué hay un problema con el borrado? Especialmente en el segundo caso, intentó borrarlo dos veces.
 
FOReignEXchange:
Y las órdenes pendientes se fijan exactamente a la misma hora y no se pierden. ¿Por qué hay un problema con la eliminación? Más aún cuando en el segundo caso intentó borrarlo dos veces.

Fíjese bien: esta es la segunda vez que intenta eliminar una orden ejecutada, no una orden limitada.

Y para el ajuste hay niveles de parada y para la eliminación sólo hay niveles de libertad.

 
TheXpert:

Fíjese bien: esta es la segunda vez que intenta eliminar una orden ejecutada, no una orden limitada.

Y hay líneas de parada para hacer un pedido, pero sólo hay freesliders para eliminar, y eso si hay.


Todo está claro con el primer caso. ¡Muchas gracias! ¿Conoce el segundo? Es más importante porque ocurre más a menudo y causa más pérdidas. Todo está bien en términos de condiciones. Y no es la velocidad del mercado y hay mucho tiempo para quitarlo. La condición no se cumple, aunque debería hacerlo.
 
FOReignEXchange:

¿Conoce por casualidad el segundo? La condición no funciona, aunque debería hacerlo.

Tal vez esta condición a veces falla, es decir, su lado derecho

if (OrderType()==OP_BUYSTOP && Ask>(OrderOpenPrice()-4*Point))

Normalizar Preguntar antes de comparar.

 
OnGoing:

Tal vez esta condición a veces falla

Normalice la pregunta antes de compararla.


¿Así?

NormalizeDouble(Ask,Digits)>(OrderOpenPrice()-4*Point))