Your symbols and your datafeeds in Metatrader 5 - page 11

New comment
 

I will add another test function containing two even plateaus of maximum values:

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

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

If you change X,Y from -20 to +20 with step 0.1, the complete iteration takes 160801 iterations.

In the test, both plateaus are seen in 1400 iterations, which is less than one percent of the complete search.

Will anyone run this on GA? Interesting to compare.

 
event:

I will add another test function containing two even plateaus of maximum values:

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

If you change X,Y from -20 to +20 with step 0.1, the complete iteration takes 160801 iterations.

In the test, both plateaus are seen in 1400 iterations, which is less than one percent of the complete search.

Will anyone run this on GA? Interesting to compare.

Aren't you looking with GA?

Working with two arguments of an optimised function is not indicative at all. Not only because the search space is small, but also because the "bad" properties of the search algorithm itself can appear.

Convert the formula to a form with at least 10 arguments and all the positive and negative properties of the algorithm will show up.

 
joo:

Aren't you looking with GAs?

Working with two arguments of an optimized function is not indicative at all. Not only because the search space is small, but also because the "bad" properties of the search algorithm itself can appear.

Convert the formula to a form that would be at least 10 arguments - all the positive and negative properties of the algorithm will appear at once.

This is not GA, there is a link to the article in the thread.

Above I posted an example with six parameters. The whole difficulty with displaying a lot of parameters.

If you suggest a function with more parameters - I will make a test.

 
event:

If you suggest a function with more parameters - I'll make a test.

Y=a+b;

where:

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

You already know where to look for the Skin function.

So there are 20 variables, and the Y function is very easy to visualise. You can use this principle to build a function with an unlimited number of arguments, but still be able to visualize it.

And accordingly, the final result is checked as Y*2/n against the known value of the extremum, where n is the total number of arguments.

 
Laryx:

And can you give me an example of an algorithm where in a "understeer" a complete oversteer is in a dozen hours and in MT it is months ?

It is also realistic to have a complete search faster than the optimization heuristic. A complete brute force attack in MT is represented as a set of independent runs. In fact it is always possible to consider optimization as one single computational problem and apply algorithmic optimization to it.

In this approach the sequence of passes is of great importance as almost all calculations are cached. For almost every (all independent) input parameter of TC there are always global buffers in optimizer that store values of previous passes.

For example, you use the MA MA and PriceChannel. For each of these indicators have their own independent input parameters. This is why for each indicator we prescribe (a few lines actually, with OOP it should be even more beautiful) the function to fill its global buffer. Then we compare the resource intensity of each indicator (PriceChannel is heavier than MA). The input parameters of the heavier indicators begin to be enumerated in the external loop (first for), the simple ones - in the internal loop (in nested for).

This is where we get a huge gain. Plus, there is C++, integer calculations and our own order system without unnecessary checks. That's how you get the result. As a result, single runs are at least an order of magnitude faster than MT. And the optimization is orders of magnitude faster.

What is missing in the MT-optimizer is the OnOptimization function that would provide full access to the obtained matrix of optimization results. There I perform various analyses of the obtained matrix: filtering, combining passes of an order that do not overlap by trade time, etc. But what is even more useful is calculation of weight coefficients for each of the passes to compose a meta-TS in the form of an appropriate portfolio. OnOptimization has a vector-Equity for each of the non-"hopeless" passes for this purpose.

But the under-tester is not invented at the stage of searching for a working TS, but when it has already been found, unfortunately. The search itself is a completely different stage: without a description.
 
event:

Will someone run this on GA? Interesting to compare.

 
joo:

Y=a+b;

where:

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

You already know where to look for the Skin function.

So there are 20 variables, and the Y function is very easy to visualise. You can use this principle to build a function with an unlimited number of arguments, but still be able to visualize it.

And accordingly, the final result is checked as Y*2/n against the known value of the extremum, where n is the total number of arguments.

scary thing...)) And can you explain how"function Y is very easy to visualize"?
 
Serj_Che:
How many passes and at what variable pitch is the calculation?
 
event:
How many passes and with what step of variables is the calculation?

Who cares if you don't like the picture?

64 bit GA in MT5 is very good, it solves any problem, the main thing is to formulate the problem correctly.

I don't know what kind of a nerd you are talking about in this thread about GA.

I don't think that the problem is with the GA, but the tester itself is useless, especially at the exchange because of wrong quotes history storage and impossibility to save own history.

I hope this problem will be solved, but I'm afraid I have to wait for 3-5 years.

 
zaskok:

For example, you use the MA and PriceChannel. Each of these indicators has its own independent input parameters. Therefore, for each indicator there is a written (a few lines actually, with OOP it must be even more beautiful) function that fills its corresponding global buffer. Then we compare the resource intensity of each indicator (PriceChannel is heavier than MA). The input parameters of the heavier indicators begin to be enumerated on the external loop (first for), the simple ones - on the internal loop (in the nested for).

Something tells me that this approach could easily be done under GA as well. The amount of work is about the same. The "inner loop" is reworked on every pass...

But, most importantly - how much demand would that be ? As I suspect, not everybody uses even simple custom OnTester() function. But this is a very powerful optimization tool.

Here, for example, is one of my implementation:

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

Here it is based on the recovery factor, but it highlights runs with a minimum number of successive SLs and with quite frequent trades.

However, the way I see it - most use the standard options.

1...456789101112131415161718...26
New comment