Alternative to MQL5

Question

I am starting with Expert Advisors on MetaTrader Terminal software and I have many algorithms to use with it. These algorithms were developed in MATLAB using its powerfull built in functions ( e.g. svd, pinv, fft ). To test my algorithms I have some alternatives:

1. Write all the algorithms in MQL5.
2. Write the algorithms in C++ and than make a DLL to call by MQL5.
3. Write the algorithms in Python to embed in C and than make a DLL.
4. Convert the MATLAB source code to C and than make a DLL.

About the problems:

1. Impracticable because MQL5 does not have built in functions so I will have to implement one by one by hand.
2. I still did not try this, but I think it will take a long time to implement the algorithms ( I wrote some algorithms in C but took a good time and the result wasn't fast like MATLAB ).
3. I am getting a lot of errors when compiling to a DLL but if I compile to an executable there is no error ( this would be a good alternative since to convert MATLAB to python is quite simple and fast to do ).
4. I am trying this now, but I think there is so much work to do.

I researched about other similar pieces of software, like MetaTrader Terminal but I didn't found a good one.

I would like to know, if there is a simplest ( and fast ) way to embed other language in some way to MQL5 or some alternative to my issue.

Thanks.

Answer 1

Yes, there is alternative ... 5 ) Go Distributed :

having a similar motivation for using non-MQL4 code for fast & complex mathematics in external quantitative models for FX-trading, I have started to use both { MATLAB | python | ... } and MetaTrader Terminal environments in an interconnected form of a heterogeneous distributed processing system.

MQL4 part is responsible for:

1. anAsyncFxMarketEventFLOW processing
2. aZmqInteractionFRAMEWORK setup and participation in message-patterns handling
3. anFxTradeManagementPOLICY processing
4. anFxTradeDetectorPolicyREQUESTOR sending analysis RQST-s to remote AI/ML-predictor
5. anFxTradeEntryPolicyEXECUTOR processing upon remote node(s) indication(s)

{ MATLAB | python | ... } part is responsible for:

1. aZmqInteractionFRAMEWORK setup and participation in message-patterns handling

2. anFxTradeDetectorPolicyPROCESSOR receiving & processing analysis RQST-s to from remote { MQL4 | ... } -requestor

3. anFxTradeEntryPolicyREQUESTOR sending trade entry requests to remote { MQL4 | other-platform | ... }-market-interfacing-node(s)

Why to start thinking in a Distributed way?

The core advantage is in re-using the strengths of MATLAB and other COTS AI/ML-packages, without any need to reverse engineer the still creeping MQL4 interfacing options ( yes, in the last few years, DLL-interfaces had several dirty hits from newer updates ( strings ceased to be strings and started to become a struct (!!!) etc. -- many man*years of pain with a code-base under maintenance, so there is some un-forgettable experience what ought be avoided ... ).

The next advantage is to become able to add failure-resilience. A distributed system can work in ( 1 + N ) protected shading.

The next advantage is to become able to increase performance. A distributed system can provide a pool of processors - be it in a { SEQ | PAR }-mode of operations ( a pipeline-process or a parallel-form process execution ).

---

MATLAB node just joins:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MATLAB script to setup 

zeromq-matlab
clear all;
if ~ispc
    s1 = zmq( 'subscribe', 'ipc', 'MATLAB' );   %% using IPC transport on <localhost>
else
    disp( '0MQ IPC not supported on Windows.' )
    disp( 'Setup TCP transport class instead' )
    disp( 'Setting up TCP')                     %% using TCP transport on <localhost>
    s1 = zmq( 'subscribe', 'tcp', 'localhost', 5555 );
end

recv_data1 = [];                                %% setup RECV buffer

This said, one can preserve strengths on each side and avoid any form of duplications of already implemented native, high-performance tuned, libraries, while the distributed mode of operations also adds some brand new potential benefits for Expert Advisor modus operandi.

• one may add a remote keyboard interface to an EA automation and use some custom-specific commands ( CLI )
• a fast, non-blocking, distributed remote logging
• GPU / GPU-grid computing being used from inside MetaTrader Terminal
• may like to check other posts on extending MetaTrader Terminal programming models

---

A Distributed System, on top of a Communication Framework:

MATLAB has already available port of ZeroMQ Communication Framework, the same that MetaTrader Terminal has, thanks to Austin CONRAD's wrapper ( though the MQH is interfacing to a ver 2.1.11 DLL, the services needed work like a charm ), so you are straight ready to use it on each side, so these types of nodes are ready to join their respective roles in any form one can design into a truly heterogeneous distributed system.

My recent R&D uses several instances of python-side processes to operate AI/ML-predictor, r/KBD, r/RealTimeANALYSER and a centralised r/LOG services, that are actively used, over many PUSH/PULL + XREQ/XREP + PUB/SUB Scalable Formal Communication Patterns, from several instances of MetaTrader Terminal-s by their respective MQL4-code.

MATLAB functions could be re-used in the same way.