Errors, bugs, questions - page 739

[Mykola Demko]

ivandurak:

Optimise by bit fields, there will be no unnecessary passes in this variant.

For example:

input int bp=0;
int a=0;
int b=0;
Start()
{
 switch(bp)
   {
    case 0: a=0; b=0; break;
    case 1: a=0; b=1; break;
    case 2: a=1; b=0; break;
    default: a=1; b=1; break;    
   }
}

and optimise in given parameters, for this example bp is optimised from 0 to 3

[Yedelkin]

ivandurak:
Only you forgot to write the verdict whether you can or cannot.

I haven't forgotten anything :) If I had known exactly how to do it, I would have told you. It is a bit presumptuous to give a negative verdict, because not knowing the solution does not mean there is no solution.

[Alexey]

I get the idea. I wonder if genetics will go crazy from such a trick. It turns out that in principle a working set of parameters gives zero result and is not involved in further selection. Imho better in the wishes of methaqvoters write something like related optimizable parameters, if it is false, then it should not be overridden.

[Anatoli Kazharski]

Yedelkin:

How can it be "easier"? :) The conditions for deleting an EA or for REASON_INITFAILED still have to be tracked. This is what looks like a hassle.

If there is no elegant solution, you can first use the one that is "easier". Find something better, you can always replace it. :)

[Yedelkin]

ivandurak:
It turns out that, in principle, a working set of parameters yields zero results and is not involved in further selection.

Not really, if we are talking about my torturous idea. With "working set of parameters" and first trpar2=false pass will give quite working result. All subsequent passes with the same "working set of parameters" and trpar2=false will immediately return zero, but your "working set of parameters" will take part in selection anyway and duplicated passes will be rejected. This is what you wanted, isn't it?

[Yedelkin]

tol64:
In the absence of an elegant solution, you can use the 'easier' one first. If something better is found, it can always be replaced. :)

Once again: the hassle is not which command to finish the pass early - it's quite primitive solution, whatever it is. Botherness - in tracking conditions for early completion of the passage. From the fact that the passage will be completed ahead of time with the help of your proposal, the "tracking block" itself is not reduced, and the elegance of this block is not increased in any way.

[Alexey]

Yedelkin:
Not really, if you're talking about my torturous idea. With "working set of parameters" and first trpar2=false the pass will give quite working result. All other passes with the same "working set of parameters" and trpar2=false will immediately return zero, but your "working set of parameters" will take part in selection anyway. This is what you wanted, isn't it?

You can correct it a bit. The optimization parameters should be written in structures, and they (simple structures) should be treated as variables. The code should read

if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par; Parold2=Par2 ; return(9) } Here Par and Parold are structures into which optimal parameters from other currency pairs are written. As many pairs as there are ifs, it doesn't look so ugly. Thank you.

[Anatoli Kazharski]

Yedelkin:
Once again: hassle is not about which command to terminate the pass early - this is a rather primitive solution, whatever it may be. The bother is in keeping track of the conditions for completing the pass early. The fact that passage will be completed ahead of time with the help of your suggestion, "tracking unit" itself isn't less bothersome, and elegance of this unit is not increased in any way.

So what did you mean by that? That in the absence of an elegant solution, you should not use any at all? Even if there is one, but, as you put it, "painful"?

In short, let's move on. Otherwise it's more bothersome from flooding than from code. :)

[Yedelkin]

ivandurak:

You can correct it a bit. Optimisation parameters should be written to structures, and they (simple structures) should be treated as variables. The code should read

if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par; Parold2=Par2 ; return(9) } Here Par and Parold are structures into which optimal parameters from other currency pairs are written.

Yes, something like that. It just turns out that we'll have to remember ALL "working sets of parameters" that collided with trpar2=false. I.e. array of corresponding structures would expand immensely. Besides it will have to be saved in file to read remembered at new pass.

[Anatoli Kazharski]

ivandurak:

You can correct it a bit. Optimisation parameters should be written to structures, and they (simple structures) should be treated as variables. The code should read

if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par; Parold2=Par2 ; return(9) } Here Par and Parold are structures into which optimal parameters from other currency pairs are written. As many pairs as there are ifs, it doesn't look so ugly. Thank you.

There is one more variant (it slipped my mind).

You may have a look at the functions: OnTesterInit(), OnTesterPass(), OnTesterDeinit().

And FrameFirst (),FrameFilter (),FrameNext (),FrameInputs (),FrameAdd().

That's exactly what they're for. :)

That is, you can always request all parameters of any pass in the current optimization at any time.