Discussion of article "Statistical Distributions in MQL5 - taking the best of R" - page 6

New comment
 
Renat Fatkhullin:

This is just pure proof in practice and theory of the fallacy of the position expressed by some traders in the topic https://www.mql5.com/ru/forum/96176/page10 (there was a mention somewhere):

  • in R all libraries are optimised and as fast as possible
  • there are many optimisations in R, including Intel Threading Building Blocks, etc.


It turned out that this is not true. In the simplest function, it turned out to be a drain and MQL5 is more efficient. Moreover, I have substantiated why it is faster theoretically. In addition to practical results.

R is even officially called "language and environment" - inside it is actually a scheme with its dsl, macros, sexpr and rubbish that "glues" to different libs and environment...But it is compact and easy to extend, it is actually good, that's why it is valued. And not so long ago apologists of mat.stat. packages on the one hand and fans of FP on the other hand were denouncing R for brakes :-).

PS. by the way, there is a suspicion that in microbenchmark seq() is deployed already inside the measurements. A small thing, of course.

 
Maxim Kuznetsov:

R is even officially called "language and environment" - inside it is actually a scheme with its dsl, macros, sexpr and rubbish that "glue" to different libs and environment...But it is compact and easy to extend, it is actually that good, that's why it is appreciated. And not so long ago apologists of mat.stat. packages on the one hand and fans of FP on the other hand were denouncing R for brakes :-))

Let it be called whatever you want.

It's just that the statement about its optimisation turned out to be false even if it has a lot of functions in native 64-bit DLLs. Now we will point out everywhere that our matrix calculations are faster than in R. And that the transfer of developed ideas from R to MQL5 will give a real advantage.


PS. by the way, there is a suspicion that in microbenchmark seq() is deployed already inside the measurements. A trifle, of course.

No, seq is outside the measurement.

Try to call it yourself many times after a single fill via seq

res <- microbenchmark(a<-dbinom(k, n, pi/10, log = TRUE))
print(res)
 
Being a theorist would never dare to argue with a developer-practitioner, because being a developer-practitioner in my field, I always look with condescension at the criticism of theorists.
 
Renat Fatkhullin:

In MQL5 it is counted twice as fast: 10 microseconds against 20 microseconds in R.

I have a little bit different.
Average time: MT5 12 microseconds, R 16 microseconds
Minimum: MT5 8 microseconds, R 15 microseconds.

Windows 10 Pro (x64 based PC), IE 11.00, UAC, Intel Core i7-6700 @ 3.40GHz
R - 3.3.1 x64
MT5 1445

Congratulations, mql compiler can good optimisation.

<nerd mode.

To the MT5 results you should add 100 milliseconds spent on compilation.
R in 16 microseconds manages to interpret input from a string and pass it to the library and get the result back.

</ nerd mode>

 
Dr.Trader:
< nerd mode>

To the MT5 results you should add 100 milliseconds spent on compilation.
R takes 16 microseconds to interpret the result from a string and pass it to the library and get the result back.

</ nerd mode>.

No it doesn't.

I too believed that it should be optimised in R. But I installed it myself, started to understand it myself and realised absolutely that this system can't squeeze out the maximum because of the system overhead of the dynamic language.


You should look at the minimum time. You have a direct confirmation of my results: 8 vs. 15.

 
Renat Fatkhullin:

Let it be called whatever you want.

It's just that the statement about its optimisation turned out to be false even if it has a lot of functions in native 64-bit DLLs. Now we will point out everywhere that our matrix calculations are faster than in R. And that the transfer of developed ideas from R to MQL5 will give a real advantage.


No, seq is out of measurement.

Try to call many times yourself after a single fill through seq.

It is not a fact at all..R is an FP, it can "omit" a significant part of calculations simply because it is unnecessary, it can make a specific conclusion about the calculation path. Just incomparable things, like sour and soft :-)

 
Maxim Kuznetsov:

not a fact at all..R is a FP, it can "omit" a significant part of the computation simply for unnecessary, it can make a specific inference about the path of the computation. Just incomparable things, like sour and soft :-)

Enough with the nonsense already.

Time after time trying to disprove reality.

 

I'm talking about R, but my skill is very small)) can someone check the correctness of the code?

library(microbenchmark)
library(compiler)
n <- 2000
k <- seq(0,n,by=20)
q<- function(xx) { dbinom(k, n, pi/10, log = TRUE) }
res <- microbenchmark(cmpfun(q))
print(res)


The results show the same graphs for this code,




and Renate's code.


If the code is correct, can you check the benchmark?

 
Dr.Trader:

To the MT5 results you should add 100 milliseconds spent on compilation.

I mean that mql compiler already knows all input parameters during compilation. It is enough for it to calculate everything during compilation, and when calling the script - it just returns the pre-calculated result. I've seen some articles on the hub where c++ compilers were compared, and judging by the analysis of assembler code, this is exactly what happens there.

 
ivanivan_11:

If the code is correct, can you check the benchmark?

The question is cancelled, in the first test the results were in microseconds, here they are in milliseconds. didn't pay attention at first

12345678910111213...20
New comment