hey w3b5urf3e, I see on the pic that you want to implement Brent, what about the BDQRF method mentioned on your Bisection testings file? they state that BDQRF is better than Brent

Hello w3b5urf3r

I am trying to figure out this regarding eval(). I do not get it. It is quite not logical to me. For instance, we can make a function in this way

f(x):line(a:x,y:eval(a^2+5*a-3),2,1)

We can call it and get the result

f(-2)=-9 f(2)=11

But can not use it here

Bisection(f(x#),-9,0,10^{-5},50)=#@#

If we remove eval(), everything is fine

f(x):line(a:x,y:a^2+5*a-3,2,1)

Bisection(f(x#),-9,0,10^{-5},50)=-5.5414

There are functions like Bisection() that actually need the function value regardless the expression behind that function. Moreover, eval() has proven to be sometimes very useful in order to increase the calculation speed dramatically. I think this would be quite a restriction if we could not use it in the situation like these. I suppose that is due to the SMath design and its symbolic engine. I think this is quite a disadvantage regarding the strictly numerical computations and just hope that something could be done about it.

Regards,
Radovan

Edited by user 08 September 2012 17:59:00(UTC)  | Reason: Not specified

Hello w3b5urf3r,

Thank you for your explanation and the updated plugin ancing:

Best Wishes,
Radovan

Plugin updated.

Added the Newton-Raphson method for Nonlinear systems of equations and the Bisected Direct Quadratic Regula Falsi method.


regards,

w3b5urf3r

Hello w3b5urf3r,

Do not have anything to say, but keep up this way

I hope you would not mind if I suggest you to change your convergence criterion in the root finding functions.
The convergence criterion at the moment is that the absolute function value in some iteration to be smaller than epsilon


abs(f(P3))<epsilon

This is the simplest convergence criterion. Sometimes it is not good enough. To make that stronger you could add, for instance, that the absolute relative difference of two iteration be smaller than epsilon as well.


(abs(f(P3))<epsilon)&(abs({P3-P2}/{P3+epsilon})<epsilon)

The epsilon in the denominator is in the case the solution is zero.

Regards,
Radovan

I've forgot to swap the indices of the jacobian derivatives after the debugging, plugin reupdated...




I know, but I'm trying to pay attention to the management of functions with unit of measurement... although I have not advertised this behavior, actually all solvers shown below works also with units. Introducing new covengence criteria preserving this aspect implies a more advanced error handling (and developping time)...


regards,

w3b5urf3r

Edited by user 11 September 2012 02:36:31(UTC)  | Reason: Not specified

You are right and I respect that

Regards,
Radovan

Hello,

Some more testings and surprises. I attached one of my files and tried all the nonlinear solvers including the SMath solve, roots() and all of them made by w3b5urf3r up to now

I attached a part of my file (primer63w.sm). Here is another situation regarding SMath optimization. The first picture is when the Symbolic Optimization of the function is applied. Everything seems to be fine (although two functions failed - roots(),NewtonRaphosn()). Strangely, when the Optimization is none, numeric - all of them failed and just look at the second picture - now the result of f(1000) is a vector and not scalar as before. This is due to the situation where we have the product of two vector - the result should be a scalar (scalar product of two vectors). When we change some Optimization in the file we can even get the result as in the third picture - solve() gave the result but the other two solvers have different results than solve(). Something must be strange here because other solvers failed. The main problem here is that SMath sometimes returns scalar and sometimes vector depending on optimization applied (fourth and fifth picture on the next post). I think I made some mistakes but can not figure out what happened here.

Could someone take a look at this please.

Regards,
Radovan

Edited by user 13 September 2012 18:51:49(UTC)  | Reason: Not specified

Hi omorr

seems there are many little issues (see the attachment)...

if you use a line in the definition of funh(T), the behavior changes further


regards,

w3b5urf3r

Plugin updated.

added HRE(...) and HRE.B(...) (Homotopy root estimation using NewtonRaphson and Broyden, respectively);

fixed issues of internal variable parser with differentiations.

EDIT: Plugin reuploaded with support for unassigned variables named with apostrophe (f.e. x')


regards,

w3bsurf3r

Edited by user 15 September 2012 00:19:20(UTC)  | Reason: Not specified