MQL4 -> R-Project - Interface Library | Page 2 | Forex Factory

Options

Go to
Permalinks
Print Thread

Similar Threads

Need help to fix mql5 library to work properly on mql4 2 replies

Roffild's Library - Library for MQL5 (MetaTrader) with support 10 replies

MQL4 Language Most Recent Version is it updated beyond the tutorial on the mql4 websi 6 replies

A better interface for placing Orders/Pending 3 replies

Attachments: MQL4 -> R-Project - Interface Library
Exit Attachments

MQL4 -> R-Project - Interface Library

  • #21
  • Oct 22, 2010 12:17pm Oct 22, 2010 12:17pm
I just noticed that it will leak a thread handle on every call to RExecuteAsync(), this is a problem if you leave it running for a few days. The reason is I was too lazy to use the TThread class as it would have been the recommended way but instead quickly hacked a BeginThread() into my existing code without caring about the thread handle afterwards. I am now preparing a new release that will fix this problem.
  • #22
  • Oct 22, 2010 4:09pm Oct 22, 2010 4:09pm
Quoting 7bit
I am now preparing a new release that will fix this problem.
Uploaded new version 1.2.0.36 which fixes this problem.
  • #23
  • Oct 23, 2010 8:32am Oct 23, 2010 8:32am
Quoting 7bit
Uploaded new version 1.2.0.36 which fixes this problem.
Thanks Bernd!
  • #24
  • Oct 23, 2010 10:36am Oct 23, 2010 10:36am
7bit,

is there a way to use this interface under Linux running Metatrader with Wine?
  • #25
  • Edited 3:18pm Oct 23, 2010 10:53am | Edited 3:18pm
Quoting Mechthildche
7bit,

is there a way to use this interface under Linux running Metatrader with Wine?
I haven't tested it. It will (since it assumes that it is running in windows) try to start (with the help of wine) the *windows* executable ~/.wine/drice_c/..../rterm.exe (not /usr/bin/R) since inside the wine environment it has no idea that there can exist anything outside of ~/.wine/ (and how such a strange alien world [the OS that lives outside] might look like or function) and this is why the wine implementation of of the windows API CreateProcess() could not start native linux executables anyways, even if it had the correct path name. It could not cross this border.

You will have to install the windows version of R in wine and then it should theoretically work. (untested but this is how it should work in theory).
  • #26
  • Oct 23, 2010 2:40pm Oct 23, 2010 2:40pm
you are the usual genius... i was doing this with sockets so far, and i am sorry for all the double to char array conversions i forced my cpu to perform.
Cant wait to test this, thanks.
  • #27
  • Oct 23, 2010 3:24pm Oct 23, 2010 3:24pm
Quoting pippero
you are the usual genius... i was doing this with sockets so far, and i am sorry for all the double to char array conversions i forced my cpu to perform.
Cant wait to test this, thanks.
There are still double to char and char to double conversions for vectors, only if you transfer a matrix it will write the whole raw memory block as it is to a temp file and then read.bin() with R. But it is quite fast since there is no polling involved and also the temp file writing is so fast that most of it happens in the file system cache only.

The average roundtrip time for a simple RExecute() is ~300µs on my slow laptop. (measured with a separate .exe that loads my dll, not with mql4)
  • #28
  • Oct 23, 2010 3:43pm Oct 23, 2010 3:43pm
Quoting 7bit
There are still double to char and char to double conversions for vectors, only if you transfer a matrix it will write the whole raw memory block as it is to a temp file and then read.bin() with R. But it is quite fast since there is no polling involved and also the temp file writing is so fast that most of it happens in the file system cache only.

The average roundtrip time for a simple RExecute() is ~300µs on my slow laptop.
Oh well, i guess i could always try using the writetobinary/readBin mechanism for passing vectors too, but it seems like we all have more cpus than we need these days.

you should look into the tcltk / tcltk2 packages for R ; they have some sort of timer mechanism that runs in another R thread -- you could use it to execute dummy R calls at regular intervals so your R graphics windows dont block .
  • #29
  • Edited 7:04pm Oct 23, 2010 6:36pm | Edited 7:04pm
