Machine learning in trading: theory, models, practice and algo-trading - page 2689

[Maxim Dmitrievsky]

Aleksey Nikolayev #:

By the way, I don't understand why nobody has made an analogue of mt-R for python. I remember you had an article about sockets, but I think you could only transfer data, not commands.

I was waiting for sockets to be allowed in the tester, but it didn't happen. I also had a crazy idea to use MT5 tester for python scripts, but then I realised that it's better to rewrite it in the platform language, and then I realised that my own tester is not bad too

And then the possibility to trade from python was added and the need for sockets was eliminated. I do not use forwarding of messages and indicator values. I don't understand the first one, the second one too, you can calculate any indicator in the bot body

In the end, Renat's position turned out to be correct in principle, that it is some excesses... well, at least in my case.

Ah, then I bought a Mac and python doesn't work as well as everything else. I will not write how much pain I experienced when installing python packages on Mac M1, everything else will seem like flowers. I just rolled back to transfer logic to bots from python.

[mytarmailS]

R marvellous!!!

[Evgeny Dyuka]

Renat Fatkhullin #:

Web Terminal Modern here: https://www.mql5.com/ru/trading

The topic of crypto is plastered and dragged to the legal bottom by players en masse every week. Therefore, we do not touch it. We do not discuss this topic.

With the ML topic we are not in the catching up, but among those who are qualitatively working on the topic and offering integrated solutions. Let's see what we will consistently build up in the next 6 months.

Few languages have native types vector, matrix, complex and operations on them. It is difficult to build machine learning without them.

Offering consumers to deploy Python + Tensorflow (+CUDA for dessert) is suicide and inability to protect and sell the fruits of their labour.

But we are striving for one *.ex5 file within a common terminal without the need to put anything additional. And OpenCL support covers the widest range of accelerators unlike CUDA.

I propose to return to this dialogue in a year.
My prediction:
- the terminal will not move to the browser (I mean a normal browser solution), so it will be old-school on Windows with bells, beepers, jumping chart and zoom in the form of a button with a magnifying glass "goodbye youth";
- there will be no movement towards the crypto audience (it is already stated);
- Ml will probably be supplemented with functions, but the gap between popular ML bibles will not even shrink (they do not stand still either);
- real working ML solutions will not appear on the market (there is no one to write, see the previous point). previous paragraph).

But crypto exchanges with their financial power and services like TradingView can move towards forex, funds and raw materials....

[Evgeny Dyuka]

News about python. Like now it's the most popular language.

And TA-Lib can already be used in python.

[Sergey Gridnev]

Evgeny Dyuka #:

News about python. It's like the most popular language now.

And TA-Lib can already be used in python.

That's a weird ranking.

[Maxim Kuznetsov]

Sergey Gridnev #:
Strange rating.

Everyone should move to VisualBasic - it is the most stable among TOPs in the rating and "cooler" than R and MATLAB :-)

[Maxim Dmitrievsky]

If crypto is a legal bottom, then forex is banned altogether :) Soon they'll be getting the terminal out from under the floor psst... wanna open a 1 to 1000 leveraged trade? 😁

[Vladimir Perervenko]

Maxim Dmitrievsky #:
And so another, seemingly positive topic, has been reduced to a discussion of the problems of stRajduzhdushchih 😆 And for example the same crypto exchanges do not give Rapi, only python? And I wrote for several years that nobody needs R

What are you talking about. Crypto exchanges(specifically Binance) provides REST APIs and sockets. Python and R write libraries that use these APIs. In R it's the binance library in Python ... I don't have it at hand.

Regarding unnecessary R, you don't need to speak for everyone. Speak for yourself.

About libraries for R. The latest R64.dll is universal for both mt4 and mt5. R is perfectly integrated with mt4/5. Seamlessly with Python and not bad with Julia.

Renat correctly divided developers roughly into two groups: those working for sale (market, freelance) and researchers developing for themselves. And their demands and interests are very different. That's why there is no sense in arguing about the eternal - which Yap is better. Better is the one that allows you to solve your tasks for your goals quickly and efficiently.

But rewriting models on MKL is not serious. If there will be onxx - good, but not all frameworks support it. It's an uncertain future.

One thing is clear - developers want to embrace the vastness. The aspiration is commendable. No need to criticise. Maybe something will work out. Let's wish them luck.

[Maxim Dmitrievsky]

Vladimir Perervenko #:

But rewriting models on MKL is not serious. If there will be onxx - good, but not all frameworks support it. It's an uncertain future.

One thing is clear - developers want to embrace the vastness. The aspiration is commendable. No need to criticise. Maybe something will come of it. Let's wish them luck.

