Libraries: ALGLIB - Numerical Analysis Library

[Automated-Trading]

ALGLIB - Numerical Analysis Library:

ALGLIB math function library (v. 3.5.0) ported to MQL5. ALGLIB is one of the largest and most complete mathematical libraries

Do you need to make a fast Fourier transform or to solve a differential equation system? Do you perform a complex data analysis trying to gather all methods in one place as a source code? Then ALGLIB library of numerical methods is for you!

ALGLIB library is being constantly enhanced, new functions and improvements according to users' comments are implemented regularly. The latest version is 3.6.0.

Besides, the library contains the large collection of test cases covering the major part of the proposed methods' functionality. That will allow you to carry the tests and report detected errors to the project's authors.

Author: MetaQuotes

[amin_mohammadi]

Hello,

I need to find eigenvalues of below matrix:

2   3    2

10  3   4

3    6   1

how can I apply this library on this matrix? (non-symmetric matrix)

[davidhigh]

Thank you very, very much for this great article and the attached code! This will surely be the main tool for my planned MQL5 codes, and prevents me from going the C++-to-DLL-to-MQL5 way.

 

Regarding the previous question: there is a function named "NonSymmetricEVD" in the linalg.mqh file, which is not referenced in the text. Simply use this routine.

 

Best, David 

[davidhigh]

I have a further question: the newest version of the alglib seems to be 3.8.2., whereas according to the text the ported version is 3.5.0.

 

Are there plans for updating the ported code?

 

Thanks in advance,

David 

[Elmo de Moraes]

The code could be updated to the last version 3.8.2

[Rashid Umarov]

Automatically generated CHM-help for ALGLIB

[Tom Sasson]

Thank you @Rashid Umarov

I recommend all to go to the website, because this thread has been updated for 3 years, but the website keeps updating.

[LydiaMW]

We've done a complete overhaul of the GPL C++-based version of the ALGLIB library, releasing it as ALGLIB++. This tracks the latest version of ALGLIB, which is at 3.16.0, as of 2019/12. Much has been added in the Optimization and Interpolation modules since the earlier versions that MQL5 is synched up to (e.g. point-cloud splines(!), more inverse distance weighted interpolation methods, numerous additional optimization methods, etc.)

ALGLIB++ is a derivative of ALGLIB that is being used as an intermediate form in a longer-term reengineering/refactoring process, in which it will be recoded into native C++ (similar to where it was before Version 3), the extra layer and duplication being removed in preparation of providing more direct support for multi-threading, as well as additional tests and modules and eventually a scripting language front end.

The different language versions of ALGLIB were all generated from a common core, with the C++ version providing limited (but unofficial) support for the C90 dialect of C. This feature made it necessary to simulate, within C, features that would otherwise be native to C++, and then to provide a C++ wrapper on top of this. Correspondingly, there are two separate name-spaces: alglib_impl, which contains the C version, and alglib, which contains the C++ wrappers. ALGLIB++ has retained most of this structure and as much of the original coding as possible, but has reduced or eliminated much of the global infrastructure as a first step for its elimination and replacement by multi-threaded native C++ code and has significantly simplified the C++ wrapper interface. As such, it represents an intermediate form bridging between ALGLIB, itself, and the future library that ALGLIB++ is being transformed into.

Many issues that lead to a growth of complexity in ALGLIB, since (and prior to) the versions adapted by MQL5, have been resolved, with a resulting simplification in structure and reduction in complexity. In its present form, it should prove easier to adapt to MQL5, by those who are currently maintaining the MQL5 version of ALGLIB.

Included with the distribution is a complete reformatting of the manual for ALGLIB++ from the ALGLIB C++ original. The sections on the packages and subpackages, however, are compatible with both versions of ALGLIB, and the layout and content should both be easily adapted to the MQL5 version. MQL5 gets a shout-out in the "References & Related Links" section of the manual.

The latest version may be found at https://www.github.com/LydiaMarieWilliamson/ALGLIB_cpp ... bear in mind that, at present, it is undergoing continual reengineering and refactoring at a fairly rapid pace, and this will remain the case for a while longer. The timestamp of the latest revision is always kept in the README file. 

The recoded version will eventually be expanded into a larger library that will include more features and applications dedicated to Machine Learning, advanced Digital Signal Processing, Graphics and Sound Processing and Natural Language Processing. We are also preparing a C++ translation of LAPACK, to be called LAPACK++, for future integration into ALGLIB++. Other libraries, including MKL (which has neural net routines, by the way) are also under consideration for future integration.

[LydiaMW]

A few additional notes to the developers of the MQL5 version of ALGLIB:

When you adapted ALGLIB to MQL5, you ran into difficulties with the "RCOMM" routines.

These are effectively multi-threaded routines, where the thread-switching is written directly into the code by:

(1) caching thread-local variables with each entry and exit - and iteration routines carry out potentially millions and billions of call/return cycles!

(2) implementing thread-switching by jumping out of the routine to "pause" on an event, and jumping back into the routine to "resume" after the event - which means a lot of goto's and multiple entry points.

(3) decimating the control-flow structure of these routines in order to put the entry points on the top level in the function body.

When adapting ALGLIB to MQL5 you kept the control flow decimation in place, actually shipping off the code snippets into separate routines. This solution - as you eventually found out - is not maintainable; which has made keeping up with the ALGLIB updates impossible. ALGLIB, itself, got a little behind the curve as well - their RCOMM routines sometimes leave orphan structures and variables from earlier versions.

In ALGLIB++, the control flow structure is reintegrated: entry points jump back into the middle of a loop or other control flow structure where they left off.

There is no caching of thread-local variables; for the time being they've been made static (at the cost of thread-safety - but multi-threading is not formally a part of GPL ALGLIB).

Like ALGLIB, this means there are a lot of goto statements to do all the jumping back and forth; but they are more cleanly organized.

The repairs made in ALGLIB++, by themselves, speed up the routines by about 20-25%, based on our test results.

There are two ways to deal with this architecture to get rid of the goto statements and more properly handle the thread-local variables:

(1) Implement actual thread-switching, which means that the RCOMM routines send out "event" messages (which is what the needf, ... algpowerup flags actually are), and the caller has to set up an event-handler to receive and process the messages. Not sure if MQL5 can produce and handle user-defined events, however.

(2) Use function pointers for the events.

Bear in mind that the RCOMM routines may be nested; and in some cases, they can relay events on to their caller obtained from the RCOMM routines that they themselves call.

The ALGLIB developer(s) decided not to use function pointers or multi-threading, when they implemented ALGLIB, because when ALGLIB was first released there was no formal support for multi-threaded programming in any widely-distributed and widely-used language, and not all languages that ALGLIB was targeted to had the same or similar equivalent to the function pointers of C and C++. But MQL5 has function pointers. If you adapt ALGLIB to MQL5, it will be much easier to do this from ALGLIB++, instead, because of the reintegration of the control flow structures.

The ideal solution, however, is to use thread-switching. Eventually, either function pointers or thread-switching will be used in ALGLIB++; we haven't decided yet which way to go.

[Mars Yuan]

LydiaMW:

A few additional notes to the developers of the MQL5 version of ALGLIB:

When you adapted ALGLIB to MQL5, you ran into difficulties with the "RCOMM" routines.

These are effectively multi-threaded routines, where the thread-switching is written directly into the code by:

(1) caching thread-local variables with each entry and exit - and iteration routines carry out potentially millions and billions of call/return cycles!

(2) implementing thread-switching by jumping out of the routine to "pause" on an event, and jumping back into the routine to "resume" after the event - which means a lot of goto's and multiple entry points.

(3) decimating the control-flow structure of these routines in order to put the entry points on the top level in the function body.

When adapting ALGLIB to MQL5 you kept the control flow decimation in place, actually shipping off the code snippets into separate routines. This solution - as you eventually found out - is not maintainable; which has made keeping up with the ALGLIB updates impossible. ALGLIB, itself, got a little behind the curve as well - their RCOMM routines sometimes leave orphan structures and variables from earlier versions.

In ALGLIB++, the control flow structure is reintegrated: entry points jump back into the middle of a loop or other control flow structure where they left off.

There is no caching of thread-local variables; for the time being they've been made static (at the cost of thread-safety - but multi-threading is not formally a part of GPL ALGLIB).

Like ALGLIB, this means there are a lot of goto statements to do all the jumping back and forth; but they are more cleanly organized.

The repairs made in ALGLIB++, by themselves, speed up the routines by about 20-25%, based on our test results.

There are two ways to deal with this architecture to get rid of the goto statements and more properly handle the thread-local variables:

(1) Implement actual thread-switching, which means that the RCOMM routines send out "event" messages (which is what the needf, ... algpowerup flags actually are), and the caller has to set up an event-handler to receive and process the messages. Not sure if MQL5 can produce and handle user-defined events, however.

(2) Use function pointers for the events.

Bear in mind that the RCOMM routines may be nested; and in some cases, they can relay events on to their caller obtained from the RCOMM routines that they themselves call.

The ALGLIB developer(s) decided not to use function pointers or multi-threading, when they implemented ALGLIB, because when ALGLIB was first released there was no formal support for multi-threaded programming in any widely-distributed and widely-used language, and not all languages that ALGLIB was targeted to had the same or similar equivalent to the function pointers of C and C++. But MQL5 has function pointers. If you adapt ALGLIB to MQL5, it will be much easier to do this from ALGLIB++, instead, because of the reintegration of the control flow structures.

The ideal solution, however, is to use thread-switching. Eventually, either function pointers or thread-switching will be used in ALGLIB++; we haven't decided yet which way to go.

Dear   Lydia：

But your ALGLIB ++ library file on github is still in C ++ CPP format. It has not been converted to MQL5 mql. would you provide ALGLIB ++ library file as .mql? Thank you！

[Arthur Albano]

Hi!

I am completely new to ALGLIB. So, I was trying to perform the following task, which is to calculate k² using a script. I can easly do that in Excel, but have no idea how to use a non-linear eqution model with one boxed constraint.

void OnStart()
  {
   const double x[22] = {28.98, 30.48, 30.98, 31.48, 31.98, 32.48, 32.98, 33.48, 33.98, 34.48, 34.98, 35.48, 35.98, 36.48, 36.98, 37.48, 37.98, 38.48, 38.98, 39.98, 40.98, 41.98};
   const double y[22] = {8.26, 7.26, 5.71, 6.15, 5.90, 5.15, 5.03, 4.30, 4.15, 3.30, 2.90, 2.71, 1.96, 1.57, 1.27, 0.90, 0.70, 0.47, 0.33, 0.20, 0.09, 0.06};
   const double w[22] = {2, 8, 2, 2, 2, 1, 11, 12, 24, 12, 6, 12, 21, 7, 74, 51, 159, 385, 171, 109, 18, 18}; //weights
   const double x0 = 37.74; //central value theorem

//model equation
//y = (1/2)*((x^2-2x0x+x0^2+4k^2)^(1/2) + x+x0) - x
//k^2 was calculated as 0.582018800686398, after using Solver in Excel where total error was a minimized sum of w(y-y0)^2
//box constraint k^2>0;
  };

Thanks in advance for reading!