NonlinearSolvers plugin - BDQRF, Bisection, Brent's, Broyden's, Newton-Raphson, Ridder's, Secant, Homotopy - Messages
#201 Posted: 10/24/2016 1:38:03 PM
Thank you Davide 
,
I wish you all the best, and hope this time we will have more success than before.
Radovan
,I wish you all the best, and hope this time we will have more success than before.
Radovan
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
#202 Posted: 10/24/2016 4:48:15 PM
For sure very interesting but incorrect from the onset.
"splines" are not functions, just zombie interpolation.
You can't plug "zombie" in in a vector for ODEsolve or rk solve.
"simply deceiving because deceivingly simple"
Cheers, Jean
Forum Radovan Integral.sm
"splines" are not functions, just zombie interpolation.
You can't plug "zombie" in in a vector for ODEsolve or rk solve.
"simply deceiving because deceivingly simple"
Cheers, Jean
Forum Radovan Integral.sm
1 users liked this post
Radovan Omorjan 10/24/2016 5:12:00 PM
#203 Posted: 10/24/2016 5:31:03 PM
Jean,
I just wanted to point out that in spite of "zombies" which return numbers, we are sometimes forced to use root finding, optimization etc.
You also remind me to put some stress to the many examples you posted here regarding different splines including your comments about it. As you pointed out, splines being zombies or not - we often have to integrate, differentiate etc. using splines. I think there were some example of yours worth making plugin functions from them because, as we know, we often can not do that using the current spline functions inside SMath.
Regards,
Radovan
I just wanted to point out that in spite of "zombies" which return numbers, we are sometimes forced to use root finding, optimization etc.
You also remind me to put some stress to the many examples you posted here regarding different splines including your comments about it. As you pointed out, splines being zombies or not - we often have to integrate, differentiate etc. using splines. I think there were some example of yours worth making plugin functions from them because, as we know, we often can not do that using the current spline functions inside SMath.
Regards,
Radovan
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
#204 Posted: 10/25/2016 12:49:16 AM
You are right Radovan,
Smath splines [ainterp, cinterp, linterp] are "canvas" plotting
and on-line evaluation. They don't create a function thus can't be
use to integrate directly. You have two alternatives:
1. Dicretise/integrate finites differences
2. Transit via Infinitesimal modules
I went as far as I could in the attached. Plotting the components.
The "solve" block fails miserably, why?
It attempts to retrieve back to the integral that Smath does not
produce. The "solve" does not interpret the integral transit because
the solve block is a foreign entity. The Mathcad find(x) looks incorrect.
It depends upon initialisation. In this case the worng checks right.
Though the Mathcad Given/Find is often robust, it failed 1000's times
in my 15 years Mathacd collab.
Mathcad plots your integral, smath does not, thus it reflects in the "solve".
Please don't hesitate to correct me if I can help more.
Cheers, Jean
Forum Radovan Integral.sm
Smath splines [ainterp, cinterp, linterp] are "canvas" plotting
and on-line evaluation. They don't create a function thus can't be
use to integrate directly. You have two alternatives:
1. Dicretise/integrate finites differences
2. Transit via Infinitesimal modules
I went as far as I could in the attached. Plotting the components.
The "solve" block fails miserably, why?
It attempts to retrieve back to the integral that Smath does not
produce. The "solve" does not interpret the integral transit because
the solve block is a foreign entity. The Mathcad find(x) looks incorrect.
It depends upon initialisation. In this case the worng checks right.
Though the Mathcad Given/Find is often robust, it failed 1000's times
in my 15 years Mathacd collab.
Mathcad plots your integral, smath does not, thus it reflects in the "solve".
Please don't hesitate to correct me if I can help more.
Cheers, Jean
Forum Radovan Integral.sm
#205 Posted: 10/25/2016 2:43:38 AM
Hello Jean,
The integral works form me (the recent SMath version)
solve() works for me as well
Why is this working for me and not for you - I do not know.
Regards,
Radovan
The integral works form me (the recent SMath version)
solve() works for me as well
Why is this working for me and not for you - I do not know.
Regards,
Radovan
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
#206 Posted: 10/25/2016 10:07:02 AM
Why is this working for me and not for you - I do not know.
Simple: the solve block of your version is more robust
or the chained code less reactive ? The other curiosity
5346 official release ..... 120 sec
5346 UNofficial release.... 14 sec
I got used to solve failure, rescue dichotomy.
BTW: eval(,) is not needed for f1(x)[faster].
Thanks Radovan, your collaboration is most appreciated.
Jean
1 users liked this post
Radovan Omorjan 10/25/2016 10:57:00 AM
#207 Posted: 10/25/2016 10:20:54 AM
Chain code error confirmed.
1 users liked this post
Radovan Omorjan 10/25/2016 10:57:00 AM
#208 Posted: 10/27/2016 12:02:41 AM
Davide,
Here is an unforunate example of FindRoot() being unable to solve a problems with units... While my very quick NR Line() solver works just fine.
I wonder if we run into max + number problem or devision by zero.
Hoping for a fix!
FindRootBug.sm
Here is an unforunate example of FindRoot() being unable to solve a problems with units... While my very quick NR Line() solver works just fine.
I wonder if we run into max + number problem or devision by zero.
Hoping for a fix!
FindRootBug.sm
2 users liked this post
#209 Posted: 10/27/2016 4:26:45 AM
Not sure why it fails in 1.0/1.1, but will works in next version
If you like my plugins please consider to support the program buying a license; for personal contributions to me: paypal.me/dcprojects
2 users liked this post
#210 Posted: 10/27/2016 9:16:03 AM
No matter who is getting what: As is not defined
1 users liked this post
Radovan Omorjan 10/27/2016 10:58:00 AM
#211 Posted: 10/27/2016 11:10:42 AM
Actually, it could be done - but setting the initial conditions for FindRoot() could be very troublesome for this example.
Initial conditions are chosen just on trial and error, and the calculation can diverge easily by slight changing of IC.
This is basically a second order polynomial having two solutions.
FindRootBug-corr.sm
Regards,
Radovan
Initial conditions are chosen just on trial and error, and the calculation can diverge easily by slight changing of IC.
This is basically a second order polynomial having two solutions.
FindRootBug-corr.sm
Regards,
Radovan
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
#212 Posted: 10/27/2016 11:55:32 AM
Excuse the off-topic: Could IC be readjusted iteratively depending on the expected results of the solution? IC auto-exploration so to speak. If solutions tend to behave like this then change IC like that,etc
1 users liked this post
Radovan Omorjan 10/27/2016 2:56:00 PM
#213 Posted: 10/27/2016 12:12:28 PM
Actually, it could be done - but setting the initial conditions for FindRoot() could be very troublesome for this example.
Initial conditions are chosen just on trial and error, and the calculation can diverge easily by slight changing of IC.
This is basically a second order polynomial having two solutions.
Regards,
Radovan
Is there a reason why solver would gravitate to wards a solution further from initial guess? If it were just to follow the slope at the initial guess value it would arrive to the closer, and in my case correct, solution
So far in my expirience it is almost always possible to make FindRoot() solve by substituting just the right value. There has to be a reaon why the function tends to overshoot nearest solution by so much. Also when it does not find a desired solution, the number it spits out is not always a mathematical solution either
1 users liked this post
Radovan Omorjan 10/27/2016 2:56:00 PM
#214 Posted: 10/28/2016 2:30:42 AM
Hello,
We might say that often some numerical procedures (especially nonlinear) may "go nuts" sometimes and give the unrealistic solutions. Therefore, we have to have the ability to use few of them for the same task. In this plugin there are many procedures for root finding we could use beside FindRoot(), but they are not working at the moment (or I do not know how to use them anymore).
Regards,
Radovan
We might say that often some numerical procedures (especially nonlinear) may "go nuts" sometimes and give the unrealistic solutions. Therefore, we have to have the ability to use few of them for the same task. In this plugin there are many procedures for root finding we could use beside FindRoot(), but they are not working at the moment (or I do not know how to use them anymore).
Regards,
Radovan
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
#215 Posted: 10/28/2016 4:41:14 AM
IC are a very sensible parameter in nonlinear solvers; you might know in advance an expected "order of magnitude" and the results still diverge because locally the function is too much or not enough steeper (or because there is another solution close).
For single variable problems I plan to add these algorithms, in which solutions are bounded in a range. Even, I guess would be possible to add some kind of "filter" to discard some solution (however, would be a replacement for something that should be done in any case: sanity check if the result fits personal needs).
For single variable problems I plan to add these algorithms, in which solutions are bounded in a range. Even, I guess would be possible to add some kind of "filter" to discard some solution (however, would be a replacement for something that should be done in any case: sanity check if the result fits personal needs).
If you like my plugins please consider to support the program buying a license; for personal contributions to me: paypal.me/dcprojects
1 users liked this post
Radovan Omorjan 10/28/2016 4:54:00 AM
#216 Posted: 10/28/2016 4:56:38 AM
Thank you Davide
This is exactly I was talking about - many different methods for the same task.
It would be very encouraging (less frustrating I hope) to have all those methods at our disposal as functions incorporated in plugins .
Best Regards,
Radovan
This is exactly I was talking about - many different methods for the same task.
It would be very encouraging (less frustrating I hope) to have all those methods at our disposal as functions incorporated in plugins .
Best Regards,
Radovan
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
#217 Posted: 10/28/2016 8:17:19 PM
Thanks Davide: I fell in love with SIG !
Yes Radovan: a "Peak/Deep/Root" in the menu would be great,
c/w different options. As robust they will look at the design
stage, they will not be so. Read again "ULP".
Going back to "FindRoot": as it looks in similar applications,
it is same or so Mathcad, a very universal code. For the free
finding solutions, IC must be either 0 or 1 [1 to releive from
"divide by zero"]. In examples [1,2] notice the switch of the
solutions. Be careful as it may scrap the project !
Examples [2, 3], Quaternion and Frobenius are robust and correct.
I didn't completely understand Alex example/problem. A case of
constrained IC difficult to handle and prone to fail.
Cheers, Jean
Solve Given_Find [UN test Robutness].sm
Solve NON-Iterative SIG.sm
Yes Radovan: a "Peak/Deep/Root" in the menu would be great,
c/w different options. As robust they will look at the design
stage, they will not be so. Read again "ULP".
Going back to "FindRoot": as it looks in similar applications,
it is same or so Mathcad, a very universal code. For the free
finding solutions, IC must be either 0 or 1 [1 to releive from
"divide by zero"]. In examples [1,2] notice the switch of the
solutions. Be careful as it may scrap the project !
Examples [2, 3], Quaternion and Frobenius are robust and correct.
I didn't completely understand Alex example/problem. A case of
constrained IC difficult to handle and prone to fail.
Cheers, Jean
Solve Given_Find [UN test Robutness].sm
Solve NON-Iterative SIG.sm
2 users liked this post
#218 Posted: 10/29/2016 11:37:11 AM
Just for the record (especially for Davide) FindRooot() just does not work in the recent SMath for few of your examples with the error like in the picture. Actaually, it does work when you change the IC from zero to some other values.
Regards,
Radovan
Regards,
Radovan
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
1 users liked this post
Davide Carpi 10/29/2016 12:28:00 PM
#219 Posted: 10/29/2016 12:24:52 PM
If you like my plugins please consider to support the program buying a license; for personal contributions to me: paypal.me/dcprojects
1 users liked this post
Radovan Omorjan 10/29/2016 1:50:00 PM
#220 Posted: 10/29/2016 2:14:57 PM
That's not a bug Radovan:
=>...For the free finding solutions, IC must be either 0 or 1
[1 to releive from "divide by zero"]<= ... {previous message}
Maybe you are not up to date vs Davide ?
Jean
=>...For the free finding solutions, IC must be either 0 or 1
[1 to releive from "divide by zero"]<= ... {previous message}
Maybe you are not up to date vs Davide ?
Jean
-
New Posts
-
No New Posts