Discussion of article "Parallel Particle Swarm Optimization"
Is the uniqueness check and storage of the parameter base justified? Has the algorithm been measured for speed degradation?
In view of the fact that as a rule a huge search space is used during optimisation and the probability of repeated variants is extremely small, and in case of small search spaces it is more rational to make a complete search.
ZЫ Thanks to the author for the ground for thinking.
ZZY I did not quite understand how the question of "soft" loading of agents at a fixed size of the colony (or population) without downtime is solved, while I am rereading the article.
The article shows some not worked out moments from the MT5 side. For example, obtaining values of non-optimised parameters in OnTesterInit without DLL. And the same commission.
It would be great to add to the source code the possibility to enable (via macro) reading of all Tester parameters via DLL. There are ready solutions.
Another wish is generation of opt-file from PSO-passes.
It will be necessary to compare this solution and the standard GA in terms of performance and quality. It shouldn't be difficult for any non-syndicator TC (based on the sources from the article, since it is a universal style).
The article is super! But not for beginners.
Finished reading.
There is too much code for the task of replacing the standard optimiser, too many inclusives, who will understand it? - Unfortunately, for the vast majority of readers the article will remain beyond understanding.
How can you take any Expert Advisor and screw a PSO library to it with minimal effort?
Ideally, the optimisation algorithm should be a completely separate entity, so that you don't have to go into it every time you need to write a new Expert Advisor (any algorithm that you plan to optimise).
Besides, what algorithm settings are acceptable in most practical cases? - The author did not give an answer to this question. And, if the inquisitive mind of the reader wants to optimise the algorithm parameters using the same algorithm, it will not be possible to do it right away, because the code is not isolated.
Please don't consider this a grouch, but there is no ready-to-use tool without code unnecessary for specific tasks.
Finished it.
There is too much code for the task of replacing the standard optimiser, too many inclusives, who will understand it? - Unfortunately, for the vast majority of readers, the article will remain beyond comprehension.
How can you take any Expert Advisor and screw a PSO library to it with minimal effort?
Ideally, the optimisation algorithm should be a completely separate entity, so that you don't have to go into it every time you need to write a new Expert Advisor (any algorithm to be optimised).
Besides, what algorithm settings are acceptable in most practical cases? - The author did not give an answer to this question. And if the inquisitive mind of the reader wants to optimise the parameters of the algorithm with the same algorithm, it will not be possible to do it straight away, because the code is not isolated.
Please don't consider this a grouch, but there is no ready-to-use tool without code unnecessary for specific tasks.
Of course, one cannot embrace the immense. The second iteration of the open source tool has been presented (the first, non-parallelised one was published earlier on the blog). It is ready in the sense that they have already figured out for you where to put the code and how it will work. I agree that there is no product in a box yet. But it would be for sale in the marketplace. What is presented here is a do-it-yourself kit with a ready instruction.
As for the includnics - they were added not from a good life, but because there are no similar in-house ways to do everything the same (and needed). And it's very good that all these routine things are already ready in the form of includniks, which only need to be connected (for which many thanks to fxsaber-u). It is strange to complain on an algo-trading site about the main way to avoid duplication of work. If these includers were not there, we would have had to do the whole project from scratch. And it's better to have includniks than batniks. In general, there are no dependencies on third-party programs and DLLs. And there is no (any) alternative to the built-in optimisation method that can be implemented by small code.
As for tuning PSO parametres, this is an open problem for any optimisation method. In particular, for the built-in GA there are some hardwired settings that users cannot change, and that's why many people complain about this very point, and they have to order custom solutions based on GA from you. So it turns out that the absence of settings is bad, and when they are there, it is also bad, because you gave them to us and now we don't know what to do with them. And what to do with them is this: research for each specific task. Asking for ready settings for some unknown black box, which is someone's expert, is like asking for ideal parameters for this expert (without optimisation). And why do we need optimisation itself then? Because it's not all that simple - neither searching for the parameters of an expert, nor searching for meta-parameters of a particular optimisation algorithm. What you are asking is like asking for a ready-made neural network configuration for data that nobody has seen yet. There are no optimal settings for most expert == practical cases.
As a starting point, we can take the parallel with GAs made in the article: if the user has run the GA 1000 times, let him set the group count to 1000, if there were 100 generations in the GA - let it be 100 PSO cycles, and if there were 100 individuals in the population, let the swarm size be 100 as well.
As for includnics - they are added not from a good life, but because there are no similar standard ways to do all the same (and necessary) things. And it's very good that all these routine things are already available ready-made in the form of includniks, which only need to be connected (thanks to fxsaber for that). It is strange to complain on an algo-trading site about the main way to avoid duplication of work. If these includers were not there, we would have had to do the whole project from scratch. And it's better to have includniks than batniks. In general, there are no dependencies on third-party programs and DLLs. And no (any) alternative to the built-in optimisation method can be implemented by small code.
It makes no sense to duplicate the functionality of the standard tester in the form of virtual trading functions (at least I don't see the point, this work has already been done for us by smart, highly paid guys from MQ), but to make an addition, an extension of functionality - yes.
bolded - maybe, indeed.
As for tuning PSO parametres, that's an open problem for any optimisation method. In particular, for the built-in GA there are some hardwired settings that users cannot change, and that's why many people complain about this very point, and they have to order custom solutions based on GA from you. So it turns out that the absence of settings is bad, and when they are there, it is also bad, because you gave them to us and now we don't know what to do with them. And what to do with them is this: research for each specific task. Asking for ready settings for some unknown black box, which is someone's expert, is like asking for ideal parameters for this expert (without optimisation). And why do we need optimisation itself then? Because it's not all that simple - neither searching for the parameters of an expert, nor searching for meta-parameters of a particular optimisation algorithm. What you are asking is like asking for a ready-made neural network configuration for data that nobody has seen yet. There are no optimal settings for most expert == practical cases.
As a starting point, we can take the parallel with GAs made in the article: if the user has run the GA 1000 times, let him set the group count to 1000, if there were 100 generations in the GA - let it be 100 PSO cycles, and if there were 100 individuals in the population, let the swarm size be 100 as well.
The above said by you says that the work on research of search abilities of the algorithm was not done. ready neural network and optimisation algorithm are not the same, NS requires training on specific data and depends on data purity, completeness and relevance, but the optimisation algorithm should not depend on these factors in any way, it should not care whether to train the neural network (optimise) or to find optimal parameters of itself on a set of test problems.
But! In any case, my comments on the article are purely practical, but not principled. Any points of view on the problem of optimisation have the right to exist. You see it this way, I see it somewhat differently, which is good.
In today's world nobody needs "build it yourself" designers, everybody needs ready-made solutions, Mercedes and other Audis are bought not to be finished but to be enjoyed... or at least a low-blooded way to screw the solution to the customer's existing projects should be presented.
;)
interesting article
I didn't like the implementation - linking virtual trading with the tester,
maybe it works as intended, but imho, the implementation for optimisation should be either completely with the help of virtual trading ( Virtual.mqh ) - then it will be online auto-optimisation,
or implementation using the possibilities of the terminal strategy tester (OnTesterInit()). - we would get an alternative GA for the tester, in the current implementation it is difficult to assume how the strategy tester works.
thanks for the interesting material and software implementation, it may be useful.
I will answer in order.
Remembering hashes of calculated combinations is optional - it can be excluded from the source if desired. The presence of this check should not slow down the process much in comparison with the speed of calculation of the trade itself.
Full parameter enumeration makes sense only for really small spaces, but between them and millions of combinations there is a whole layer of usecases. For example, you need to run optimisation on 10000 combinations, a full search will take 1 hour, but you want to see a rough estimate in a few minutes. In this case, you obviously need a fast way of optimisation, and duplicate combinations are very likely. And by detecting them, we can speed up processing.
The loading of agents is left to the tester. Trade passes are distributed evenly on average (the number is equal and complexity is averaged due to randomisation).
I would like to add opt-files, but I can't manage to do it all at once. If you screw in all the options, the result will never see the light of day.
I would not like to use DLLs and external programmes, so to speak, by design.
Using virtual trading functions makes a lot of sense - they are much faster than built-in ones. This is firstly. Secondly, they allow you to change parameters many times in a loop within one pass (within a PSO group). If it were not for this, each separate pass would have to be synchronised with the group(which has become an external entity in relation to the program ) - and this is still possible, again, either through external programs or through shared files. And there would be new super-brakes. But thirdly and finally, and this is the most important thing: when using regular tester passes without virtualisation, it is impossible to screw your own optimisation algorithm to live inside MQL. Try to think how you would do it. This is possible only with the help of external programmes and/or batnets. fxsaber even has suitable "automatisers", but that means external control over running processes and assembling their results. That's brakes squared, plus totally inconvenient to use. Dealing with these external controllers requires much more skill.
As for the statement about small code for implementing a replacement of the standard optimiser, I would disagree. As far as I know, alternative works are not small either, and require adaptation of expert code. If there is a concrete demonstration on a standalone optimisation algorithm with small code and very simple plugging into EA, share it with the public ; -).
Regarding the optimisation algorithm's indifference, as if it should be able to handle any task without tuning - I don't agree. It would be some kind of magic, a "silver bullet".
I don't see any fundamental difference between the optimisation algorithm and the NS algorithm. Both have meta-parameters.
And yes - "no work was done to investigate the search ability of the algorithm ", because you can't cover a lot of ground - there was already a lot of work to be done. The purpose of the publication is to make it publicly available to those who want to do research and share their findings.
There is auto-optimisation online (it was published in the blog), but it is only in one thread, and the point of the article was to parallelise the algorithm. Using the tester as a job iterator and distributing them to agents for group virtual counting -- that's the biggest trick of the whole project. Synergy.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
New article Parallel Particle Swarm Optimization has been published:
The article describes a method of fast optimization using the particle swarm algorithm. It also presents the method implementation in MQL, which is ready for use both in single-threaded mode inside an Expert Advisor and in a parallel multi-threaded mode as an add-on that runs on local tester agents.
From an algorithmic point of view, the PSO method is relatively simple. The main idea is to generate a set of virtual "particles" in the space of the Expert Advisor's input parameters. The particles then move and change their speed depending on the EA's trading metrics at the corresponding points in space. The process is repeated many times until the performance stops improving. The pseudo-code of the algorithm is shown below:
Particle Swarm Optimization Pseudo-Code
According to this code, each particle has a current position, speed and memory of its "best" point in the past. Here, the "best" point means the point (a set of EA input parameters), where the highest value of the objective function for this particle was achieved. Let us describe this in a class.
The size of all arrays is equal to the dimension of the optimization space, so it is equal to the number of the Expert Advisor parameters being optimized (passed to the constructor). By default, the larger the objective function value, the better the optimization. Therefore, initialize the bestValue field with the minimum possible -DBL_MAX number. One of the trading metrics is usually used as a criterion for evaluating an EA, such as profit, profitability, Sharpe ratio, etc. If optimization is performed by the parameter whose lower values are considered better, such as for example drawdown, appropriate transformations can be made to maximize opposite values.
Arrays and variables are made public to simplify access and their recalculation code. Strict adherence to the OOP principles would require hiding them using the 'private' modifier and describing read and modify methods.
Author: Stanislav Korotky