Not for MT developers! What to replace INIT_PARAMETERS_INCORRECT with ? - page 2

 

You can create your own optimization set in OnTesterInit and make the optimizer think that only one sinput int NumPass is being optimized.

It is hard to say what effect this will have on the final result - whether the desired global (local) extremum will be found.

I am not ready to provide you with an example, have a look at the Documentation. It is well written there.

 
fxsaber:

One recipe is for developers to have the result of INCORRECT passes counted as the nearest CORRECT pass previously counted. This will even out the holes in the optimization surface.

This is what developers are against. In this case, other individuals in the population will "survive". And the genetics will start to work with errors.

 

How about writing a function that only outputs valid chains by number ?

The first thing that comes to mind is a table of 117649 values, and let genetics look for numbers in that table.

 
Sergey Savinkin:

This is what the developers are against. In this case, other individuals in the population will 'survive'. And the genetics will start to malfunction.

I would also be against such an algorithm. INCORRECT is an unacceptable set of parameters, it cannot be replaced by the "nearest acceptable" one.

 
Sergey Savinkin:

This is what the developers are against. In this case, other individuals in the population will 'survive'. And genetics will start to work in error.

Genetics in practice is almost always wrong, which is the norm. Without proper research in this area, I would not claim anything on the proposed option.

 
Georgiy Merts:

How about a function that returns only valid chains by number ?

The first thing that comes to mind is a table of 117649 values and let genetics look for numbers in that table.

Forum on trading, automated trading systems & strategy testing

Not for MT Developers! What to replace INIT_PARAMETERS_INCORRECT with ?

fxsaber, 2018.07.10 16:22

You can create your optimization set in OnTesterInit and make the optimizer think that only one sinput int NumPass is being optimized.

It is difficult to say what effect this will have on the final result - whether the required global (local) extremum will be found.

It strongly depends on the criterion of satisfaction with the final result.


It is evident that if we follow the complete enumeration of y = x^2. Then randomly shuffle the rows and create a new set based on the shuffling. Then GA will not find the vertex of the parabola.

 
fxsaber:

Obviously, if you trace a full enumeration of y = x^2. Then randomly shuffle the opimization strings and create a new set based on the shuffling. The GA will not find the vertex of the parabola.

Yes, here it turns out that these very INCORRECTs "tear up" the fitness function space too much.

I'm afraid there is nothing to do except redesign the input parameters. Skipping OnTick() as you suggest is just a crutch replacing INCORRECT parameter, in reality genetic algorithm will be "killed" anyway. Genetics requires some "gradients" of result function, so we can use them to move to the maxima. But when you have more INCORRECTs than valid values - how do you find this maximum?

I suspect that except for full brute force you can't do anything, and even full brute force will find a highly unstable solution.
 

It takes a bit of skill to set the input parameters.

A very common example can be given. When optimising the daily trading interval, the daily start and end times are the most common two input parameters.

But this is much worse for GA than, for example, specifying start time and duration. Seemingly the same thing, but not for the GA. In the second case, the GA would do better. Although 'better' is a rather subjective assessment.

 

Georgiy Merts:

when we have more INCORRECTs than valid values - how do you find this maximum?

Let's take the same parabola as above. Suppose we make INCORRECT on testing interval 90% of value of single input parameter. The current GA will crash on such a task. However, if you proceed with the suggested option, the GA will do fine.


I think @Andrey Dik can help on these questions. But even constructive criticism of the regular GA didn't end well for him...

 
fxsaber:

Take the same parabola as above. Suppose we make INCORRECT on the test interval 90% of the value of the single input parameter. The current GA would die on such a task. However, if you proceed with the suggested variant, the GA will do fine.

How? By replacing incorrects with the nearest corrections ??? I'm afraid it all depends on how we distribute these very incorrections. It is quite possible that the nearest corrections - will be away from the top.

Yes, and it will turn out that instead of wrong sets of parameters - we will have correct results - which also, in my opinion, should not be done - what do we find then ? We'll get a maximum and it will have an incorrect set of parameters ?

Reason: