Crear Criterios Personalizados de Optimización de Asesores Expertos

Introducción

El Terminal de Cliente MetaTrader 5 ofrece un gran abanico de posibilidades para la optimización de parámetros de Asesores Expertos. Además de los criterios de optimización incluidos en el Probador de Estrategias, los desarrolladores tienen la posibilidad de crear sus propios criterios. Esto lleva a un número casi ilimitado de posibilidades para poner a prueba y optimizar los Asesores Expertos. Este artículo describe formas prácticas de crear estos criterios, tanto complejas como simples.

1. Revisión de Prestaciones del Probador de Estrategias

Este tema ya se ha tratado varias veces, de modo que simplemente haré una lista de artículos con breves descripciones. Le recomiendo familiarizarse con los siguientes materiales antes de leer este artículo.

• "The Fundamentals of Testing in MetaTrader 5" ("Fundamentos de la Simulación en MetaTrader 5"). Cubre todos los aspectos técnicos de la simulación de un Asesor Experto (EA, por sus siglas en inglés) en detalle: los modos de generación de ticks, el trabajo con precios abiertos, y las barras M1. Describe el uso de indicadores durante una simulación, emulación de variables del entorno y gestión de eventos estándares. Además, trata los puntos básicos de la simulación multidivisa.
• "Guide to Testing and Optimizing of Expert Advisors in MQL5" ("Guía de Simulación y Optimización de Asesores Expertos en MQL5"). Cubre la cuestión de la simulación y optimización de parámetros de entrada de un Asesor Experto. Describe el proceso de ajuste de parámetros, interpretación de resultados de la simulación y selección de los mejores parámetros.
• "Using the TesterWithdrawal() Function for Modeling the Withdrawals of Profit" ("Usar la Función TesterWithdrawal() para Modelar la Retirada de Beneficio"). Trata sobre el uso de la función TesterWithdrawal para modelar retiradas de dinero de una cuenta en el Probador de Estrategias. También muestra cómo afecta esta función al algoritmo de cálculo de reducciones de beneficio en el Probador de Estrategias.

Y, por supuesto, en primer lugar debe familiarizase con la documentación facilitada con el terminal de cliente.

2. Los Criterios de Optimización Incluidos en el Probador de Estrategias

Si echa un vistazo a la documentación, encontrará la siguiente descripción: un criterio de optimización es un factor determinado cuyo valor define la calidad de un conjunto simulado de parámetros. Cuanto más alto sea el valor del criterio de optimización, mejor se considerará el resultado de la simulación con el conjunto de parámetros dado.

Aquí deberíamos destacar algo importante: un criterio de optimización se puede usar solo en el modo de algoritmo genético de optimización. Queda claro, pues, que al pasar por todas las combinaciones posibles de valores de parámetro, no puede haber ningún factor para elegir parámetros óptimos de un Asesor Experto. Por otro lado, podemos guardar los resultados de la simulación y después procesarlos para encontrar una combinación óptima de parámetros.

Tal y como se explica en la documentación, el Probador de Estrategias incluye los siguientes criterios de optimización para usar en el algoritmo genético:

• Balance max - el valor más alto del saldo;
• Balance + max Profit Factor - el valor más alto del producto del saldo por el factor de beneficio;
• Balance + max Expected Payoff - el valor del producto del saldo por la recompensa esperada;
• Balance + min Drawdown - en este caso, el valor de saldo por el nivel de reducción se tienen en cuenta: (100% - Reducción)*Saldo;
• Balance + max Recovery Factor - el producto del saldo por el factor de recuperación;
• Balance + max Sharpe Ratio - el valor del producto del saldo por la proporción Sharpe;
• Custom max - criterio de optimización personalizado. Aquí, el criterio de optimización es el valor de la función OnTester() en el Asesor Experto. Este parámetro nos permite usar cualquier valor personalizado para la optimización del Asesor Experto.

Los criterios de optimización se pueden seleccionar en la pestaña Settings (Configuración) del Probador de Estrategias, tal y como se muestra en la fig. 1:

Fig. 1. Elegir criterios de optimización para el Asesor Experto.

El criterio Custom max, que es el último de la lista, es el más interesante para nosotros, y su uso es el tema de este artículo.

3. Creación de Criterios de Optimización Personalizados

Lo primero que debe hacer es dar al usuario la posibilidad de combinar libremente parámetros (sin limitarse a los mostrados en la fig. 1, sino personalizados) que se calculen en el Probador de Estrategias tras cada ejecución de un Asesor Experto.

Por ejemplo, la siguiente variante es interesante: Balance max + min Drawdown + Trades Number - cuantas más operaciones de trading haya, más fiable será el resultado. O la siguiente - Balance max + min Drawdown + max Profit Factor. Por supuesto, hay muchas otras combinaciones interesantes que no se incluyen en la configuración del Probador de Estrategias.

Llamemos a estas combinaciones de criterios criterios simples de optimización.

Pero estos criterios no son suficientes para hacer un cálculo fiable de un sistema de trading. Si lo miramos desde el punto de vista del concepto de trading -conseguir un beneficio con un riesgo mínimo-, podemos suponer el siguiente criterio: podemos optimizar parámetros para obtener una curva suavizada de saldo con desviación mínima de resultados de operaciones de trading separadas desde la línea recta.

Llamemos a este criterio criterio de optimización por curva de saldo.

El siguiente criterio de optimización que usaremos es el coeficiente de seguridad de un sistema de trading. Este coeficiente se describe en el artículo "Be In-Phase". Caracteriza la correspondencia de un sistema de trading con el mercado; esto es lo que necesitamos descubrir durante la optimización de parámetros. Llamémoslo criterio de optimización por el coeficiente de seguridad de un sistema de trading (CSTS).

Además, hagamos posible la combinación libre de los criterios descritos.

4. La Función OnTester()

Antes de escribir las partes del código, echemos un vistazo al uso de criterios personalizados de optimización de EA en el Probador de Estrategias.

La función predeterminada OnTester() está diseñada para la creación de criterios personalizados de optimización. Se llama automáticamente al final de cada pase de simulación de un Asesor Experto dentro de un intervalo de tiempo especificado. Esta función se llama justo antes de la llamada de la función OnDeinit().

De nuevo, note que al usar la función OnTester() debería activar el modo de optimización Fast genetic base algorithm (Algoritmo base genético rápido) tal y como se muestra en la fig.1.

Esta función tiene el formato doble de valor devuelto, que se usa para la optimización en el Probador de Estrategias.

Eche un vistazo a la documentación una vez más:

En la optimización genética se aplica una distribución a los resultados dentro de una generación. Es decir, desde el punto de vista del criterio de optimización, los mejores resultados se obtienen con los valores más grandes. En esta distribución, los peores valores se posicionan al final, después se eliminan y no participan en la formación de la siguiente generación.

Por tanto, al crear un criterio de optimización personalizado, necesitamos obtener un valor integral que se usará para cálculos de trading del Asesor Experto. Cuando mayor sea el valor, mejor serán los resultados de trading del Asesor Experto.

5. Escribir Asesores Expertos Experimentales

Ahora es el momento de hacer un Asesor Experto que optimizaremos en el Probador de Estrategias. En este caso, el principal requisito para ello es la sencillez y la velocidad, y no perder demasiado tiempo en el procedimiento rutinario de optimización. Además, es recomendable si el Asesor Experto no nos reporta muchas pérdidas.

Tomemos el Asesor Experto descrito en el artículo "Several Ways of Finding a Trend in MQL5" ("Varias Formas de Encontrar una Tendencia en MQL5") como el EA experimental y mejorémoslo. Es destacable que el EA se basa en el "abanico" de tres medias móviles. La mejora consiste en eliminar el uso del indicador para aumentar la velocidad de la operación y mover la parte de los cálculos del código dentro del mismo EA. Esto permite aumentar la velocidad de la simulación significativamente (casi tres veces en un intervalo de dos años).

La parte de la configuración de los parámetros de entrada es sencilla:

input double Lots = 0.1; 
input int  MA1Period = 200; // period of the greatest moving average
input int  MA2Period = 50;  // period of the medium moving average
input int  MA3Period = 21;  // period of the smallest moving average

Los períodos de las medias móviles son lo que vamos a optimizar.

La estructura y operación del Asesor Experto se describen en detalle en el artículo mencionado arriba, de modo que no entraremos en ello ahora. La innovación principal es el controlador del evento de compleción de otro pase de simulación - la función OnTester(). Actualmente, está vacío y devuelve el control.

//---------------------------------------------------------------------
//  The handler of the event of completion of another test pass:
//---------------------------------------------------------------------
double OnTester()
{
  return(0.0);
}

El archivo del EA - FanExpert.mq5 se puede encontrar como archivo adjunto de este artículo. Podemos asegurarnos que es idéntico al FanTrendExpert.mq5 EA desde el punto de vista de las transacciones realizadas. La comprobación de existencia y dirección de una señal se lleva a cabo en la apertura de una nueva barra en un gráfico.

Para obtener el resultado de la simulación calculada al final de cada pase se usa la función TesterStatistics(); devuelve el valor estadístico requerido calculado como resultado de la simulación. Solo se puede llamar desde las funciones OnTester() y OnDeinit(), de lo contrario el resultado queda indefinido.

Ahora añadamos un criterio de optimización personalizado. Supongamos que necesitamos encontrar resultados óptimos en base a un valor máximo de factor de recuperación - max Recovery Factor. Para ello, debemos saber los valores de la reducción máxima de saldo en dinero y el beneficio bruto al final de la simulación. El factor de recuperación se calcula como la división del beneficio en la reducción máxima.

Se hace solo como ejemplo, puesto que el factor de recuperación ya viene incluido en la lista de resultados estadísticos de simulación calculados.

Para ello, añada la función OnTester():

//---------------------------------------------------------------------
//  The handler of the event of completion of another test pass:
//---------------------------------------------------------------------
double OnTester()
{
  double  profit = TesterStatistics(STAT_PROFIT);
  double  max_dd = TesterStatistics(STAT_BALANCE_DD);
  double  rec_factor = profit/max_dd;

  return(rec_factor);
}

La comprobación de la división por cero se excluye del código para hacerlo más fácil. Puesto que la reducción máxima puede ser igual a cero, esta comprobación se debe hacer en un Asesor Experto real.

Ahora, creemos el criterio mencionado arriba: Balance max + min Drawdown + Trades Number - Balance + Minimal Drawdown + Number of Trades.

Para ello, cambie la función OnTester() de la siguiente forma:

double OnTester()
{
  double  param = 0.0;

//  Balance max + min Drawdown + Trades Number:
  double  balance = TesterStatistics(STAT_PROFIT);
  double  min_dd = TesterStatistics(STAT_BALANCE_DD);
  if(min_dd > 0.0)
  {
    min_dd = 1.0 / min_dd;
  }
  double  trades_number = TesterStatistics(STAT_TRADES);
  param = balance * min_dd * trades_number;

  return(param);
}

Aquí tomamos un valor opuesto a la reducción, porque cuanto más pequeña sea la reducción, mejor será la situación, suponiendo que otras condiciones sean iguales. Ejecute la optimización del EA FanExpert con el criterio de optimización creado por el parámetro MA1Period usando el intervalo 2009.06.01 - 2011.06.03 y el marco cronológico Н1. Configure el intervalo de valores de la media móvil de 100 a 2000.

Al final de la optimización, obtendrá la siguiente tabla de valores ordenados por los mejores parámetros:

Fig. 2. Los mejores resultados de la optimización por el criterio Balance max + min Drawdown + Trades Number.

Los mejores parámetros se alistan aquí (por la columna Result).

Ahora echemos un vistazo a los peores parámetros:

Fig. 3. Los peores parámetros de optimización por el criterio Balance max + min Drawdown + Trades Number.

Al comparar las dos tablas, puede ver que la reducción y el beneficio se consideran junto con el número de operaciones de trading. En otras palabras, nuestro criterio de optimización funciona. Además, podemos ver el gráfico de optimización (lineal):

Fig. 4. El gráfico de optimización por el criterio Balance max + min Drawdown + Trades Number.

El eje horizontal muestra el parámetro optimizado, y el eje vertical muestra el criterio de optimización. Podemos ver el máximo claro del criterio configurado; está localizado dentro del intervalo entre 980 y 1200 de períodos.

Debería entender y recordar que se trata de la optimización genética de parámetros, no la búsqueda entera. Esta es la razón por la que la fig. 2 y la fig. 3 contienen los parámetros más "viables" que han pasado la selección natural en varias generaciones. Probablemente se hayan descartado algunas variantes exitosas.

La curva saldo/beneficio para el período 1106 tiene el siguiente aspecto:

Fig. 5. La curva saldo/beneficio para el período MA1 = período 1106.

6. Creación de Clases de Criterios de Optimización Personalizados

Ya hemos aprendido cómo crear y usar criterios de optimización simples. Ahora hagamos una clase para simplificar su uso en Asesores Expertos. Uno de los principales requisitos para esta clase es la velocidad de operación, además de la conveniencia de su uso. Los cálculos de criterios de optimización se deben llevar a cabo rápidamente, de lo contrario tendrá que esperar un buen rato para obtener los resultados.

MetaTrader 5 nos permite usar la tecnología de cálculo de nube para la optimización. Esto es un gran avance, puesto que el procesamiento de un gran número de parámetros requiere un enorme poder de cálculo. Por tanto, para desarrollar nuestra clase usaremos las soluciones más simples y rápidas, aunque no son tan elegantes desde el punto de vista de programación.

Para el desarrollo, usaremos las clases de organización de datos estándar que hemos recibido junto con el terminal de cliente.

En primer lugar, clasifiquemos los tipos de resultados estadísticos de simulación calculados:

• Tipo flotante o íntegro con la proporcionalidad directa entre los valores de resultados de simulación y criterio de optimización.

En otras palabras, cuanto mayor sea el valor del resultado de la simulación, mejor y mayor será el valor del criterio de optimización. Un buen ejemplo de este resultado de simulación Beneficio bruto al final de la simulación STAT_PROFIT. El valor tiene el formato flotante y puede cambiar de infinito negativo (en realidad está limitado por el valor de depósito) a infinito positivo.

Otro ejemplo del resultado de simulación de este tipo es el Número de operaciones de trading STAT_TRADES. Generalmente, cuanto mayor sea el número de operaciones, más fiable será el resultado de la optimización. El valor tiene el formato íntegro, y puede cambiar de cero a infinito positivo.

• Tipo flotante o íntegro con la proporcionalidad inversa entre los valores de resultados de simulación y criterio de optimización.

En otras palabras, cuanto menor sea el valor del resultado de la simulación, mejor y mayor será el valor del criterio de optimización. Un ejemplo de este resultado de simulación Reducción máxima de saldo en dinero STAT_BALANCE_DD, así como cualquier otra reducción.

Para obtener este tipo de resultado de simulación, tomaremos un valor inverso para el cálculo del valor del criterio de optimización. Por supuesto, deberemos implementar la simulación para la división por cero para evitar el error correspondiente.

La clase base para la creación de los criterios personalizados de optimización TCustomCriterion es muy simple. Su propósito es la determinación de la funcionalidad base. Tendrá el siguiente aspecto:

class TCustomCriterion : public CObject
{
protected:
  int     criterion_level;        // type of criterion

public:
  int   GetCriterionLevel();
  virtual double  GetCriterion();  // get value of the result of optimization
};

El método virtual TCustomCriterion::GetCriterion debería anularse en clases heredadas. Este es el principal método que devuelve el valor del resultado integral de la simulación de un Asesor Experto el final de cada pase de simulación.

El miembro de clase TCustomCriterion::criterion_level guarda el tipo de criterio personalizado inherente en esta instancia de clase. Se usará después para la diferenciación de objetos por sus tipos.

Ahora podemos heredar de él todas las clases requeridas para la optimización.

La clase TSimpleCriterion está diseñada para la creación de criterios personalizados "simples" que se corresponden con un resultado estadístico especificado de la simulación. Su determinación tendrá el siguiente aspecto:

class TSimpleCriterion : public TCustomCriterion
{
protected:
  ENUM_STATISTICS  stat_param_type;

public:
  ENUM_STATISTICS  GetCriterionType();     // get type of optimized stat. parameter

public:
  virtual double   GetCriterion();           // получить значение результата оптимизации
  TSimpleCriterion(ENUM_STATISTICS _stat); // конструктор
};

Aquí usamos un constructor con parámetros; se implementa de la siguiente manera:

//---------------------------------------------------------------------
//  Constructor:
//---------------------------------------------------------------------
TSimpleCriterion::TSimpleCriterion(ENUM_STATISTICS _stat)
:
stat_param_type( _stat )
{
  criterion_level = 0;
}

Esta nueva prestación del lenguaje MQL5 es conveniente para crear instancias de clase. Asimismo, hemos anulado el método virtual TSimpleCriterion::GetCriterion que se usa para obtener el resultado de la optimización al final de cada pase de simulación. Su implementación es simple:

//---------------------------------------------------------------------
//  Get the result of optimization:
//---------------------------------------------------------------------
double  TSimpleCriterion::GetCriterion()
{
  return(TesterStatistics(stat_param_type));
}

Como puede ver, devuelve el resultado estadístico correspondiente de la simulación.

El siguiente tipo de criterio de optimización personalizado "simple" se crea usando la clase TSimpleDivCriterion. Está diseñado para criterios con proporcionalidad inversa entre los valores del resultado de simulación y el criterio de optimización.

El método TSimpleDivCriterion::GetCriterion tendrá el siguiente aspecto:

//---------------------------------------------------------------------
//  Get value of the optimization result:
//---------------------------------------------------------------------
double  TSimpleDivCriterion::GetCriterion()
{
  double  temp = TesterStatistics(stat_param_type);
  if(temp>0.0)
  {
    return(1.0/temp);
  }
  return(0.0);
}

Este código no requiere ninguna descripción adicional.

Otros dos tipos de criterios personalizados de optimización "simples" se crean usando las clases TSimpleMinCriterion y TSimpleMaxCriterion. Están diseñados para la creación de criterios con valores limitados de resultado estadístico de simulación de ambos desde abajo y desde arriba, respectivamente.

Pueden ser útiles en caso de que necesite descartar deliberadamente valores incorrectos de parámetros durante la optimización. Por ejemplo, puede limitar el número mínimo de operaciones de trading, la reducción máxima, etc.

La descripción de la clase TSimpleMinCriterion tendrá el siguiente aspecto:

class TSimpleMinCriterion : public TSimpleCriterion
{
  double  min_stat_param;

public:
  virtual double  GetCriterion();    // получить значение результата оптимизации
  TSimpleMinCriterion(ENUM_STATISTICS _stat, double _min);
};

Aquí usaremos el constructor con dos parámetros. El parámetro _min configura el valor mínimo de un resultado estadístico de simulación. Si con un nuevo pase de simulación obtenemos como resultado un valor menor que el especificado, el resultado se descarta.

La implementación del método TSimpleMinCriterion ::GetCriterion es como se muestra a continuación:

