Sus símbolos y sus fuentes de datos en Metatrader 5 - página 11
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Añadiré otra función de prueba que contenga dos mesetas pares de valores máximos:
z = abs(tanh(x) + tanh(y))
Si se cambia X,Y de -20 a +20 con el paso 0,1, la iteración completa tarda 160801 iteraciones.
En la prueba, ambas mesetas se ven en 1.400 iteraciones, lo que supone menos del 1% de la búsqueda completa.
¿Alguien va a ejecutar esto en GA? Es interesante comparar.
Añadiré otra función de prueba que contenga dos mesetas pares de valores máximos:
z = abs(tanh(x) + tanh(y))
Si se cambia X,Y de -20 a +20 con el paso 0,1, la iteración completa tarda 160801 iteraciones.
En la prueba, ambas mesetas se ven en 1.400 iteraciones, lo que supone menos del 1% de la búsqueda completa.
¿Alguien va a ejecutar esto en GA? Es interesante comparar.
¿No estás buscando con GA?
Trabajar con dos argumentos de una función optimizada no es nada indicativo. No sólo porque el espacio de búsqueda es pequeño, sino también porque pueden aparecer las propiedades "malas" del propio algoritmo de búsqueda.
Convierte la fórmula en una forma con al menos 10 argumentos y aparecerán todas las propiedades positivas y negativas del algoritmo.
¿No estás buscando con GAs?
Trabajar con dos argumentos de una función optimizada no es nada indicativo. No sólo porque el espacio de búsqueda es pequeño, sino también porque pueden aparecer las propiedades "malas" del propio algoritmo de búsqueda.
Convierte la fórmula en una forma que tenga al menos 10 argumentos: todas las propiedades positivas y negativas del algoritmo aparecerán a la vez.
Esto no es GA, hay un enlace al artículo en el hilo.
Más arriba he puesto un ejemplo con seis parámetros. Toda la dificultad de mostrar muchos parámetros.
Si sugieres una función con más parámetros, haré una prueba.
Si sugieres una función con más parámetros, haré una prueba.
Y=a+b;
donde:
a=Piel(x1, y1)+Piel(x2, y2)+Piel(x3, y3)+Piel(x4, y4)+Piel(x5, y5);
b=Piel(x6, y6)+Piel(x7, y7)+Piel(x8, y8)+Piel(x9, y9)+Piel(x10, y10);
Ya sabes dónde buscar la función Piel.
Así que hay 20 variables, y la función Y es muy fácil de visualizar. Puedes utilizar este principio para construir una función con un número ilimitado de argumentos, pero aún así ser capaz de visualizarla.
Y en consecuencia, el resultado final se comprueba como Y*2/n con el valor conocido del extremo, donde n es el número total de argumentos.
¿Y puedes darme un ejemplo de un algoritmo en el que en un "subviraje" un sobreviraje completo esté en una docena de horas y en MT esté en meses?
En este enfoque, la secuencia de pases es de gran importancia, ya que casi todos los cálculos se almacenan en caché. Para casi todos los parámetros de entrada (todos independientes) del TC siempre hay buffers globales en el optimizador que almacenan los valores de las pasadas anteriores.
Por ejemplo, se utiliza la MA y el PriceChannel. Cada uno de estos indicadores tiene sus propios parámetros de entrada independientes. Por eso para cada indicador prescribimos (unas pocas líneas en realidad, con la POO debería ser aún más bonito) la función para llenar su buffer global. A continuación, comparamos la intensidad de recursos de cada indicador (PriceChannel es más pesado que MA). Los parámetros de entrada de los indicadores más pesados comienzan a enumerarse en el bucle externo (primer for), los simples - en el bucle interno (en for anidado).
Aquí es donde obtenemos una gran ganancia. Además, hay C++, cálculos de enteros y un sistema de pedidos propio sin comprobaciones innecesarias. Así es como se obtiene el resultado. Como resultado, las carreras individuales son al menos un orden de magnitud más rápidas que la MT. Y la optimización es órdenes de magnitud más rápida.
Lo que falta en el optimizador MT es la función OnOptimization que proporcionaría acceso completo a la matriz de resultados de optimización obtenida. Allí realizo diversos análisis de la matriz obtenida: filtrado, combinación de pases de una orden que no se solapan por tiempo de negociación, etc. Pero lo que es aún más útil es el cálculo de los coeficientes de ponderación de cada uno de los pases para componer una meta-TS en forma de cartera adecuada. Para ello, OnOptimization dispone de un vector-Equity para cada uno de los pases no "desesperados".
Pero el subcomprobador no se inventa en la fase de búsqueda de una ST que funcione, sino cuando ya se ha encontrado, por desgracia. La búsqueda en sí es una etapa completamente diferente: sin descripción.
¿Alguien va a hacer esto en GA? Es interesante comparar.
Y=a+b;
donde:
a=Piel(x1, y1)+Piel(x2, y2)+Piel(x3, y3)+Piel(x4, y4)+Piel(x5, y5);
b=Piel(x6, y6)+Piel(x7, y7)+Piel(x8, y8)+Piel(x9, y9)+Piel(x10, y10);
Ya sabes dónde buscar la función Piel.
Así que hay 20 variables, y la función Y es muy fácil de visualizar. Puedes utilizar este principio para construir una función con un número ilimitado de argumentos, pero aún así ser capaz de visualizarla.
Y en consecuencia, el resultado final se comprueba como Y*2/n con el valor conocido del extremo, donde n es el número total de argumentos.
¿Cuántas pasadas y con qué paso de variables es el cálculo?
¿A quién le importa si no le gusta la foto?
El GA de 64 bits en MT5 es muy bueno, resuelve cualquier problema, lo principal es formular el problema correctamente.
No sé de qué clase de pardillo se habla en este hilo sobre GA.
No creo que el problema esté en el GA, sino que el propio probador es inútil, sobre todo en la bolsa por el almacenamiento erróneo del historial de cotizaciones y la imposibilidad de guardar el propio historial.
Espero que este problema se solucione, pero me temo que tendré que esperar entre 3 y 5 años.
Por ejemplo, se utiliza la MA y el PriceChannel. Cada uno de estos indicadores tiene sus propios parámetros de entrada independientes. Por lo tanto, para cada indicador hay una función escrita (unas pocas líneas en realidad, con la POO debe ser aún más hermosa) que llena su correspondiente buffer global. A continuación, comparamos la intensidad de recursos de cada indicador (PriceChannel es más pesado que MA). Los parámetros de entrada de los indicadores más pesados comienzan a enumerarse en el bucle externo (primer for), los simples - en el bucle interno (en for anidado).
Algo me dice que este enfoque también podría hacerse fácilmente bajo GA. La cantidad de trabajo es más o menos la misma. El "bucle interior" está pasando en cada pasada...
Pero, sobre todo, ¿cuál sería la demanda? Como sospecho, no todo el mundo utiliza ni siquiera la simple función personalizada OnTester(). Pero es una herramienta de optimización muy potente.
Aquí, por ejemplo, está una de mis implementaciones:
double CDoublePeakBottomAdvisorPartsFactory::MyOnTester(CMyExpertT* pmeExpert)
{
ulong ulTickedTime = pmeExpert.GetTickedTime();
uint uiTotalNumberOfSL = pmeExpert.GetNumOfLosePositions();
double dDDPercent = TesterStatistics(STAT_EQUITY_DDREL_PERCENT);
double dStartBalance = TesterStatistics(STAT_INITIAL_DEPOSIT);
double dProfit = TesterStatistics(STAT_PROFIT);
double dNumOfTrades = TesterStatistics(STAT_TRADES);
double dNumOfProfitTrades = TesterStatistics(STAT_PROFIT_TRADES);
double dMaxNumOfSL = TesterStatistics(STAT_MAX_CONLOSS_TRADES);
double dRecoveryFactor = TesterStatistics(STAT_RECOVERY_FACTOR);
double dProfitTradesPerWeek = dNumOfProfitTrades/ulTickedTime*SECS_IN_WEEK;
double dProfitPerDay = dProfit/ulTickedTime*SECS_IN_DAY;
Print("Ticked time (days): ",DoubleToString(ulTickedTime/SECS_IN_DAY,2));
Print("Number Of Trades: ",DoubleToString(dNumOfTrades,1));
if(dNumOfTrades == 0)
{
Print("Ни одного трейда !");
return(-100000);
};
if(dMaxNumOfSL > uiIMaxNumOfSeqSL)
return(-10000 - dMaxNumOfSL*100 + dProfit/1000);
double dBarsPerTrade = ((double)ulTickedTime/PeriodSeconds(m_didData.m_etTimeFrame))/dNumOfTrades;
if((bILongAllow == false) || (bIShortAllow == false))
dBarsPerTrade /= 2;
if(dBarsPerTrade < MIN_BARS_PER_TRADE)
return(dBarsPerTrade-MIN_BARS_PER_TRADE + dRecoveryFactor);
Print("Max number Of SL: ",DoubleToString(dMaxNumOfSL,1));
if(iIMaxNumOfSeqSLForQualify > 0 && dMaxNumOfSL > iIMaxNumOfSeqSLForQualify)
{
Print("Слишком много СЛ подряд !");
return(dRecoveryFactor - (dMaxNumOfSL-iIMaxNumOfSeqSLForQualify)*1000)-10000;
};
Print("Bars Per Trade (half): ",DoubleToString(dBarsPerTrade,1));
if(dBarsPerTrade > MAX_BARS_PER_TRADE)
{
Print("Слишком редкие трейды !");
return(dRecoveryFactor - dBarsPerTrade/100);
};
Print("Profit: ",DoubleToString(dProfit,3));
Print("Profit per day: ",DoubleToString(dProfitPerDay,3));
Print("Число СЛ: ",IntegerToString(uiTotalNumberOfSL));
Print("Приемлемая торговля.");
return(dRecoveryFactor + (1-(uiTotalNumberOfSL/dNumOfTrades))*100);
};
Aquí se basa en el factor de recuperación, pero destaca las ejecuciones con un número mínimo de SLs sucesivos y con operaciones bastante frecuentes.
Sin embargo, tal y como yo lo veo, la mayoría utiliza las opciones estándar.