Machine learning in trading: theory, models, practice and algo-trading - page 2695
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
The problem with the topic of neural networks in trading is not in the tools, there are plenty of tools (I am not talking about mql). And there are plenty of professionals who"have serious knowledge and outlook on this topic".
On the basis of popular libraries this problem has been solved for many years. Maybe the problem is not in tools and professionals, but in ideas and understanding of HOW to do it. You can always get specialists to a working solution and they will polish it.
My point is that your chase for beauty of tools may not lead to results. Other places have these tools for a long time, as well as access to historical quote data. You are not giving anything new. Why is it suddenly going to work here?
I'm just messing around, it's always fun to have a fight or a chat.
I'm just messing around. It's always fun to have a fight or a chat.
Yes normal goal, to write your own tool for MO and of course this is quite different than using third party tools and connecting with them, of course more complex global and risky task, but quite logical. If the lag will be a couple of years from the beginning of the use of third-party packages after their takeoff in the metaquotes sandbox everything will be normal. And of course usability of programming environment for coders will be on the first place.
I don't see anything logical.
I really can't understand why to suffer, wait and get into MQL implementation of something that doesn't exist yet and in what form it will be unknown, but has been done long ago and cool and has a huge community. What would it take to get to the market? And maybe, probably, to sell something, if you are lucky, but it is not for sure.
And then not be able to move somewhere with it, like crypto, where the real money is. And where services with trading bots like 3commas or veles.finance will give you a chance to make money normally.
Well, write a better article there I don't know
Still, I would like to understand the reason why there is no mt-R analogue for python. It is about the possibility of launching an interpreter from an mql5-program with the ability to send commands to it and exchange data in both directions. This is convenient, for example, for quick testing of a trained model without distilling it into mql5-code, and in general it is quite a flexible tool. And it seems to be exactly what a fan of "chattering and chattering" wants.
I don't see what makes sense.
I really can't understand why to suffer, wait and delve into the implementation in MQL of something that does not exist yet and in what form it will be unknown, but has been done long ago and cool and has a huge community. What would it take to get to the market? And maybe, probably, to sell something, if you are lucky, but it is not certain.
And then not be able to move somewhere with it, like crypto, where the real money is. And where services with trading bots like 3commas or veles.finance will give you a chance to make money normally.
Again, complex, global and risky. And there is always a risk of not being liked in infrastructures as services as a commodity. But this is at least an understandable path. Maybe of course denial of duct tape on some successful moments of their necessity is evil, but it is certainly not the target path.
Still, I would like to understand the reason why there is no mt-R analogue for python. I am talking about the possibility of launching an interpreter from an mql5 program with the ability to send commands to it and exchange data in both directions. This is convenient, for example, for quick testing of a trained model without distilling it into mql5-code, and in general it is quite a flexible tool. And it seems to be exactly what a fan of "chattering and chattering" wants.
Probably because of the prohibition of array exchange between mqlPy-program and Py interpreter.
The same religion will be for R.
To be honest, I don't understand the point of critical security that MQ is talking about.
Maybe it's not about security, but about the complicated Py api for arrays.
They just didn't bother with it.
The numpy api is really painful there.
I'm stuck on matlab in general ))
I wrote a C-api dll for sending commands, everything is exchanged quite quickly, within the system frequency.
But for exchange in the background process the matlab engine is launched, and it consumes a lot of memory.
The only disadvantage of matlab.
For desktop and quick check it's fine.
Still, I would like to understand the reason why there is no mt-R analogue for python. I am talking about the possibility of launching an interpreter from an mql5 program with the ability to send commands to it and exchange data in both directions. This is convenient, for example, for quick testing of a trained model without distilling it into mql5-code, and in general it is quite a flexible tool. And it seems to be exactly what a fan of "chiming and chattering" wants.
Probably because of the prohibition of array exchange, between the mql5 program and the Py interpreter.
The same religion will be for R.
To be honest, I don't understand the point of critical security that MQ talks about.
Maybe it's not about security, but about the complicated Py api for arrays.And they just didn't bother with it.
So it is done for R - somehow via dll, though I didn't go into details.