//---------------------------------------------------------------------
//  Get value of the optimization result:
//---------------------------------------------------------------------
double  TSimpleMinCriterion::GetCriterion()
{
  double  temp = TesterStatistics(stat_param_type);
  if(temp<this.min_stat_param)
  {
    return(-1.0);
  }
  return(temp);
}

La clase TSimpleMaxCriterion se realiza de forma similar, y no requiere descripción adicional alguna. Las otras clases de los criterios personalizados "simples" se hacen de forma similar a los descritos arriba; se pueden localizar en el archivo CustomOptimisation.mqh, adjunto a este artículo. El mismo principio se puede usar para desarrollar cualquier otra clase para usar en optimización.

Antes de usar las clases descritas arriba, creemos una clase contenedora para una operación más conveniente con el conjunto de criterios. Para ello, usaremos también las clases para organizar datos estándar. Puesto que necesitamos un procesamiento consecuente simple de los criterios, la clase más adecuada para ello es CArrayObj. Nos permite organizar un array dinámico de objetos heredados de la clase CObject.

La descripción de la clase contenedora TCustomCriterionArray es muy simple:

class TCustomCriterionArray : public CArrayObj
{
public:
  virtual double  GetCriterion( );  // get value of the optimization result
};

Solo tiene un método - TCustomCriterionArray::GetCriterion, que devuelve el valor del criterio de optimización al final de cada pase de simulación. Su implementación es así:

double  TCustomCriterionArray::GetCriterion()
{
  double  temp = 1.0;
  int     count = this.Total();
  if(count == 0)
  {
    return(0.0);
  }
  for(int i=0; i<count; i++)
  {
    temp *= ((TCustomCriterion*)(this.At(i))).GetCriterion();
    if(temp <= 0.0)
    {
      return(temp);
    }
  }

  return(temp);
}

Un detalle que debería tener en cuenta: si se encuentra con un valor negativo durante el procesamiento de criterios, los siguientes pasos del ciclo no tendrán sentido. Además, elimina la situación en la que obtiene un valor positivo como resultado de la multiplicación de dos valores negativos.

7. Usar Clases de Criterios de Optimización Personalizados

Ahora tenemos todo para usar los criterios personalizados "simples" durante la optimización de Asesores Expertos. Analicemos la secuencia de pasos para mejorar el EA "experimental" FanExpert:

• Añada el archivo incluido que contiene la descripción de clases de los criterios personalizados:

#include <CustomOptimisation.mqh>

• Añada el puntero al objeto de la clase contenedora para usar criterios personalizados:

TCustomCriterionArray*  criterion_Ptr;

• Inicialice el puntero al objeto de la clase contenedor para usar criterios personalizados:

  criterion_array = new TCustomCriterionArray();
  if(CheckPointer(criterion_array) == POINTER_INVALID)
  {
    return(-1);
  }

Se hace en la función OnInit. En caso de que la creación del objeto no tenga éxito, se devolverá un valor negativo. En este caso, el Asesor Experto detendrá sus operaciones.

• Añada los criterios de optimización requeridos al Asesor Experto:

  criterion_Ptr.Add(new TSimpleCriterion(STAT_PROFIT));
  criterion_Ptr.Add(new TSimpleDivCriterion(STAT_BALANCE_DD));
  criterion_Ptr.Add(new TSimpleMinCriterion(STAT_TRADES, 20.0));

En este caso, hemos decidido optimizar el EA por el beneficio máximo, reducción mínima y el máximo número de operaciones de trading. Además, descartaremos los conjuntos de parámetros externos del Asesor Experto que resulta en menos de veinte operaciones.

• Añada la llamada correspondientes a la función OnTester:

  return(criterion_Ptr.GetCriterion());

• En la función OnDeinit, añada el código para la eliminación del objeto contenedor:

  if(CheckPointer(criterion_Ptr) == POINTER_DYNAMIC)
  {
    delete(criterion_Ptr);
  }

