Seus símbolos e seus dados no Metatrader 5 - página 11

Novo comentário
 

Acrescentarei outra função de teste contendo dois planaltos pares de valores máximos:

z = abs(tanh(x) + tanh(y))

z = abs(tanh(x) + tanh(y))

Se você mudar X,Y de -20 para +20 com o passo 0,1, a iteração completa leva 160801 iterações.

No teste, ambos os platôs são vistos em 1400 iterações, o que representa menos de um por cento da busca completa.

Alguém vai administrar isto na GA? Interessante para comparar.

 
event:

Acrescentarei outra função de teste contendo dois planaltos pares de valores máximos:

z = abs(tanh(x) + tanh(y))

Se você mudar X,Y de -20 para +20 com o passo 0,1, a iteração completa leva 160801 iterações.

No teste, ambos os platôs são vistos em 1400 iterações, o que representa menos de um por cento da busca completa.

Alguém vai administrar isto na GA? Interessante para comparar.

Você não está olhando com a GA?

Trabalhar com dois argumentos de uma função otimizada não é de modo algum indicativo. Não apenas porque o espaço de busca é pequeno, mas também porque as "más" propriedades do próprio algoritmo de busca podem aparecer.

Converta a fórmula para uma forma com pelo menos 10 argumentos e todas as propriedades positivas e negativas do algoritmo aparecerão.

 
joo:

Você não está procurando com ACs?

Trabalhar com dois argumentos de uma função otimizada não é de modo algum indicativo. Não apenas porque o espaço de busca é pequeno, mas também porque as "más" propriedades do próprio algoritmo de busca podem aparecer.

Converter a fórmula em uma forma que seria pelo menos 10 argumentos - todas as propriedades positivas e negativas do algoritmo aparecerão de uma só vez.

Isto não é GA, há um link para o artigo na linha.

Acima publiquei um exemplo com seis parâmetros. Toda a dificuldade de exibir muitos parâmetros.

Se você sugerir uma função com mais parâmetros - eu farei um teste.

 
event:

Se você sugerir uma função com mais parâmetros - eu farei um teste.

Y=a+b;

onde:

a=Skin(x1, y1)+Skin(x2, y2)+Skin(x3, y3)+Skin(x4, y4)+Skin(x5, y5);

b=Skin(x6, y6)+Skin(x7, y7)+Skin(x8, y8)+Skin(x9, y9)+Skin(x10, y10);

Você já sabe onde procurar a função de pele.

Portanto, existem 20 variáveis, e a função Y é muito fácil de visualizar. Você pode usar este princípio para construir uma função com um número ilimitado de argumentos, mas ainda assim ser capaz de visualizá-la.

E, portanto, o resultado final é verificado como Y*2/n em relação ao valor conhecido do extremo, onde n é o número total de argumentos.

 
Laryx:

E você pode me dar um exemplo de um algoritmo onde em uma "subviragem" uma completa sobreviragem é em uma dúzia de horas e em MT são meses?

Também é realista ter uma busca completa mais rápida do que a otimização heurística. Um ataque de força bruta completo na MT é representado como um conjunto de corridas independentes. De fato, é sempre possível considerar a otimização como um único problema computacional e aplicar a ela a otimização algorítmica.

Nesta abordagem, a seqüência de passes é de grande importância, pois quase todos os cálculos são armazenados em cache. Para quase todos os parâmetros de entrada (todos independentes) do TC há sempre buffers globais no otimizador que armazenam valores de passagens anteriores.

Por exemplo, você usa o MA MA e o PriceChannel. Para cada um desses indicadores têm seus próprios parâmetros de entrada independentes. É por isso que para cada indicador que prescrevemos (algumas linhas na verdade, com OOP deveria ser ainda mais bonito) a função de preencher seu buffer global. Depois comparamos a intensidade de recursos de cada indicador (PriceChannel é mais pesado que MA). Os parâmetros de entrada dos indicadores mais pesados começam a ser enumerados no laço externo (primeiro para), os simples - no laço interno (no aninhado para).

