Didn't find an explicit alglib topic, thus I post this here:

It seems that the convolution function from the alglib plugin does not care for the second and fourth arguments (problem size in alglib ). I guess that the problem size is nothing else than the size of the 1st and 3rd arguments, thus they are obsolete.

If that is correct than I suggest to provide a convr1d(2) function.
BTW, a real symmetric eigensolver would be fine...

It seems that the alglib license does not allow for inclusion of the plugin in any smath distribution, except if someone buys a commercial license.

[Moderator]: Moved.

---

conv.sm (6 КиБ) скачан 170 раз(а).

AlgLib 3.1x

---

Functions list: al_airy(), al_beta(), al_convr1d(), al_convr1dinv(), al_fftc1d(), al_fftc1dinv(), al_nleqsolve(), al_rkckadapt(), al_polyroots().


[albumimg]81[/albumimg] [albumimg]83[/albumimg] [albumimg]121[/albumimg] [albumimg]1546[/albumimg] [albumimg]1585[/albumimg]
[albumimg]1560[/albumimg] [albumimg]1547[/albumimg] [albumimg]1561[/albumimg] [albumimg]1562[/albumimg] [albumimg]1563[/albumimg]

Examples:

alglib.ode.integrate.sm (11 КиБ) скачан 94 раз(а).
alglib.ode.kinetic1.sm (7 КиБ) скачан 141 раз(а).
alglib.ode.kinetic2.sm (10 КиБ) скачан 120 раз(а).
alglib.ode.kinetic3.sm (10 КиБ) скачан 126 раз(а).
alglib.ode.test1.sm (10 КиБ) скачан 137 раз(а).
alglib.ode.test2.sm (10 КиБ) скачан 119 раз(а).
alglib.ode.Amplitude detector.sm (19 КиБ) скачан 123 раз(а).

alglib.ode.integrate.pdf (92 КиБ) скачан 100 раз(а).
alglib.ode.kinetic1.pdf (75 КиБ) скачан 123 раз(а).
alglib.ode.kinetic2.pdf (89 КиБ) скачан 110 раз(а).
alglib.ode.kinetic3.pdf (83 КиБ) скачан 111 раз(а).
alglib.ode.test1.pdf (85 КиБ) скачан 108 раз(а).
alglib.ode.test2.pdf (89 КиБ) скачан 107 раз(а).
alglib.ode.Amplitude detector.pdf (147 КиБ) скачан 114 раз(а).

Fourier series coefficients.sm (28 КиБ) скачан 166 раз(а).
Fourier series coefficients.pdf (170 КиБ) скачан 140 раз(а).

Links:

1. ALGLIB

Wrote

It seems that the convolution function from the alglib plugin does not care for the second and fourth arguments (problem size in alglib ). I guess that the problem size is nothing else than the size of the 1st and 3rd arguments, thus they are obsolete.

If that is correct than I suggest to provide a convr1d(2) function.

I think it's best to follow the description in the source code (see doc.pdf). I corrected the behavior of the function and added an inverse function convr1dinv().

Wrote

I think it's best to follow the description in the source code (see doc.pdf). I corrected the behavior of the function and added an inverse function convr1dinv().

Uni, thanks for the update. Now the function convr1d seems to insist on providing the correct vector sizes as arguments. This is not really an improvement unless values differing from the actual length can be provided for some magic purpose. I did not find any such hint in the doc. Thus, in order to keep the argument list lean, I would recommend to have
[MATH]convr1d(f;g)[/MATH] and let the interface determine the sizes as in the previous version.

However, I do not want to distract you from progress in the xyplot-plugin!

Martin

Wrote

Wrote

I think it's best to follow the description in the source code (see doc.pdf). I corrected the behavior of the function and added an inverse function convr1dinv().

Thus, in order to keep the argument list lean, I would recommend to have
[MATH]convr1d(f;g)[/MATH] and let the interface determine the sizes as in the previous version.

Ok, I'll add this too. It seems to me that I need to follow the documentation to describe the interfaces of functions.

Wrote

Wrote

Thus, in order to keep the argument list lean, I would recommend to have
[MATH]convr1d(f;g)[/MATH] and let the interface determine the sizes as in the previous version.

Ok, I'll add this too. It seems to me that I need to follow the documentation to describe the interfaces of functions.

Thanks for considering the change. This would perhaps apply to the other integral transforms as well. When providing sort of convr1d(2), then you could add a hint to the doc string that the size parameters in alglib are determined from the actual size).

The alglib version of the Beta function seems o return values if one argument is negative despite of the docs limiting the range to posive arguments. Also, in contrast to the implementation in the StatisticalTools Plugin, the function cannot handle complex numbers.

I added the plugin to the inofficial SMath distribution.

After a look at the alglib license I feel safe to do so. The available functions are (at least a little) documented in the Handbook based on alglib docs and examples by uni.

---

Updated. al_convr1d(2), al_convr1dinv(2) added.

[albumimg]116[/albumimg]

Wrote

Updated. al_convr1d(2), al_convr1dinv(2) added.

Thanks for implementing the proposal.

On my system, Example 2.sm fails to run correctly. If I replace the al_convr1dinv(4) by al_convr1dinv(2) then it is ok. My handbook examples show the same effect, on top of that, in conv.sm, there is an xy-plot-region throwiing an critical error. It does not recover, even if I fix the convolution problem with the new (2)-call. conv1.sm is the fixed version.

---

conv1.sm (11 КиБ) скачан 109 раз(а).

Updated. al_nleqsolve() function added (Levenberg-Marquardt-like nonlinear solver).

This algorithm solves system of nonlinear equations F(x).

Parameters:

[albumimg]121[/albumimg] [albumimg]123[/albumimg]

Thank you uni for this one

I could see that al_nleqsolve() will not work with

[MATH=eng]f(v):eval(F(el(v,1),el(v,2),el(v,3)))[/MATH]

[MATH=eng]j(v):eval(Jac(el(v,1),el(v,2),el(v,3)))[/MATH]

Is there any way to make this possible?

Regards,
Radovan

I think it is not necessary, since the function within itself already performs this. I need more examples. Try this solver at work.

Wrote

I think it is not necessary, since the function within itself already performs this. I need more examples. Try this solver at work.

I just have some frustrating experience when the Jacobian is involved, and would rather appreciated some "derivative free" algorithms of this kind.

Here is just a playing with the NonlinearSolver plugin which includes Levenberg-Marquard algorithm and this one in AlgLib. For this particular example all performed quite well.

[albumimg]122[/albumimg]

Regards,
Radovan

Wrote

Wrote

I think it is not necessary, since the function within itself already performs this. I need more examples. Try this solver at work.

I just have some frustrating experience when the Jacobian is involved, and would rather appreciated some "derivative free" algorithms of this kind.

Here is just a playing with the NonlinearSolver plugin which includes Levenberg-Marquard algorithm and this one in AlgLib. For this particular example all performed quite well.

[albumimg]122[/albumimg]

Regards,
Radovan

Thank you, Radovan. Unfortunately, this interface is defined by the function.

[albumimg]123[/albumimg]

Updated. al_rkckadapt() function added (Runge-Kutta-Cash-Karp adaptive ODE solver).

You can compare with the examples from here: Using the AlgLib ODE (Runge-Kutta) Solver with Excel.

[albumimg]228[/albumimg] [albumimg]230[/albumimg] [albumimg]231[/albumimg] [albumimg]229[/albumimg]

Updated. Source code refactoring.

Updated to AlgLib 3.14, refactored.



al_nleqsolve.sm (15 КиБ) скачан 113 раз(а).
al_nleqsolve.pdf (41 КиБ) скачан 103 раз(а).

Wrote

Updated to AlgLib 3.14, refactored

Thanks UNI, works fine 6179.

Jean

Some problem in the latest plugin. Another solver f_nrk(...) works fine.
x is formal parameter, how I can define it ? Optimization is numerical, the same for both solvers.

I need a complete example.

Hello uni,
Unfortunately I can't provide complete example, but if I pass to solver copy-pasted copies of the equations, it works.
See it below. The problem is that plugin can't read correct result of symbolic calculations, but solver written in Smath does it right.

example.sm (48 КиБ) скачан 105 раз(а).