How do I check whether 'Optimisation' or 'Forward Optimisation' is in progress? - page 8

New comment
 
Stanislav Korotky:
I have done a similar check indirectly. The first trade is always a top up (it is the same on all runs). Therefore, I memorized HistoryDealGetInteger(ticket, DEAL_TIME) for the first trade in OnTester and wrote it into the frame. By this value, we can divide the entire set of runs inOnTesterPass into back and forward. If possible, pass the values for the required calculations from OnTester to OnTesterPass, while the calculation itself is already performed in OnTesterPass.
If we get a single array of trades for the run, we can catch the first one - the back deposit by the balance amount and the second forward deposit by the same amount. The probability that the result of all trades up to the forward part will be equal to the same round amount is vanishingly small.
 
Dmitry Fedoseev:
Yes. So, we should take out "forward" option from ini and check the tester's mode of operation - simple testing or optimization. So that the function will only trigger at simple testing and when forward is selected?

Forward = Custom, Optimization = Disabled, OnTester #2 (they also advise to throw in a testerPass, apparently, to work in peace) and write profitability in the file with regression.

I just suspect that OnTester #2 occurs only in this case and in the case of optimization with forward. But I never use it and just

regression to the file through OnTester #2.

 
Youri Tarshecki:
It is not possible to programmatically define the boundary between this and that.

It's too late to notice this topic. I have a solution. I was recently messing around with a visual tool for back+forward testing. I realized that it is impossible to determine programmatically, but pass numbers of back and forward runs coincide.

Therefore, the arrival time of the first frame from forward run can easily be found in the pool of saved pass numbers.

The time of IN/OUT transaction can also be fixed. There is a picture in the profile where the moment of forward run is dotted - it is determined by fact.

 
Youri Tarshecki:
the pool itself).
Pool = array. You take it and make it.
 
Igor Volodin:

It's too late to notice this topic. I have a solution. I was recently messing around with a visual tool for back+forward testing. I realized that it is impossible to determine programmatically, but pass numbers of back and forward runs coincide.

Therefore, the arrival time of the first frame from forward run can easily be found in the pool of saved pass numbers.

The time of IN/OUT transaction can also be fixed. There is a picture in the profile where the moment of forward is dotted - it is determined by the fact

OFFTOP. (I think it is already possible, the topic starter has got three variants of indirect methods ). And can you visually align on this point in the picture and combine many different back-and-forth runs?
 

they are combined . forward in the optimiser was selected = 1/2 period, which can be seen in the graph. in datagrid one of the combined runs is selected, its line can be seen in the graph

 
Igor Volodin:

they are combined . forward in optimizer was selected = 1/2 period, which can be seen on the graph. in datagrid one of the combined runs is selected, its line can be seen on the graph

This is alignment to the initial back deposit. And by the initial deposit of the forwards can you? The forwards should start at the same point so you can see the winner in the forward.
 
Youri Tarshecki:
This is an alignment on the initial deposit of the back. And by initial forward deposit can you?

Got it. Here the abscissa axis corresponds to linear time increment. But I don't see a problem to overlay. Only the initial deposit will be different. Forwards = total back period.
But if we take profit increment graphs and take zero as a basis, it will be from the same point.

P.s. Only for me personally, the usefulness of such a graph is questionable

 
Igor Volodin:
Got it. The abscissa axis here corresponds to linear time increments. But I don't see a problem with overlaying it. Only the initial deposit will be different. Forwards = total back period.
But if we take profit increment graphs and take zero as a basis, it will be from the same point.

I think the back's starting deposit can be sacrificed - everyone understands that it is a convention anyway. The main thing is that all forwards should have the same starting deposit.

I mean that the vogue for wolfing forwards is not far off and they should already have some kind of unified standard image.

I like that the timeline is the same for everyone - you can feel the relative density of trades immediately.

 
Igor Volodin:

It's too late to notice this topic. I have a solution. I was recently messing around with a visual tool for back+forward testing. I realized that it is impossible to determine programmatically, but pass numbers of back and forward runs coincide.

Therefore, the arrival time of the first frame from forward run can easily be found in the pool of saved pass numbers.

The time of IN/OUT transaction can also be fixed. There is a picture in the profile where the moment of forward is dotted - it is determined by the fact

Where do I get this number?
1234567891011
New comment