É aqui que obtemos um enorme ganho. Além disso, há C++, cálculos inteiros e nosso próprio sistema de pedidos sem verificações desnecessárias. É assim que se obtém o resultado. Como resultado, as corridas simples são pelo menos uma ordem de magnitude mais rápida do que a MT. E a otimização é ordens de magnitude mais rápida.

O que falta no MT-optimizador é a função OnOptimization que proporcionaria acesso total à matriz obtida de resultados de otimização. Lá realizo várias análises da matriz obtida: filtragem, combinação de passes de uma ordem que não se sobrepõem pelo tempo de troca, etc. Mas o que é ainda mais útil é o cálculo de coeficientes de peso para cada um dos passes para compor uma meta-TS na forma de uma carteira apropriada. OnOptimização tem um vetor-Equidade para cada um dos passes não "sem esperança" para este fim.

Mas o sub-teste não é inventado na fase de busca de um TS em funcionamento, mas quando já foi encontrado, infelizmente. A busca em si é uma etapa completamente diferente: sem uma descrição.
 
event:

Alguém vai dirigir isto na GA? Interessante para comparar.

 
joo:

Y=a+b;

onde:

a=Skin(x1, y1)+Skin(x2, y2)+Skin(x3, y3)+Skin(x4, y4)+Skin(x5, y5);

b=Skin(x6, y6)+Skin(x7, y7)+Skin(x8, y8)+Skin(x9, y9)+Skin(x10, y10);

Você já sabe onde procurar a função de pele.

Portanto, existem 20 variáveis, e a função Y é muito fácil de visualizar. Você pode usar este princípio para construir uma função com um número ilimitado de argumentos, mas ainda assim ser capaz de visualizá-la.

E, portanto, o resultado final é verificado como Y*2/n em relação ao valor conhecido do extremo, onde n é o número total de argumentos.

coisa assustadora...)) E você pode explicar como"a função Y é muito fácil de visualizar"?
 
Serj_Che:
Quantos passes e em que passo variável é o cálculo?
 
event:
Quantos passes e com que passo das variáveis é o cálculo?

Quem se importa se você não gosta da foto?

O GA de 64 bits em MT5 é muito bom, resolve qualquer problema, o principal é formular o problema corretamente.

Eu não sei de que tipo de nerd você está falando neste tópico sobre a GA.

Não acho que o problema seja com a AG, mas o próprio testador é inútil, especialmente na troca por causa de citações erradas, armazenamento de histórico e impossibilidade de salvar o próprio histórico.

Espero que este problema seja resolvido, mas receio ter que esperar de 3 a 5 anos.

 
zaskok:

Por exemplo, você usa o MA e o PriceChannel. Cada um desses indicadores tem seus próprios parâmetros de entrada independentes. Portanto, para cada indicador há uma função escrita (algumas linhas na verdade, com OOP deve ser ainda mais bonita) que preenche seu correspondente buffer global. Depois comparamos a intensidade de recursos de cada indicador (PriceChannel é mais pesado que MA). Os parâmetros de entrada dos indicadores mais pesados começam a ser enumerados no laço externo (primeiro para), os simples - no laço interno (no aninhado para).

Algo me diz que esta abordagem também poderia ser feita facilmente no âmbito da AG. A quantidade de trabalho é praticamente a mesma. O "laço interno" está passando em cada passagem.

Mas, o mais importante - quanta demanda isso seria? Como eu suspeito, nem todos usam até mesmo a simples função OnTester() personalizada. Mas esta é uma ferramenta de otimização muito poderosa.

Aqui, por exemplo, é uma de minhas implementações:

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);
};

Aqui ele se baseia no fator de recuperação, mas destaca as execuções com um número mínimo de SLs sucessivos e com negócios bastante freqüentes.

Entretanto, do meu ponto de vista - a maioria utiliza as opções padrão.

1...456789101112131415161718...26
Novo comentário