Esto es todo sobre la optimización. Ejecute la optimización y asegúrese de que todo funciona como debería. Para ello, configure los parámetros en la pestaña Settings (Configuración) del Probador de Estrategias tal y como se muestra en la figura de abajo:

Fig. 6. Configuración del Probador de Estrategias.

El conjunto del intervalo de optimización de parámetros de entrada en la pestaña Input parameters (Parámetros de entrada) del Probador de Estrategias tal y como se muestra en fig. 7:

Fig. 7. Parámetros de entrada optimizados.

Utilice los agentes "cloud" (nube) para la optimización. Para ello, configure los siguientes parámetros en la pestaña Agents (Agentes):

Fig. 8. Parámetros de agentes de simulación.

Ahora haga click en el botón Start (Inicio) (fig.6) y espere a que se complete la optimización. Al usar la tecnología de cálculo de nube, la optimización se lleva a cabo de forma muy rápida. El final, obtendremos los siguientes resultados de optimización por los criterios especificados:

Fig. 9. Resultados de optimización.

Nuestro Asesor Experto "experimental" se ha optimizado con éxito. Nos ha llevado 13 minutos el optimizarlo con agentes de nube. El EA para comprobar este criterio se encuentra en el archivo adjunto en el artículo FanExpertSimple.mq5.

8. Crear una Clase de Criterio de Optimización Personalizado en Base al Análisis de la Curva de Saldo

La base para la creación de esta clase es el artículo "Controlling the Slope of Balance Curve During Work of an Expert Advisor" ("Controlar la Pendiente de la Curva de Saldo Durante el Trabajo con un Asesor Experto"). La idea de este criterio de optimización es hacer la línea de saldo tan similar a una línea recta como sea posible. El grado de similitud con una línea recta se calculará por el valor de de la desviación estándar de sus resultados de trading. La ecuación de una línea recta se calculará por la línea de regresión dibujada por los resultados de transacciones en el Probador de Estrategias.

Para descartar curvas con saldo resultante negativo, configure límites adicionales: el beneficio resultante será mayor que un valor especificado, y el número de operaciones no será menor que el valor especificado.

Por tanto, el criterio de optimización será inversamente proporcional al valor de la desviación estándar de resultados de operaciones de trading de la línea recta, considerando los límites del beneficio resultante y el número de operaciones.

Para implementar el criterio de optimización en base a la curva de saldo, necesitaremos la clase TBalanceSlope del artículo mencionado arriba. La vamos a cambiar: usaremos constructores con parámetros (por motivos de conveniencia) y añadiremos el cálculo de desviación estándar al cálculo de la regresión lineal. Este código se encuentra en el archivo adjunto al artículo BalanceSlope.mqh.

La secuencia de pasos para añadir este criterio de optimización al Asesor Experto es el mismo que el descrito arriba. Ahora, los criterios de optimización tienen el siguiente aspecto:

criterion_Ptr.Add(new TBalanceSlopeCriterion(Symbol( ), 10000.0));

Además del criterio de curva de saldo, podemos añadir otros criterios desarrollados por nosotros mismos. Dejo a los lectores la posibilidad de experimentar con diferentes conjuntos de parámetros estadísticos de simulación.

Ejecutemos la optimización con los criterios configurados. Para obtener más operaciones, realice la optimización usando el marco cronológico H4. el período 2010.01.01 - 2011.01.01 y el símbolo EURUSD. Obtendremos una serie de resultados:

Fig. 10. El resultado de la optimización por la curva de saldo.

Ahora deberemos calcular la calidad de la optimización Creo que el criterio principal es el trabajo del Asesor Experto fuera del período de optimización. Para comprobar su funcionamiento, ejecute una simulación con el período 2010.01.01-2011.06.14.

Compare los dos resultados (con un beneficio resultante muy similar) del conjunto de parámetros óptimos - el mejor resultado con un resultado del medio. Los resultados fuera del período de optimización están separados por la línea roja:

Fig. 11. La optimización con el mejor resultado.

En general, el comportamiento de la curva no ha empeorado. La rentabilidad ha bajado ligeramente de 1,60 a 1,56.

Fig. 12. El resultado medio de la simulación.

El Asesor Experto no resulta rentable fuera del período de optimización. La rentabilidad ha aumentado significativamente de 2,17 a 1,75.

Por tanto, podemos llegar a la conclusión de que la hipótesis de correlación de la curva de saldo con la duración de funcionamiento de los parámetros optimizados tiene el derecho de existir. Ciertamente, no podemos excluir la variante cuando un resultado aceptable al usar este criterio resulta inalcanzable para un Asesor Experto. En este caso, deberemos llevar a cabo algunos análisis y experimentos adicionales.

Probablemente, para este criterio deberemos usar el período máximo posible (pero razonable). El Asesor Experto para simular este criterio se encuentra en el archivo adjunto FanExpertBalance.mq5.

9. Crear una Clase de un Criterio de Optimización Personalizado en Base al Coeficiente de Sistema de Trading Seguro (CSTS)

Tal y como se describe en el artículo "Be in-Phase", el coeficiente de sistema de trading seguro (CSTS, por sus siglas en inglés) se calcula usando la siguiente fórmula:

CSTS = Avg.Win / Avg.Loss ((110% - %Win) / (%Win-10%) + 1)

donde:

• Avg.Win - el valor medio de una transacción rentable;
• Avg.Loss - el valor medio de una transacción no rentable;
• %Win - el porcentaje de transacciones rentables;

Si el valor CSTS es menor de 1, el sistema de trading está en la zona de alto riesgo; valores aún más pequeños indicarían la zona de trading no rentable. Cuanto mayor sea el valor de CSTS, mejor se ajustará el sistema de trading al mercado, y más rentable será.

Todos los valores estadísticos requeridos para el cálculo de CSTS se calculan en el Probador de Estrategias después de cada pase de simulación. Se deja para crear la clase TTSSFCriterion heredada de TCustomCriterion e implementar el método GetCriterion() en ella. La implementación de este método en el código es así:

double  TTSSFCriterion::GetCriterion()
{
  double  avg_win = TesterStatistics(STAT_GROSS_PROFIT) / TesterStatistics(STAT_PROFIT_TRADES);
  double  avg_loss = -TesterStatistics(STAT_GROSS_LOSS) / TesterStatistics(STAT_LOSS_TRADES);
  double  win_perc = 100.0 * TesterStatistics(STAT_PROFIT_TRADES) / TesterStatistics(STAT_TRADES);

//  Calculated safe ratio for this percentage of profitable deals:
  double  teor = (110.0 - win_perc) / (win_perc - 10.0) + 1.0;

//  Calculate real ratio:
  double  real = avg_win / avg_loss;

//  CSTS:
  double  tssf = real / teor;

  return(tssf);
}

Supongo que estos períodos cortos son adecuados para este criterio de optimización. No obstante, para evitar el ajuste, deberíamos tomar resultados que estén en el medio de los resultados de la optimización.

Les damos a nuestros lectores la posibilidad de llevar a cabo una optimización por sí mismos. El Asesor Experto para simular este criterio se encuentra en el archivo adjunto FanExpertTSSF.mq5.

Conclusión

En cualquier caso, hay que admitir que una solución tan sencilla para la implementación de la posible creación de criterios de optimización personalizados (usando un porcentaje integral solo) es casi perfecta, en comparación con otras variantes. Nos permite elevar la barra de desarrollo de sistemas de trading robustos a un nivel más alto. El uso de la tecnología de nube reduce la limitación de optimizaciones ejecutadas de forma significativa.

Otras formas de evolución podrían estar conectadas con criterios matemática y estadísticamente justificados descritos en diversas fuentes de información. Tenemos una herramienta para ello.