Quoting pippero
you should look into the tcltk / tcltk2 packages for R ; they have some sort of timer mechanism that runs in another R thread -- you could use it to execute dummy R calls at regular intervals so your R graphics windows dont block .
I could do this directly from my DLL (I already have the locking mechanism and the thread that waits for the result of RExecuteAsync() to release the lock again, so this would not be much work. Maybe I'll implement it.

PS: I just made some measurements with mql4 and the following code:
Inserted Code
   for(i=0; i<100000; i++){
       RExecute(R, "");
    }
needs 14 seconds, this means 140µs per RExecute(). If I do something like
Inserted Code
   for(i=0; i<100000; i++){
       RGetInteger(R, "1+1");
    }
which translates to
Inserted Code
as.integer(1+1)
it takes 20 seconds (200µs per call).

The following assigns the same 100 element vector 100000 times:
Inserted Code
   double foo[100];
   int i;
   ArrayInitialize(foo, 1.0/3); // odd numbers, long strings with 15 digits

   log("Start");
   for(i=0; i<100000; i++){
      RAssignVector(R, "foo", foo, 100);
   }
   log("End");
needs 208 seconds (2.08 ms per vector). This is still 500 vectors or 50000 doubles or roughly 0.8 Megabytes per second ascii data that is going through the pipe.

The same as above but *each* vector as matrix: (transfer via file 10000 times create & write & as.matrix(readBin()) & delete)

Inserted Code
   double foo[100];
   int i;
   ArrayInitialize(foo, 1.0/3); // odd numbers, long strings with 15 digits

   log("Start");
   for(i=0; i<100000; i++){
      RAssignMatrix(R, "foo", foo, 100, 1); // 100 rows, 1 column
   }
   log("End");
582 seconds (5.8ms per vector (each one being a file of 800 byte))

(Of course this is only a stupid benchmark. If I had assigned a matrix of 100 x 100000 this would be only one command and one temp file of 80MB (8 bytes per double) and be done in a few seconds.)

These numbers are from an old Pentium-M running at 1300MHz and wndows is running inside a virtualbox.
  • #30
  • Oct 24, 2010 7:17pm Oct 24, 2010 7:17pm
by the way, if you ever want to do a version that uses R.dll directly (and thus passes arrays natively), I'd be happy to help in any way i can, vc++ or lazarus. it would be pretty awesome imho.
  • #31
  • Oct 25, 2010 1:36am Oct 25, 2010 1:36am
Hi,

7bit thanks again for what you‘re doing to this community.

Maybe I’m a bit off topic but over the weekend I was a bit documenting myself and I came across with this open source toolbox.

http://www.shogun-toolbox.org/

R examples.
http://www.shogun-toolbox.org/doc/r__examples.html

Does anyone have experience with such a toolbox? Maybe we could open a separate thread for sharing experiences and opinion.

Claudio
  • #32
  • Oct 25, 2010 5:37am Oct 25, 2010 5:37am
Quoting 7bit
Here it is: (save it as an indicator in the indicators folder)
[code]
#property copyright " Bernd Kreuss"


#property indicator_chart_window

#property indicator_buffers 1
#property indicator_color1 Red
#property indicator_width1 2


#include <mt4R.mqh>

extern int order = 200;
extern int back...
Thanks for the great indicator.Addition to yours I have found similar one in mql 5 codebase: http://www.mql5.com/ru/code/129
http://www.mql5.com/ru/code/134
  • #33
  • Oct 27, 2010 6:49pm Oct 27, 2010 6:49pm
Quoting purley
Thanks for the great indicator.Addition to yours I have found similar one in mql 5 codebase: http://www.mql5.com/ru/code/129
http://www.mql5.com/ru/code/134
At least "7bit" is trying to do us a favor here converting mql5 to mql4, which is something hard I find myself.

It is easy to convert mql4 to mql5, but not the other way around.

I hope this gives a thumb up for 7bit my friend.

Cheers,

Sf
  • #34
  • Oct 27, 2010 6:51pm Oct 27, 2010 6:51pm
Hi 7Bit,

Thanks a lot.

It is very useful , and I mainly concentrate on the code itself so I can learn how things can be done, and might find some use of this code in the future to implement another idea.

Best wishes,

SF
  • #35
  • Edited 7:59pm Nov 6, 2010 6:06pm | Edited 7:59pm
I uploaded a new version. Current version is now 1.3.0.25, find it at post #1 in this thread.

Again we have some minor API changes but you are not losing any functionality. Additionally the .mqh file now also defines some shortcuts for the super lazy programmers among you who do not want to type the lengthy function names, the handle and the array sizes all the time: simply call one of the Rx() and friends (defined at the bottom of mt4R.mqh.

An important change is that I have now decided to put it under the GPL license (NOT LGPL, I am NOT Santa Clause, although I almost look like him!). If you need a commercial license for a closed source product then please contact me, we might find some agreement.

The library will now start a separate thread that deals with the refreshing of the plot window, so you don't have to worry about this anymore, frozen plot windows should be a problem of the past. Just call options(device='windows') in init and then you can plot() and it will just work.

A few minor changes have been made to the API, RDebug() has been replaced with RPrint(), this will call print() and send the output to the debug monitor on debug level 0.

I have been using this version now unchanged for more than a week, permanently starting and stopping multiple instances of R while switching timeframes or recompiling all sorts of EAs and scripts, etc. without finding any problems. I can recommend this version as very stable and I will soon make a section on my website about it where you will then always find the latest version.
  • #36
  • Nov 6, 2010 6:37pm Nov 6, 2010 6:37pm
Quoting superluz
Hi,

http://www.shogun-toolbox.org/

R examples.
http://www.shogun-toolbox.org/doc/r__examples.html
This looks like libshogun could also be directly accessed without using R (the shogun-R interface does not look very native to R, it almost looks as foreign to R as my mql-R interface looks foreign to mql). Maybe it is also possible to use it through my mql4-python interface.

Somebody should make a direct mql-shogun interface.
  • #37
  • Nov 15, 2010 12:09pm Nov 15, 2010 12:09pm
I ran the debugview.exe and then started the terminal. It crashed with the below errors in the debugview


[1520] installed exception handler for Crogram FilesFIGfx - Meta Traderexpertslibrariesmt4R.dll
[1520] <-1> TRConsole: destroying
[1520] removed exception handler for Crogram FilesFIGfx - Meta Traderexpertslibrariesmt4R.dll
[5216] installed exception handler for Crogram FilesFIGfx - Meta Traderexpertslibrariesmt4R.dll
[5216] <-1> TRConsole: destroying
[5216] removed exception handler for Crogram FilesFIGfx - Meta Traderexpertslibrariesmt4R.dll


Is it of any help? or shud I capture it in someother way.
  • #38
  • Edited 3:46pm Nov 15, 2010 12:28pm | Edited 3:46pm
Quoting reachjj
I ran the debugview.exe and then started the terminal. It crashed with the below errors in the debugview


[1520] installed exception handler for Crogram FilesFIGfx - Meta Traderexpertslibrariesmt4R.dll
[1520] <-1> TRConsole: destroying
[1520] removed exception handler for Crogram FilesFIGfx - Meta Traderexpertslibrariesmt4R.dll
[5216] installed exception handler for Crogram FilesFIGfx - Meta Traderexpertslibrariesmt4R.dll
[5216] <-1> TRConsole: destroying
[5216] removed exception handler for Crogram FilesFIGfx - Meta Traderexpertslibrariesmt4R.dll


Is...
could you set the debug level RDEBUG to 2 and try again?

Which version of R do you have?
Did you set the correct RPATH in the EA?
Which version of windows are you running?

[Edit:] for confused readers of this thread: we are talking about the EA that I posted in the cointegration and mean reversion thread

[Edit2]: Problem found: You did not specify the correct path to your Rterm.exe. You must configure this correctly in the mq4 file. I am aware that it should not be the intended behavior to crash when this happens, It should catch this gracefully and report the error instead. The next version of mt4R.dll will have this fixed (I have fixed it already for the next release). In the meantime make sure you always specify the correct path to Rterm.exe and it will not crash.
  • #39
  • Nov 16, 2010 4:13pm Nov 16, 2010 4:13pm
Maybe you could help me out...

When trying to compile the EA you posted in the first page, I have warnings telling me that StartR, StopR, RX, etc. functions are not referenced and will be removed from the exp file.

Can you help me out?

I'm really eager to try this as we've done a bit of actuarial modeling in college on R through GNU Emacs!
  • #40
  • Edited 5:47pm Nov 16, 2010 5:33pm | Edited 5:47pm
Quoting ultfrisbee
Maybe you could help me out...

When trying to compile the EA you posted in the first page, I have warnings telling me that StartR, StopR, RX, etc. functions are not referenced and will be removed from the exp file.
This is nothing to worry about. It does only notice that it optimized the .ex4 by not including the unused functions that are defined in the include file but never used in this particular EA. (They must be there because other EAs or indicators using mt4R.mqh might need them). Other compilers do this optimizing too without mentioning it (at least not labeled as warning) but the mql4 compiler is a bit talkative.

If it compiles but MT4 does immediately crash then the path to the Rterm binary is not correct.

You also need DebugView.exe (from microsoft) if you want to make your own scripts (and set the debug level in RInit() to 2) because it cannot use Print() it needs this to output debug messages and you need to see what is going on until your script is completely working.

It also helps for development and debugging to do a RExecute(handle, "save.image('c:/path/to/somewhere/file.R')") after some intermediate results to save the complete workspace, so you can load it from a separate R console to inspect it interactively and try things.
0 traders viewing now