Errors, bugs, questions - page 2438
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
2. one type of frames is read in OnTesterPass, finished in OnTesterDeinit. Other frames are read in OnTesterDeinit
This feature does not allow us to work in real time with the results of calculated passes if there are several frames per pass.
Forum on trading, automated trading systems & strategy testing
Testing of Strategy Timetables with Autosubstitution of Results in EAs
Slava, 2013.04.10 15:04
1. Yes. May be redundant.
2. one type of frames is read in OnTesterPass and finished in OnTesterDeinit. The remaining frames are read in OnTesterDeinit
This ability to transmit-receive several types of frames allowed us to correct some hard-to-reproduce errors in the tester. And frames were transmitted only if there was a difference with some reference value.
Earlier I mentioned loss of frames, if many frames are passed in one pass and there are problems with the agent - connection is broken - will something be done about this situation?
Will you open the opt-format?
Yes.
In exchange for publishing the code to read the opt file
This feature does not allow you to work in real time with the results of counted passes if there are several frames per pass.
Yes.
That's why we have to read frames of "non-core" type after optimization is finished.
Earlier I talked about frame loss, if many frames are transmitted in one pass and there were problems with the agent - a break in communication - will something be done about this situation?
What can you do?
The optimization result will in any case leave earlier and faster than its frame. If the agent has been stalled (computer shutdown, service stopped), there is definitely nothing to be done.
We could try to do the following: until the frame is sent, don't send the result. But it is unknown when we will correct it.
This seems to be a purely methodological flaw
We avoid unnecessary memory reallocation.
In this case there is 99% probability that the array buffer will be allocated once
What can you do?
The result of the optimization will anyway leave earlier and faster than its frame. If the agent has been stalled (computer shutdown, service stopped), there's exactly nothing you can do about it.
We could try the following: until a frame is sent, don't send the result. But it is not known when we will correct it.
Maybe before transmission of frames, you can say how many frames are expected, and if it's less than expected and the agent is unavailable, then give the pass to another agent and overwrite the frames already received?
Or in the body of each frame write the total number and its sequence number in that number, and in the same way, if all did not come, reoptimize.Yes.
In exchange for publishing the code to read the opt file
I'm even more interested in the recording. I'll do the reading, if the format is known.
Can you tell how many frames are expected before you start transmitting, and if less than expected arrived and the agent is unavailable, then give the pass to another agent and overwrite the frames already received?
Or in the body of each frame to write the total number and its sequence number in this quantity, and the same way, if all did not come, re-optimize.What if not every pass returns a frame?
I gave above an example on error catching in the tester. Frames were sent only when some result value did not coincide with the benchmark