Modelado de las recotizaciones en el Tester y análisis de estabilidad del Asesor Experto

Introducción

El Tester de estrategia integrado en la Terminal de cliente de MetaTrader 4 es una buena herramienta de evaluación de verificación/calidad para un sistema de trading realizado en un Asesor Experto. Pero en este momento, tiene dos características críticas (a mi parecer). Primero, no utiliza el historial real de ticks para un símbolo, y modela los ticks en base a barras de un minuto. Segundo, no considera el fenómeno de que los brokers hacen recotizaciones a menudo, especialmente en volúmenes pequeños de trades o en los más grandes, y también en el "delgado" mercado poco-líquido. Bajo las condiciones de posibles recotizaciones, no hay ninguna oportunidad para comprobar el AE que lleve a la aparición de "griales", trading en "picos", saltos y cotizaciones de no-mercado. Se explicó y se probó varias veces, que una estrategia así no podría ser efectiva en una cuenta real pero, desafortunadamente, muy a menudo es difícil darse cuenta si el Asesor Experto juega en "picos" o no. En un historial de gráficos con trades impuestos, a veces es posible ver que el Tester abre trades en saltos, pero no siempre. También es difícil de predecir si reducirá la estrategia de recotizaciones durante esos momentos, o simplemente bajará la rentabilidad. En este artículo, voy a dar mis propios métodos para resolver este problema.

Suposiciones y definiciones

La recotización es la respuesta del broker a la orden que se envía al servidor del trade. Esta respuesta informa de que el precio (en el que se intenta abrir el trade) ya no es actual. Suele ocurrir en mercados poco-líquidos o volátiles, donde el precio puede cambiar mucho durante el proceso de la petición en la terminal. Las recotizaciones también son muy frecuentes cuando se intentan abrir en cotizaciones explosivas y de fuera de mercado.

Vamos a considerar que el Asesor Experto abre y cierra sólo las órdenes como OP_SELL y OP_BUY. No cambia la esencia, pero hace que algunas funciones sean más fáciles.

Modelar las recotizaciones en el Tester de estrategia

El objetivo es simular recotizaciones con la probabilidad establecida previamente en la apertura y cierre de las órdenes. Primeo vamos a introducir una variable externa especial que establecerá la probabilidad con la que ocurrirá la recotización artificial. De acuerdo a mi investigación/seguimiento, la probabilidad de la recotización en pares poco-líquidos es de cerca del 90% - por lo que vamos a usar este valor en el análisis del Asesor Experto.

extern int RQF_TEST = 90;

Como se utilizará la función MathRand con un valor de retorno aleatorio, es mejor iniciar la secuencia de números pseudo-aleatorios. Para ello, la función MathSrand se realizará al inicio del trabajo del Asesor Experto. Para información más detallada sobre la generación de valores aleatorios y del propósito de esta función, puede leer el libro de referencia sobre el lenguaje MQL. Hay que decir que, si no se usa MathSrand, pese a la "aletoriedad" de los números de la función MathRand, siempre se recibirán los mismos resultados. Y, por normal general, no es adecuado.:

int start()
  {
    //----
    MathSrand(TimeCurrent());

Después de eso, se deberían escribir las funciones propias OrderSend y OrderClose. Vamos a llamarlas MyOrderSend y MyOrderClose:

int MyOrderSend(int req_prob, string symbol, int cmd, double volume, double price, 
                int slippage, double stoploss, double takeprofit, 
                string comment="", int magic=0, datetime expiration=0, 
                color arrow_color=CLR_NONE)
  {
    if(IsTesting() && (MathRand() % 100) < req_prob && (cmd == OP_SELL || cmd == OP_BUY))
        return (-1); //modelling requote
    return(OrderSend(symbol, cmd, volume, price, slippage, stoploss, takeprofit, 
           comment, magic, expiration, arrow_color));
  }
 
bool MyOrderClose(int req_prob, int ticket, double lots, double price, int slippage,
                  color Color=CLR_NONE)
  {
    if(IsTesting() && (MathRand() % 100) < req_prob)
        return (false); //modelling requote
    return (OrderClose(ticket, lots, price, slippage, Color));
  }

Ahora habría que reemplazar todas las funciones OrderSend y OrderClose en el AE por MyOrderSend y MyOrderClose, con la indicación de la variable externa RQF_TEST introducida anteriormente como el primer argumento. Debajo hay un ejemplo de mi propio AE.

OrderClose -> MyOrderClose:

if(MyOrderClose(RQF_TEST, ticket, amount, Bid, 0, Blue)) 
// PREV: if(OrderClose(ticket, amount, Bid, 0, Blue))
  {
    Print("Skalpel: Order #" + ticket + " closed! (BUY, " + Bid + ")");
            //... Something
  }
else
  {
    // Requote or something like this
    Print("Skalpel: Error while closing order #" + ticket + " (BUY)!");
    // ... Something
  }

OrderSend -> MyOrderSend:

ticket = MyOrderSend(RQF_TEST, Symbol(), OP_BUY, amount, Ask, 0, 
                     Bid-StopLoss*Point, Bid+TakeProfit*Point, 
                     NULL, EXPERT_MAGIC, 0, Blue);
// PREV: OrderSend(Symbol(), OP_BUY, amount, Ask, 0, Bid - StopLoss*Point, 
// Bid+TakeProfit*Point, NULL, EXPERT_MAGIC, 0, Blue);
 
if(ticket > 0)
    Print("Skalpel: Order #" + ticket + " opened! (BUY)");
else
    Print("Skalpel: Error while placing order."); 
    // ... Requote or something like this

Conclusiones y análisis de los resultados

Lo primero que debería explicarse es el valor de la variable RQF_TEST. Establece la cantidad de recotizaciones para 100 trades y, en consecuencia, puede tomar el valor de 0, donde no hay ninguna recotización; y hasta 100, donde es absolutamente imposible abrir o cerrar la orden. Si RQF_TEST es igual a 90, como en el ejemplo, significa que por lo menos 90 de 100 intentos de abrir o cerrar la transacción serán un fracaso, es decir, se simulará la recotización.

De hecho, los resultados, que se recibieron en varios valores de RQF_TEST, muestran la estabilidad de la estrategia para las recotizaciones, y las diferencias en flujo grueso del tester y el broker.

Si los resultados se deterioran cuando el RQF_TEST aumenta, es necesario comprobar la conveniencia de una estrategia así, ya que la sensibilidad a las recotizaciones significa que está jugando con apuestas muy arriesgadas y agresivas, o con su pip. Se habló mucho sobre las consecuencias de un uso así de los asesores.

Como ejemplo, consideremos un gráfico del trabajo equilibrado de un AE clásico con apuestas arriesgadas, con varios valores de RQF_TEST. El Aseor Experto se coge del artículo "Mi primer Grial" (). Y se transformó ligeramente para la visualización. Todas las órdenes de tipo límite se realizan por las de los mercados normales, y también se recogen los parámetros para que los gráficos muestren el deterioro de los parámetros cuando las recotizaciones son más evidentes.

Si no hay recotizaciones (RQF_TEST = 0):

En 90 de 100 casos hay una recotización (RQF_TEST = 90):

Obviamente, la situación es muy deplorable. Especialmente en la estipulación de que probar EURCHF es el par con más liquidez y las recotizaciones son muy frecuentes incluso en los mercados silenciosos, mucho más en las apuestas arriesgadas. Por lo tanto, la conveniencia del uso del AE se desvanece, a pesar del precioso gráfico que falta durante la recotización.

Observaciones y adiciones

Es más bien difícil encontrar el asesor que pueda pasar de rentable a no rentable por las recotizaciones. Busqué durante mucho tiempo un Asesor Experto así, cuya reducción se pudiera demostrar claramente en el gráfico de balance. Normalmente la recotización (incluso al nivel de 50%) suprime la cantidad de transacciones y el beneficio cuando el gráfico es aparentemente el mismo (constante). Hay una explicación simple: si el broker no le permite abrir la orden en "participación" en 90 de 100 casos, en el 10% restante de las situaciones, recibirá algunos pips de beneficios, hasta que ya no se le prohíba utilizar AEs. En el artículo "Mi primer Grial" se describe una situación así. Pero incluso si se asume que el broker no sobrecargará (es difícil), el beneficio reducido 10 veces (y es exactamente así cuando se recotiza a un 90% - el asesor simplemente "pierde" 90 "participaciones" de 100) arrebatará todas las ventajas del "Grial" – será menos rentable que el depósito del banco.