Machine learning in trading: theory, models, practice and algo-trading - page 665
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
Absolutely correct approach.
Absolutely wrong approach at the moment. Your approach was correct when the programs for MT and Quick worked at the same speeds.
Now MT overtakes Quick by 100 times.
And by the way, the programs that work on all sorts of packages are optimized for single calculation, and MT more often uses streaming calculations.
R for example R counts as the sum of N points divided by N. Whereas in MT only the first point is counted this way, the rest in two steps, take away the last one not included in the new calculation, add a new calculation.
Therefore R is useful only for development, a lot of possibilities, and who knows what to apply. And when the development is finished (even no, not so, when the experiments are over) and the algorithms for TC are decided everything should be transferred to Mql.
Less gateways, less problems.
.... and with the algorithms for TC decided everything should be translated into Mql.
When people write such things, it means one thing: they do not have the slightest idea of the problem
When people write things like this, it means one thing: they don't have the faintest idea about the problem.
Yes they do, the problem is that modern people are so used to high-level languages that they don't even understand how to implement the same probability density function in arithmetic operations.
They do, the problem is that modern people are so used to high-level languages that they don't even understand how to implement the same probability density function in arithmetic operations.
Well, let's say I do. Suppose. I may not understand - it doesn't matter.
I do not understand why it is necessary to implement....? And, in principle, it is not necessary to understand - knowledge of electric kettle structure and circuit theory is absolutely not required for boiling water in it and using it.
Well, let's say I understand. Let's say I do. I may not understand - it doesn't matter.
I do not understand why it is necessary to implement....? And, in principle, it is not necessary to understand - knowledge of the structure of an electric kettle and circuit theory is absolutely not required for boiling water in it and using it.
For constant boiling of water in one and the same place you would prefer to run the socket to the table, or will use a dozen of extension cords which are plugged into each other, and laid which one behind the refrigerator, which one behind the chair, which one through the bathroom, there are also plugged in a bunch of other devices, etc. The essence I hope you understand.
Option 1: EA written in mql, run on a VPS and forget about the problems.
Option 2: Have assembled the integration of the hedgehog and the horrible, put on your home computer (this is generally a tinny), well, on a remote VPN for three times the price, and every day shaking failed or not.
Option 2: Build the integration of the hedgehog and the horndog, put on a home computer (this is a tinny), okay on a remote VPN at three times the price, and every day you shake malfunction or not.
That's all right. There's that too. I really can't really step away when the system is running and control is needed. And that's a problem. There can be problems with the UPU as well, but less so, I agree.
But I'd rather have a hedgehog with a hedgehog. I have a bad idea how to make the system by means of one MKUL and how much time and effort it will take. There is a lot of external software - from DB to IP clients, not to mention external matrix functionality. And it's simply unrealistic to do it all by means of a single MCL, well, it's even impossible with UPU.
SZY I should say, that it's no problem to pin it to the same C++/C#.
That's all right. There is also such a thing. I really can't really step back when the system is running and control is needed. And that's a problem. There can be problems with the UPU as well, but less so, I agree.
But I'd rather have a hedgehog with a hedgehog. I have a bad idea how to make the system by means of one MKUL and how much time and effort it will take. There is a lot of external software - from DB to IP clients, not to mention external matrix functionality. And it's simply unrealistic to do it all by means of a single MCL, well, it's even impossible with UPU.
It's realistic, but I don't deny that it's difficult.
Option 1: Write EA in mql, run on VPS and forget about problems.
That's the main thing which makes you to do everything by mql only.
R to use for speed, because alglib will be dozens of times slower to learn.