What do you mean, not serious? Three-storey neural networks, sure, but they're not serious about using them for time series. Simple trained models are relatively easy to transfer. Cycles and arrays of weights/splits.

It is not serious to build a garden in one language, then connect to a terminal (only those who have written bots for metac, not hypotheticals, will understand). Because it always requires fine-tuning, including through the optimiser and including for different trading conditions. But those who like to build towers of Babel out of layers don't realise this :)

[Vladimir Perervenko]

Maxim Dmitrievsky #:
What do you mean, not serious? 3-storey neural networks of course, but it's not serious to use them for time series either. Simple trained models are easily transferable

Of course you need to be more specific. For simple models like logistic regression, wooden models, etc. it is probably possible. But I am talking about serious models for both TC and tabular data. These two areas have now become very divided and specialised. For tabular data, which are mainly used in machine learning, TabNet(paper, implementations (py) 1, 2, 3) is very promising. And a lot of other packages that give great results. Here is a list of what I have researched and partially use.

conda environments:
#
 base                  *  C:\Users\User\AppData\Local\R-MINI~1
PressPurtEnv             C:\Users\User\AppData\Local\R-MINI~1\envs\PressPurtEnv
aif360                   C:\Users\User\AppData\Local\R-MINI~1\envs\aif360
autogluon                C:\Users\User\AppData\Local\R-MINI~1\envs\autogluon
autokeras                C:\Users\User\AppData\Local\R-MINI~1\envs\autokeras
autopt                   C:\Users\User\AppData\Local\R-MINI~1\envs\autopt
darts                    C:\Users\User\AppData\Local\R-MINI~1\envs\darts
deap                     C:\Users\User\AppData\Local\R-MINI~1\envs\deap
deepxf                   C:\Users\User\AppData\Local\R-MINI~1\envs\deepxf
evalml                   C:\Users\User\AppData\Local\R-MINI~1\envs\evalml
fastai                   C:\Users\User\AppData\Local\R-MINI~1\envs\fastai
fedot                    C:\Users\User\AppData\Local\R-MINI~1\envs\fedot
flash                    C:\Users\User\AppData\Local\R-MINI~1\envs\flash
gluon                    C:\Users\User\AppData\Local\R-MINI~1\envs\gluon
ludwig                   C:\Users\User\AppData\Local\R-MINI~1\envs\ludwig
mindsdb                  C:\Users\User\AppData\Local\R-MINI~1\envs\mindsdb
mlbox                    C:\Users\User\AppData\Local\R-MINI~1\envs\mlbox
mlr3keras                C:\Users\User\AppData\Local\R-MINI~1\envs\mlr3keras
mlsauce                  C:\Users\User\AppData\Local\R-MINI~1\envs\mlsauce
nni                      C:\Users\User\AppData\Local\R-MINI~1\envs\nni
poutyne                  C:\Users\User\AppData\Local\R-MINI~1\envs\poutyne
pycaret                  C:\Users\User\AppData\Local\R-MINI~1\envs\pycaret
pycaret-ts               C:\Users\User\AppData\Local\R-MINI~1\envs\pycaret-ts
pymc_env                 C:\Users\User\AppData\Local\R-MINI~1\envs\pymc_env
r-gluonts                C:\Users\User\AppData\Local\R-MINI~1\envs\r-gluonts
r-gluonts1               C:\Users\User\AppData\Local\R-MINI~1\envs\r-gluonts1
r-reticulate             C:\Users\User\AppData\Local\R-MINI~1\envs\r-reticulate
r-torch                  C:\Users\User\AppData\Local\R-MINI~1\envs\r-torch
reservoir                C:\Users\User\AppData\Local\R-MINI~1\envs\reservoir
skorch                   C:\Users\User\AppData\Local\R-MINI~1\envs\skorch
sktime-dl                C:\Users\User\AppData\Local\R-MINI~1\envs\sktime-dl
terchmeta                C:\Users\User\AppData\Local\R-MINI~1\envs\terchmeta

Not all of them are used mainly because of machine power limitations and personal preferences. For me training and optimisation for more than an hour is not interesting.

I don't think it will be possible to transfer these models to MCL. And here you can't do without creating infrastructure for linking MKL<->Python.

This is a bit of a digression, but the topic is important to me.

The main idea, I repeat: every developer, whether he is a freelancer, a marketer or a forex/crypto/stock trader, has his "favourite" language and his "favourite" bicycles with crutches to it. We need to share experience of use, not argue what is better. And especially not to vang about the future of the JA.

And don't take the remark as a personal offence. It's not in kindergarten.

Good luck to everyone.