Errors, bugs, questions - page 212
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
Yes, that's right, only in the form of standard functions to optimize the access speed.
I don't think we can talk about speed yet, especially since MQL5 processes the existing array of news data quickly. And that's with the hope that MQL will be even faster.
But I would like to elaborate on this subject. I'm wondering what are you planning to do with this data afterwards?
I don't think we can talk about speed yet, especially since MQL5 processes the existing array of news data quickly. And here's hoping that MQL will be even faster.
But I would like to elaborate on this. I wonder what they plan to do with this data? concrete examples of use?
And what's next is a hot field, the news was not available normally before, and then the coding of news strategies will boom.
I'm planning to use it all through the NS committees, but I would like to develop the subject further.
ZZZY But as long as the news in the tester will not appear (ie, news stories), it will have to do through files, and parser news on third-party resources.
The tester slows down as the number of trades increases.
When opening trades with the intensity of about 1 trade per 2 minutes you can see (Log tab) that 1 second of testing time by the end of quite a long period has several times less trades than at the beginning of the test. Similar picture when outputting test results in Open XML format.
Actually, testing time does not directly depend on the amount of trades. To be exact, a single run with 10 trades will of course take less time than a run with 100 000 trades because each trade in the tester needs time for processing.
But it is the number of ticks being processed in a pass that affects the testing time the most. I have run the standard Moving Average in all ticks mode starting from one month (interval 2009.01.01-2009.02.01) and increased the testing time by one month each time to 22 months.
As you can see from the diagram the dependence of testing time on the number of ticks is strictly linear.
Hello, reflect the addition of the construct
#property tester_indicator "indicator.ex5"
in the documentation, in the description of the iCustom function. I have spent a few hours trying to understand the reason why iCustom works in the chart, but does not work in the tester.
This is described in the programme properties section.
tester_indicator
string
Name of the custom indicator in the format "indicator_name.ex5" .Indicators necessary for testing are determined automatically from iCustom() function call, if the corresponding parameter is specified as a constant string. For other cases (use of the IndicatorCreate() function or use of a non-constant string in the parameter that defines the indicator name) we need this property
tester_file
string
File name for the tester, specifying its extension, enclosed in double quotes (as a constant string). The file specified will be passed to the tester for operation. Input files for testing, if needed, must always be specified
tester_library
string
Library name with extension, enclosed in double quotes. A library may have both a dll extension and an ex5 extension. The libraries needed for testing are detected automatically. However, if a library is used by a custom indicator, one should use this property
But you are right, you need to explicitly add information about it again in the relevant places.
Actually, the testing time does not directly depend on the number of trades. To be exact, a single run with 10 trades will of course take less time than a run with 100 000 trades because each trade in the tester needs time to be processed.
But it is the number of ticks being processed in a pass that affects the testing time the most. I have run the standard Moving Average in all ticks mode starting from one month (interval 2009.01.01-2009.02.01) and increased the testing time by one month each time to 22 months.
As is seen from the diagram, the dependence of testing time on the number of ticks is strictly linear.
Probably, I should read "a single run with 10 trades will of course take LESS time than a run with 100 000 trades because each trade in the tester needs time to be processed.
I agree about the ticks. But pay attention exactly to the number of deals - the time growth there is obviously not linear, and forming a testing report is completely out of the question!
What is the maximum time that can be set in EventSetTimer( )?
INT_MAX? I don't think so. I don't want to investigate on my own, and there's none in the help.
Probably should read "a single run with 10 trades will of course take LESS time than a run with 100,000 trades, as each trade in the tester takes time to process.
I agree about the ticks. But once again please pay attention to the number of trades - the time growth there is clearly not linear, and the formation of the test report is completely out of the question!
In the process of testing, a few questions arose, I show pictures taken at the same time:
As can be seen from the figure, only three cores are working, faced more than once a situation where in the course of testing, the number of cores involved in the work gradually dropped to zero, then came into operation all at once, that is, there is downtime, why freed cores do not start working immediately?
The number of runs is defined as 287, the optimization results show it that way, however:
what do these numbers mean then? The number of points in the optimization graph is also about 381...