NonlinearSolvers plugin - BDQRF, Bisection, Brent's, Broyden's, Newton-Raphson, Ridder's, Secant, Homotopy - Сообщения
#201 Опубликовано: 24.10.2016 13:38:03
325 сообщений из 2 052 понравились и 1 не понравились пользователям.
Группа: Moderator
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 Опубликовано: 24.10.2016 16:48:15
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 пользователям понравился этот пост
Radovan Omorjan 24.10.2016 17:12:00
#203 Опубликовано: 24.10.2016 17:31:03
325 сообщений из 2 052 понравились и 1 не понравились пользователям.
Группа: Moderator
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 Опубликовано: 25.10.2016 00:49:16
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 Опубликовано: 25.10.2016 02:43:38
325 сообщений из 2 052 понравились и 1 не понравились пользователям.
Группа: Moderator
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 Опубликовано: 25.10.2016 10:07:02
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 пользователям понравился этот пост
Radovan Omorjan 25.10.2016 10:57:00
#207 Опубликовано: 25.10.2016 10:20:54
Chain code error confirmed.
1 пользователям понравился этот пост
Radovan Omorjan 25.10.2016 10:57:00
#208 Опубликовано: 27.10.2016 00:02:41
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 пользователям понравился этот пост
#209 Опубликовано: 27.10.2016 04:26:45
![2016-10-27 09_19_33-SMath Studio - [FindRootBug.sm_].png](/ru-RU/files/Download/YsmTTL/2016-10-27-09_19_33-SMath-Studio---[FindRootBug.sm_].png)
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 пользователям понравился этот пост
#210 Опубликовано: 27.10.2016 09:16:03
No matter who is getting what: As is not defined
1 пользователям понравился этот пост
Radovan Omorjan 27.10.2016 10:58:00
#211 Опубликовано: 27.10.2016 11:10:42
325 сообщений из 2 052 понравились и 1 не понравились пользователям.
Группа: Moderator
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 Опубликовано: 27.10.2016 11:55:32
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 пользователям понравился этот пост
Radovan Omorjan 27.10.2016 14:56:00
#213 Опубликовано: 27.10.2016 12:12:28
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 пользователям понравился этот пост
Radovan Omorjan 27.10.2016 14:56:00
#214 Опубликовано: 28.10.2016 02:30:42
325 сообщений из 2 052 понравились и 1 не понравились пользователям.
Группа: Moderator
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 Опубликовано: 28.10.2016 04:41:14
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 пользователям понравился этот пост
Radovan Omorjan 28.10.2016 04:54:00
#216 Опубликовано: 28.10.2016 04:56:38
325 сообщений из 2 052 понравились и 1 не понравились пользователям.
Группа: Moderator
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 Опубликовано: 28.10.2016 20:17:19
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 пользователям понравился этот пост
#218 Опубликовано: 29.10.2016 11:37:11
325 сообщений из 2 052 понравились и 1 не понравились пользователям.
Группа: Moderator
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 пользователям понравился этот пост
Davide Carpi 29.10.2016 12:28:00
#219 Опубликовано: 29.10.2016 12:24:52
![2016-10-29 17_26_47-SMath Studio - [fenov.sm_].png](/ru-RU/files/Download/SdnnEk/2016-10-29-17_26_47-SMath-Studio---[fenov.sm_].png)
If you like my plugins please consider to support the program buying a license; for personal contributions to me: paypal.me/dcprojects
1 пользователям понравился этот пост
Radovan Omorjan 29.10.2016 13:50:00
#220 Опубликовано: 29.10.2016 14:14:57
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
-
Новые сообщения
-
Нет новых сообщений