Machine learning in trading: theory, models, practice and algo-trading - page 1196
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
Beautiful!
Question as an expert on Pythons, give me something in Python for experiments, I'm almost done with Sharp, it links with MT5 without any problems at all, in theory C# and Python support, then I can move to Python ;)
Python has NOTHING to do with our problem. Python is a pile of everything and everything to find useful for us, a redneck subplot with incomprehensible versions that are not compatible from top to bottom. Python's support is purely rustic, on enthusiasts. Python's acceptable package rubrication does not exist as such. To find anything in Python is a search on forums, by enthusiasts.
This is especially clear when comparing Python to R. R is our, trader's system, with an excellent reference apparatus and our rubricator. There are no problems at all with finding the tools you need. Each package is well documented: descriptions of function calls, links to algorithms that implement these functions, examples, links to articles related to the package. R can be used as a textbook on any problem. And all the material is absolutely concrete, supported by the corresponding code.
Python has no and cannot have any significant advantage over R in tools, because everything interesting for us is written in Cp, while Python or R are the shells for these packages. Sometimes Python is ahead of the new package, due to the complete lack of design requirements to packages and the subsequent support. Everything that appears on R mirrors is moderated and garbage is filtered out.
The flip side of R is Srr, R itself is written in Srrr and has a perfectly documented interface between R and Srrr. So there is always an option for you to drop the R shell and directly use the tool itself, written in Srr, from the programs in MCL.
One last thing. As far as I understand, there is still no bridge between Python and MCL. But such a bridge between R and both MKLs exists for many years, it is freely available in kodobase and there are no complaints - everything works stable, the tester works and I haven't seen any complaints about speed yet: the data is sent in memory.
Python has NOTHING to do with our problems at all. Python is a pile of everything and anything useful to us, a redneck subplot with incomprehensible versions that are not compatible from top to bottom. Python's support is purely rustic, on enthusiasts. Python's acceptable package rubrication does not exist as such. Anything to find in Python is a search on forums, by enthusiasts.
This is especially clear when comparing Python to R. R is our, trader's system, with an excellent reference apparatus and our rubricator. There are no problems at all with finding the tools you need. Each package is well documented: descriptions of function calls, links to algorithms that implement these functions, examples, links to articles related to the package. R can be used as a textbook on any problem. And all the material is absolutely concrete, supported by the corresponding code.
Python has no and cannot have any significant advantage over R in tools, because everything interesting for us is written in Cp, while Python or R are the shells for these packages. Sometimes Python is ahead of R in the appearance of new packages, due to the complete lack of design requirements on packages and the subsequent support. Everything that appears on R mirrors is moderated and garbage is filtered out.
The flip side of R is Srr, R itself is written in Srrr and has a perfectly documented interface between R and Srrr. So there is always an option for you to drop the R shell and directly use the tool itself, written in Srr, from the programs in MCL.
One last thing. As far as I understand, there is still no bridge between Python and MCL. But such a bridge between R and both MCLs exists for many years, it is freely available in kodobase and has no complaints - everything works stable, the tester works and I have not yet seen any complaints about the speed: the data is sent in memory.
I also prefer R, but I believe that the future in our field is for python. You can build a complete closed-loop system on it, from analysis to trading. An example is quantopian. You can't do that with R.
I also prefer R, but I believe that the future in our field is in python. It can be used to create a completely closed system, from analysis to trading. An example is quantopian. This will not work with R.
Why not? It seems to me that it already has for many years. There is a terminal IBrokers, which has an API to the same broker as quantopian.
Once again, Python is the same shell as R. But R is a serious development, while Python is a "dodgem" full of users which are not applicable to us and create noise.
The flip side of R is Srr, R itself is written in Srrr, and has a perfectly documented interface between R and Srrr. So it is always possible for you to drop the shell in R and directly use the tool itself, written in Srr, from the programs in MCL.
This is probably why the bridge for R is written in pascal.
You would make a good salesman, congratulations
You would make a good salesman, congratulations.
Name at least one widely known and popular (not to you, but to the world community) machine learning package in R.
Are there others? Not in R? There are almost 200 of them in the caret shell alone and not all of them, like keras itself. Do you want me to collect statistics on their use in the global community?
It's all empty talk just like any programming language choice conversation. I'm not a fan of podlucha. And for me that's the decisive criterion. To each his own.
Are there others? Not on R? There are almost 200 of them in the caret shell alone, and not all, like keras itself. Do you want me to collect statistics on their use in the global community?
It's all idle talk just like any programming language choice conversation. I'm not a fan of podlucha. And for me that's the decisive criterion. And there to each his own.
Well, I see that they started to add R, like TFlow and MXnet.
That's probably why the bridge for R is written in Pascal.
What difference does it make what it is written in?
The bridge was written 10 years ago, at that time it was used to teach programming to students. And then Pascal suddenly died.
But the main advantage of the bridge - the primitiveness, it does not require time to master.
I've even opened a branch here, agitated to write something more decent, even formulated the ToR, but nobody wants it, so what we have, we have. Python doesn't have that either.
Well, I see that they started adding R, like TFlow and MXnet, before it was only python
I've written on the forum: I don't see any profit in replacing one package with another. The whole problem is predictors and their predictive ability to a particular teacher. If this problem is solved, you can get rid of a few percent of errors at the expense of a package, but it's not worth the trouble.