Optimisation in the Strategy Tester - page 10

New comment
 

In the latest builds we've gotten rid of system overheads on task runs completely, reducing them from almost 2000 ms to zero.

Here are the results of running a calculation task, which was suggested by joo:

input double   x1=0.0;
input double   x2=0.0;
double OnTester()
  {
   return
   (
    pow(cos((double)(2*x1*x1))-0.11 e1,0.2 e1)+
    pow(sin(0.5 e0 *(double) x1)-0.12 e1,0.2 e1) -
    pow(cos((double)(2*x2*x2))-0.11 e1,0.2 e1)+
    pow(sin(0.5 e0 *(double) x2)-0.12 e1,0.2 e1)
    );
  }

Settings (the dates are set on purpose so that the chart history is not used):

Parameters to be run:

Agents used (4 local agents):

Optimisation results:

Optimisation took only 25 seconds, 18,432 passes were made:



Overall result: MetaTrader 5 and its network of agents can be used for massive mathematical calculations.

 
Renat:

In the latest builds, we've gotten rid of system overheads on task runs completely, reducing them from almost 2000 ms to zero.

Here are the results of running a calculation task, which was suggested by joo:

Settings (the dates are set on purpose so that the chart history is not used):

Parameters to be run:

Agents in use (4 local agents):

Optimisation results:

Optimisation took only 25 seconds and 18,432 passes were made:

The overall result: MetaTrader 5 and its network of agents can be used for massive mathematical calculations.

This is a very good result. Now the optimizer is really more or less suitable for optimization tasks (both trading and non-trading related). The results will be even better if the number of passes will be reduced to 2-3 thousands for this specific task with default optimizer GA settings, but for this you need to display GA settings for user access (it will be possible to reduce number of passes to 500-900 if user wants).

There remains a problem related to the limitation on the search space. A corresponding optimiser proposal has been made in servicedesk.

 
joo:

This is a very good result. Now the optimizer is really more or less suitable for optimization tasks (both trading and non-trading related directly). Even better results would be if the number of passes would be reduced to 2-3 thousand for this specific task with default GA settings of optimizer, but for this you need to make GA settings available to user (it will be possible to reduce number of passes to 500-900 if user wants).

There remains a problem related to the limitation on the search space. A corresponding optimiser proposal has been made in the service desk.

And the solution to this problem is primarily related to this problem:

If optimization pass overflow happens already on 4 parameters, then talking about increasing the number of parameters more than allowed now (64) is not appropriate yet.

 
Urain:

And the solution to this problem is primarily linked to this problem:

If optimization overflow happens already on 4 parameters, then talk about increasing number of parameters more than allowed now (64) is not appropriate yet.

Of course. Roughly, search space is P=n*step, where n-number of parameters to optimize and step-step of parameter. At the same time, P should be smaller than Pmax (maximum possible search space, limited by features of binary coding of chromosome). Therefore, one of artificially introduced restrictions (for example, you can make a limit of 10000 parameters, but then the step will be more than necessary to solve most optimization problems), so that P would not exceed Pmax, was introduced a restriction on n.

Thoughts on this are voiced in proposal for optimizer in servicedesk.


PS With the growth of remote agent networks the problem of high number of runs is coming to naught. But, of course, only if binary chromosome coding limitations are removed (read - switch to chromosome coding with real numbers).

 
joo:

Of course. Roughly, search space is P=n*step, where n-number of parameters to be optimized and step-step of parameter. Thus, P should be smaller than Pmax (maximum possible search space, limited by features of binary coding of chromosome). Therefore, one of restrictions, artificially introduced (for example, you can make a limit of 10000 parameters, but then the step will be more than necessary to solve most optimization problems), that P would not go over Pmax, was introduced a limit on n.

Thoughts on this are given in the optimizer proposal in Service Desk.


PS As networks of remote agents grow, the problem of large numbers of runs goes away. But of course, only if binary chromosome coding restrictions are removed (read: switch to chromosome coding with real numbers).

Slightly wrong, the correct number of variants is P=step_0*step_1*...*step_n

which, if the step size is equal, results in P=step^n

 
Urain:

Slightly wrong, the correct number of choices is P=step_0*step_1*...*step_n

which, if the step size is equal, results in P=step^n

Well, yes, you're right, I'm just saying - roughly, to be clearer and more evident, what depends on what.
 
Renat:

In the latest builds, we've completely eliminated system overheads at task startup, reducing them from almost 2000 ms to zero.

Fantastic! Eh, how much time was wasted over the summer on optimization...

First things first. Ran the test by joo on current build and on build 319 (02 Sep 2010). results:

2010 12/229 15:49:18 Tester passed in 2 minutes 41 seconds
2010.12.29 15:49:18 Tester optimization finished on pass 15360 (of 100000020000001)
2010.12.29 15:49:18 Tester result cache was used 7265 times
2010.12.29 15:49:13 Tester genetics is over
2010.12.29 17:10:59 Tester optimization passed in 1 hours 17 minutes 34 seconds
2010.12.29 17:10:59 Tester genetics optimization finished on pass 18176 (of 100000020000001)
2010.12.29 17:10:59 Tester result cache was used 10582 times
2010.12.29 17:10:52 Tester genetics is over

I don`t even know whether to congratulate or thank. Thank you!

 
Urain:

And the solution to this problem has to do with this problem in the first place:

If the overflow of optimization passes occurs already on 4 parameters, then talking about increasing the number of parameters more than allowed now (64) is not appropriate yet.

Use reasonable approach to search, but do not turn knobs to maximum in "Russian men break Japanese chainsaw" mode.

As soon as you start applying genetic optimisation in real work, you will immediately start choosing reasonable limits.

 
Yedelkin:

Fantastic! Eh, how much time was wasted over the summer on optimisation...

In order. I have tested it on current build and on 319th build (02 Sep 2010):

2010.12.29 15:49:18 Tester optimization passed in 2 minutes 41 seconds
2010.12.29 15:49:18 Tester genetic optimization finished on pass 15360 (of 100000020000001)
2010.12.29 15:49:18 Tester result cache was used 7265 times
2010.12.29 15:49:13 Tester genetics is over
2010.12.29 17:10:59 Tester optimization passed in 1 hours 17 minutes 34 seconds
2010.12.29 17:10:59 Tester genetics finished on pass 18176 (of 100000020000001)
2010.12.29 17:10:59 Tester result cache was used 10582 times
2010.12.29 17:10:52 Tester genetics is over

I don't know whether to congratulate or thank. Thank you!

Note that we've reduced system overhead on "sync/transmit initial data from terminal to agent and receive results from agent" phases, which resulted in saving 1.5-2 seconds per run. There was no acceleration of calculations in the language itself.

That is, the most serious effect this has is on high-speed calculations, where the calculation takes close to zero time. For massive calculations savings are not so pronounced. Although a saving of 2 seconds per 10,000 runs gives 20,000 sec = 333 minutes = 5.5 hours.

 
Renat:
It does not.

I have noticed that it has an effect. I ran the EA on weekdays and ran it with extended spread now, the result is quite different, spread is about 4 pips (four digits) on Eurobuck now. So there is some spread jam on weekend in mt5 too, so I don't want to run it at weekend, because optimisation will not be correct. I can even see it visually in mt4 where an EA has been optimizing since Monday and the results curve has gone down since weekend; it proves that the spread affects the optimization results, they have become worse.

1...34567891011121314151617...19
New comment
Reason: