Libraries: ALGLIB - Numerical Analysis Library - page 4

New comment
 
Yury Kulikov:

Beautiful MQ! Serious work!

An example of using the library is teaching MLP neural network the multiplication table.


:( I'm afraid to think what will happen to the cloud when users start actively using the library in their experts.
This simple script weighs under a megabyte.


The same but for RF:

counts not so accurate, I should try to tweak it

#include <Math\Alglib\dataanalysis.mqh>
//+------------------------------------------------------------------+
#define _rand(min,max) ((rand()/(double)SHORT_MAX)*((max)-(min))+min)
//+------------------------------------------------------------------+
void OnStart()
{
   CDecisionForest      Trf;
   CDecisionForestShell RFshell;
   CMatrixDouble        PatternsMatrix;
   CDFReport            RF_report;
   int RFinfo;
   double vector[2], out[1];
   
   // data preparation
   PatternsMatrix.Resize(100,3);
   int m=0;     // first pattern
   for(int i=1; i<=10; i++)
      for(int j=1; j<=10; j++)
      {
         PatternsMatrix[m].Set(0,i/10.0);       // input 1
         PatternsMatrix[m].Set(1,j/10.0);       // input 2
         PatternsMatrix[m].Set(2,(i*j)/100.0);  // target
         m++; //next pattern
      }
   // RF Creation.
   CDForest::DFBuildRandomDecisionForest(PatternsMatrix,100,2,1,50,0.4,RFinfo,Trf,RF_report);
   Print("Info=",RFinfo,"  Error=",CDForest::DFAvgError(Trf,PatternsMatrix,100));  
   // check the network on integer data
   string s="Test 1 >> ";
   for(int i=1; i<=10; i++)
   {
      int d1=(int)_rand(1,10), d2=(int)_rand(1,10);
      vector[0]=d1/10.0;
      vector[1]=d2/10.0;
      CDForest::DFProcess(Trf,vector,out);
      s+=(string)d1+"*"+(string)d2+"="+DoubleToString(out[0]*100,0)+" // ";
   }
   Print(s);
   // check the network on fractional data
   s="Test 2 >> ";
   for(int i=1; i<=5; i++)
   {
      double d1=NormalizeDouble(_rand(1,10),1), d2=NormalizeDouble(_rand(1,10),1);
      vector[0]=d1/10.0;
      vector[1]=d2/10.0;
       CDForest::DFProcess(Trf,vector,out);
      s+=DoubleToString(d1,1)+"*"+DoubleToString(d2,1)+"="+DoubleToString(out[0]*100,2)+
         "("+DoubleToString(d1*d2,2)+") // ";
   }
   Print(s);
}
2017.09.04 21:43:21.609 RF sample (EURUSD,H1)   Info=1  Error=0.01861400000000001
2017.09.04 21:43:21.610 RF sample (EURUSD,H1)   Тест 1 >> 6*9=55 // 7*3=21 // 6*6=38 // 9*7=65 // 9*9=80 // 8*4=32 // 4*1=6 // 1*8=13 // 4*3=12 // 2*2=5 // 
2017.09.04 21:43:21.610 RF sample (EURUSD,H1)   Тест 2 >> 7.7*5.8=46.64(44.66) // 3.0*3.3=9.70(9.90) // 6.0*9.2=55.32(55.20) // 2.6*6.7=20.08(17.42) // 2.5*4.0=12.54(10.00) //

PS

CDForest::DFBuildRandomDecisionForest(PatternsMatrix,100,2,1,500,1,RFinfo,Trf,RF_report);

it is more accurate, 500 ancient and r=1, more fitting and less noise.

2017.09.04 22:08:33.227 RF sample (EURUSD,H1)   Info=1  Error=2.02997341158806 e-15
2017.09.04 22:08:33.228 RF sample (EURUSD,H1)   Тест 1 >> 2*2=4 // 2*6=12 // 1*9=9 // 9*1=9 // 4*7=28 // 9*6=54 // 5*6=30 // 5*5=25 // 4*1=4 // 1*4=4 // 
2017.09.04 22:08:33.230 RF sample (EURUSD,H1)   Тест 2 >> 4.0*3.8=16.00(15.20) // 9.6*3.1=30.00(29.76) // 5.5*6.4=36.00(35.20) // 4.0*4.4=16.00(17.60) // 1.6*4.2=8.00(6.72) //
 
Maxim Dmitrievsky:


Same thing for RF:

Considers not as accurate, need to try to tweak it

PS

this way is more accurate, 500 trees and r=1, more fitting and less noise.

I wonder how many trees you need to make to make the results accurate? And it is the simplest multiplication table, and if there are several functions, we need to run through RF and not the multiplication table, then the answer will obviously resemble something fair from afar?
 
The MQL5 library is indeed very powerful, it is indeed how to call the library in more detail
 

Forum on trading, automated trading systems and testing trading strategies

Errors, bugs, questions

Andrey Khatimlianskii, 2019.01.30 04:57 AM

MQL5\Include\Math\AlgLib\dataanalysis.mqh - CLinReg::LRLine does not work for 1M and more values?

Does anyone know?

 

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.

 

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.

LydiaMarieWilliamson/ALGLIB_cpp
LydiaMarieWilliamson/ALGLIB_cpp
  • LydiaMarieWilliamson
  • github.com
Dismiss Join GitHub today GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together. Sign up Permalink
 
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.

 
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！

 

Dear developers, please add a method for calculating the conjugate number of a complexnumber to the complex structure ( source in SB <Math\Alglib\complex.mqh>).

My version:

   //--- operations
   void              Copy(const complex &rhs);
   bool              Eq(const complex &lhs, const complex &rhs);
   bool              NotEq(const complex &lhs, const complex &rhs);
   complex           Add(const complex &lhs, const complex &rhs);
   complex           Sub(const complex &lhs, const complex &rhs);
   complex           Mul(const complex &lhs, const complex &rhs);
   complex           Div(const complex &lhs, const complex &rhs);
   complex           Conjugate(void) const;


................


//+------------------------------------------------------------------+
//| Conjugate|
//+------------------------------------------------------------------+
complex complex::Conjugate(void) const
  {
   complex complex_val(re,-im);
   return complex_val;
  };


After the next release of a new build, you have to roll back to your previousrevision. Which is inconvenient.

 
Denis Kirichenko:

Dear developers, please add a method of calculating the conjugate number of a complexnumber to the complex structure ( source in SB <Math\Alglib\complex.mqh>).

My version:


After the next release of a new build, you have to roll back to your previousrevision. Which is inconvenient.

Added

1234567
New comment