|
The "x_odesolverstate_get_needdy()" function - sounds like it's the MQL5 off-shoot of Alglib. In the C++ version, this is just the variable "needdy". For the following, I will use the names given in the C++ version.
Most of the iteration routines in Alglib are set up in the same way, which I will describe in detail here:
(1) There is a low-level stepper routine in the implementation layer (which is the alglib_impl namespace in the C++ version).
(2) It is mirrored by a top-layer routine (in the alglib namespace, in the C++ version) which, though present, is not officially part of the API and is not documented. For differential equations, this is the odesolveriteration() routine.
(3) There is also a driver iteration routine in the top-layer which, itself, provides an example of and template for the use of the stepper routine. For differential equations, this is the odesolversolve() routine. Notice, by the way, that it uses the "needdy" flag.
(4) Other examples demonstrating the use of the low-level stepper routines may be found in the test_c file. The examples using odesolveriteration() do not use "needdy".
(5) All stepper routines have both an initial entry point and one, two or more re-entry points, as well as a final exit point.
(6) They all return "true" to indicate that they are awaiting re-entry, and return "false" to indicate that they have reached the final exit point.
(7) Correspondingly, a driver routine for the stepper routine will normally be written as a while loop that continually re-enters the stepper routine after taking some appropriate action, until the stepper routine indicates a final exit.
(8) An internal variable (usually named something-something-"stage") indicates which point of re-entry to resume execution at.
(9) A set of one, two or more flags, generally exist to indicate what the stepper routine is waiting on. Many of them are named "need"-something to indicate what it needs, some of them are status flags to indicate what it is reporting. For differential equations, there is only one flag, "needdy", so it is technically redundant.
(10) Correspondingly, the driver routine may be set up as a while loop with an if-else if-else if-...-else branch tree to direct action based on which flag was raised. For odesolveriteration() this is not necessary (though the possibility always exists that in later version, more flags could be added, so that it becomes necessary). All of the driver routines in the top-layer are set up that way ... with function pointers ... while the examples in test_c are usually set up as driver loops with the code directly embedded in the loop.
(11) For the odesolveriteration(), as you may infer by examining the code for odesolversolve() or for the examples in test_c, odesolveriteration() is providing a value x and a vector y[] of function values (y[i] = f_i(x)), awaiting a vector dy[] of values for the vector (dy[i] = f_i'(x,y)). It's awaiting the total differentials f_i'(x,y) of the functions f_i(x) evaluated at x and y[]. Both x[] and y[] may be used in the calculation of dy[], as we're talking about differential equations here! (e.g. s'(x) = c(x), c'(x) = -s(x) could be set up as dy[0] = y[1] and dy[1] = -y[0]) ... which is what one of the examples in test_c is doing. The other example in test_c does dy[0] = max(x - 1, 0), for the differential equation f'(x) = max(x - 1, 0).
(12) In odesolversolve(), this is already supplied as one of its function pointer parameters ("diff"), which it expects the caller to provide. I don't know how MQL5 handles that, how it implements odesolversolve(), nor it if has function pointers.
(13) In a hand-written version of the driver routine, you either have to supply your own function or the code for the derivative in the driver routine, itself ... or as a function pointer, if you design it in a way similar to odesolversolve(). The two routines in test_c directly implement the code in the driver loop. In C++, one can also use lambdas - C++ now supports anonymous functions-as-values. I don't know what MQL5 has, in the way of similar facilities.
(14) As a final note: alglib_note, though ostensibly written in C, is written to compile in C++ (at least in the C++ version). So, lambdas are perfectly fine for use here, in driver routines, if you use the C++ version. C++, however, is not as widely available for embedded systems, as is C, though that has changed substantially in recent years.
The main reason things were set up this way is that Alglib originated in a time before official support for multi-threaded programming was included in the standards of languages like C, C++, C# (or even Python, I believe). For C and C++ this was around 2011. The library has not kept up to date, in that respect, and it would probably be difficult for it to do, since the code is, itself, generated (from an internal language called "AlgoPascal", I believe), and that requires updating the translator too - which is not a trivial task. In another, more important, respect it has not been kept up to date: some of the Windows-version functions used in associated with multi-threading (mostly in the test_c file) are now deprecated and need to be replaced. And, again, I don't know what the corresponding situation is for MQL5, if that's what you are using.
|
Login
Register
FAQ
Search
