Research in matrix packages - page 5
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
Great, it's my first day of learning R, answer my questions please, I want to compare possibilities of R and Matlab. But don't host hostility, be reasonable and calm :).
1. Yes.
2. Why ? You need a single MT4R.dll which is the gateway for transferring data to R and getting results back.
3. To all existing databases. Not only that, but both Microsoft and Oracle have integrated R into their databases.
4. R has various options for interfacing with Matlab, from simple Matlab file exchange to executing Matlab functions from R. If you have experience in this area, you can implement an excellent Matlab-MTterminal interface with R.
5. In R the packages for all directions of a science and technics and taking into account the latest achievements are realised. You may start from here.
6. There is more than one. The most common is ff.
In general I'm surprised. You're in the middle of nowhere. Look through the articles 1 and 2 on this site and you won't understand a lot but you will get an idea of how the language works.
I am finishing the second article on deep learning that will hopefully be submitted for revision tomorrow and will contain examples of experts... If there is interest, I think I will write several articles on the initial level (filtering, decomposition, prediction etc.). And of course, keep digging on deep learning, especially as Google opened its TensorFlow library for everyone. And there are others no less interesting and promising (mxnet, pyBrain).
If a group of enthusiasts comes together, we can organize a branch of R language users.
Good luck
Please describe the process of working through this DLL in more detail. And where to get it?
Let's discuss how we can make better integration with R?
It's an interesting topic and it can be well developed.
Hi.
I will add to what has been said before.
Option1 is preferred for several reasons:
In this variant we simply provide data transfer to R process and receive data from it. What is provided in MT4R.mqh is more than enough for now.
The only thing we would like to see additionally is obtaining quotes by request from R process bypassing the terminal. It does not matter if from local files/buffers of the terminal or directly from a brokerage company's server. But it is not a crucial wish.
My non-professional opinion is thatvariant 2 requires cardinal changes not only in terminal, but also in editor. And I remember the last cardinal redesign of the terminal with a shudder. This variant can be developed simultaneously with the realization of the first variant and implemented when most of the clients get used to it, and especially when they see the benefits of using this language. Of course, full integration of the terminal and editor with R language is ideal.
I'm glad you paid attention to this direction.
Good luck
Let's discuss how we can make better integration with R?
This is an interesting topic and could be well developed.
I've always wondered why MT is not included in R?
If you look at 15 years of MT, it's an evolutionary development, when the functionality was growing, but the main thing - the customer - remained the same. It is a pseudotrader using TA as a tool.
1. The inclusion of MT in R will allow you to join the professional community of traders, those organizations with not just hundreds but thousands of traders using professional tools in the form of statistics, econometrics, machine learning ....
2. It is not unimportant that the inclusion of MT in R will make it possible to use MT in the teaching process. At one time, teaching mechanical trading systems as a tool, I chose Quick and Metastock, although I knew about MT, but it had a language that had to be taught to students, and it was not provided in the program. Incorporating MT into R with the R algorithmic language as an EA writing tool, removes all learning problems - R is learned outside the connection to terminals.
The way I see it:
1. MT itself must be a GUI in R (examples are available, as well as a tool for building such GUI - shiny). It is very desirable that this GUI is a copy of one of terminals, or better both
2. R algorithmic language. Expert Advisors are written in the R language, and all of the specific trading functions are implemented as a package. In this case, as far as I understand, the syntax for calling special functions will remain the same. This is a standard solution, as performance will be determined by language and quality of writing these functions, and they, being written in C, and tested for many years, will give the performance results comparable to existing ones. I want to pay attention that the speed of execution of other, computationally intensive algorithms in R will be maximal and not inferior to their implementation in other algorithmic languages, since a program in R is usually calls to packages, which for computationally intensive algorithms are not implemented in R. To this it should be added that usual practice of realization of computationally intensive algorithms demands loading of all cores of computer.
3. In my non-professional opinion, labor costs will not be great, given the very friendly relationship between R and C and the internal kitchen, which we can't see, can be transferred from the existing terminal to the new terminal.
4. the part of the terminal held by the brokers will remain unchanged.
As soon as the mentioned packages are included in the CRAN mirrors, the metacquotes gain narrow publicity in wide circles instead of wide publicity in narrow circles. The Metakvot terminal will have no competitors, as the only R terminal available is IBrokers, which is tied to certain fee-based brokers.
I've always wondered why MT is not included in R?
And I've always wondered why they started developing a C-like compiler themselves (I mean early MQL4) instead of getting a ready-made free C++ Compiler like GCC.
I worked for major Western companies and nobody ever thought of developing their own C++ compiler for various embedded applications from scratch. They always took gcc and made a port to a specific processor.
And judging by the fact that a very successful port to 4-processor DSP with NEON architecture (up to 6 instructions per clock per core) was made in 2006, this compiler is rather flexible for adaptation. I.e. compiler really paralleled operations with average 2-4 operations per clock per core, only bottlenecks had to be optimized on asm.
And now let's recall the crappy thing that was MQL4 up to version 600.
Now on the subject. As Renat explained, the reason was a maniacal desire to make a compiler with the fool and intruder protection. Although it didn't even smell like that before version 600, it was a glitch upon a glitch.
But, if you take his words at face value, what does R look like from the security point of view? I'm quite new to it, I've been working with Matlab since 2000, so please explain, if you know anything. May it encrypt output files like MQL4/5 compilers?
Furthermore, as far as I understood R remains an interpreter, it means that it will be even slower than the old MQL4 and certainly slower by orders of magnitude than today's MQL5.
I always wondered why they started developing a C-like compiler (I mean early MQL4) instead of using a free C++ Compiler like GCC.
I worked for major Western companies and nobody ever thought of developing their own C++ compiler for various embedded applications from scratch. They always took gcc and made a port to a specific processor.
And judging by the fact that a very successful port to 4-processor DSP with NEON architecture (up to 6 instructions per clock per core) was made in 2006, this compiler is rather flexible for adaptation. I.e. compiler really paralleled operations with average 2-4 operations per clock per core, only bottlenecks had to be optimized on asm.
And now let's recall the crappy thing that was MQL4 up to version 600.
Now on the subject. As Renat explained, the reason was a maniacal desire to make a compiler with the fool and intruder protection. Although it didn't even smell like that before version 600, it was a glitch upon a glitch.
But, if you take his words at face value, what does R look like from the security point of view? I'm quite new to it, I've been working with Matlab since 2000, so please explain, if you know anything. May it encrypt output files like MQL4/5 compilers?
Furthermore, as far as I understand R remains an interpreter, it means that it will be even slower than old MQL4 and certainly slower by orders of magnitude than today's MQL5.
Read my posts about speed. Briefly. R is largely a shell and the issues you raise have nothing to do with R at all - all these issues are solved within functions implemented in other languages. If we're talking about encryption, it certainly has nothing to do with the intended implementation of the terminal - you can take anything existing.
I have a habit of reading previous posts, so the advice is not for me ))
**************************
I must try to translate some of my Matlab programs to R to compare the speed. If I manage to figure it out by weekend, I'll do it and let you know. Matlab is pretty slow, I do a lot of stuff in C# or C++ and plug it in as a DLL for speed.
R itself is three times retarded. It's an interpreter. No problems with debugging at all, at first I started using a debugger, and then it turned out to be useless.
Speaking of R speed, there are several considerations here.
1. you can translate it into byte-code, but it's a poultice
**************************
Do you realise that MQL4/5 are compilable languages? And that for your dream of an MT-like R terminal Metakvotam will have to make an R compiler?
But, if you take his words at face value, what does R look like from a safety point of view? I'm quite new to it, I've been working with Matlab since 2000, so please explain, if you know anything. May it encrypt output files like MQL4/5 compilers?
Furthermore, as I understand it, R remains an interpreter, which means that it will be even slower than old MQL4 and certainly slower by orders of magnitude than today's MQL5.
1. everything is encrypted in different reliable ways.
2) This is fundamentally wrong. All heavy calculations are written in C plus paralleling.
Try and learn.
Good luck
Let's be realistic.
Today the MT4 terminal with the EDITOR works without any problems (at least for me). We just need to add the smallest thing to interact with R.
The developers have a better idea of how to do this. The main thing is to do it quickly and without headaches for the users.
Good luck