Rank: Administration Groups: Registered, Advanced Member Joined: 23/06/2009(UTC) Posts: 1,740 Was thanked: 318 time(s) in 268 post(s)
|
Thank you Davide , 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!" |
|
|
|
Rank: Guest
Groups: Registered
Joined: 04/07/2015(UTC) Posts: 6,866 Was thanked: 981 time(s) in 809 post(s)
|
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 (210kb) downloaded 45 time(s).
|
1 user thanked Jean Giraud for this useful post.
|
|
|
Rank: Administration Groups: Registered, Advanced Member Joined: 23/06/2009(UTC) Posts: 1,740 Was thanked: 318 time(s) in 268 post(s)
|
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 |
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!" |
|
|
|
Rank: Guest
Groups: Registered
Joined: 04/07/2015(UTC) Posts: 6,866 Was thanked: 981 time(s) in 809 post(s)
|
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 (193kb) downloaded 49 time(s).
|
|
|
|
Rank: Administration Groups: Registered, Advanced Member Joined: 23/06/2009(UTC) Posts: 1,740 Was thanked: 318 time(s) in 268 post(s)
|
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 |
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!" |
|
|
|
Rank: Guest
Groups: Registered
Joined: 04/07/2015(UTC) Posts: 6,866 Was thanked: 981 time(s) in 809 post(s)
|
Originally Posted by: omorr 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 user thanked Jean Giraud for this useful post.
|
|
|
Rank: Guest
Groups: Registered
Joined: 04/07/2015(UTC) Posts: 6,866 Was thanked: 981 time(s) in 809 post(s)
|
Chain code error confirmed.
|
1 user thanked Jean Giraud for this useful post.
|
|
|
Rank: Advanced Member Groups: Registered
Joined: 03/03/2014(UTC) Posts: 418 Was thanked: 125 time(s) in 96 post(s)
|
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 (12kb) downloaded 52 time(s).
|
2 users thanked Alex M. for this useful post.
|
on 27/10/2016(UTC), on 27/10/2016(UTC)
|
|
Rank: Advanced Member Groups: Registered, Advanced Member Joined: 13/01/2012(UTC) Posts: 2,648 Location: Italy Was thanked: 1331 time(s) in 876 post(s)
|
Not sure why it fails in 1.0/1.1, but will works in next version |
If you like my plugins consider to support SMath Studio buying a plan; to offer me a coffee: paypal.me/dcprojects |
2 users thanked Davide Carpi for this useful post.
|
on 27/10/2016(UTC), on 27/10/2016(UTC)
|
|
Rank: Guest
Groups: Registered
Joined: 04/07/2015(UTC) Posts: 6,866 Was thanked: 981 time(s) in 809 post(s)
|
No matter who is getting what: As is not defined
|
1 user thanked Jean Giraud for this useful post.
|
|
|
Rank: Administration Groups: Registered, Advanced Member Joined: 23/06/2009(UTC) Posts: 1,740 Was thanked: 318 time(s) in 268 post(s)
|
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 (17kb) downloaded 47 time(s).Regards, Radovan |
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!" |
|
|
|
Rank: Advanced Member Groups: Registered
Joined: 30/03/2011(UTC) Posts: 393
Was thanked: 132 time(s) in 113 post(s)
|
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 user thanked kilele for this useful post.
|
|
|
Rank: Advanced Member Groups: Registered
Joined: 03/03/2014(UTC) Posts: 418 Was thanked: 125 time(s) in 96 post(s)
|
Originally Posted by: omorr 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 Edited by user 27 October 2016 18:35:38(UTC)
| Reason: Not specified
|
1 user thanked Alex M. for this useful post.
|
|
|
Rank: Administration Groups: Registered, Advanced Member Joined: 23/06/2009(UTC) Posts: 1,740 Was thanked: 318 time(s) in 268 post(s)
|
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 |
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!" |
|
|
|
Rank: Advanced Member Groups: Registered, Advanced Member Joined: 13/01/2012(UTC) Posts: 2,648 Location: Italy Was thanked: 1331 time(s) in 876 post(s)
|
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). Edited by user 28 October 2016 10:51:44(UTC)
| Reason: Not specified |
If you like my plugins consider to support SMath Studio buying a plan; to offer me a coffee: paypal.me/dcprojects |
1 user thanked Davide Carpi for this useful post.
|
|
|
Rank: Administration Groups: Registered, Advanced Member Joined: 23/06/2009(UTC) Posts: 1,740 Was thanked: 318 time(s) in 268 post(s)
|
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 Edited by user 28 October 2016 14:36:35(UTC)
| Reason: Not specified |
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!" |
|
|
|
Rank: Guest
Groups: Registered
Joined: 04/07/2015(UTC) Posts: 6,866 Was thanked: 981 time(s) in 809 post(s)
|
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 (32kb) downloaded 49 time(s). Solve NON-Iterative SIG.sm (45kb) downloaded 47 time(s).Edited by user 29 October 2016 06:10:45(UTC)
| Reason: ethic publishing
|
2 users thanked Jean Giraud for this useful post.
|
on 29/10/2016(UTC), on 29/10/2016(UTC)
|
|
Rank: Administration Groups: Registered, Advanced Member Joined: 23/06/2009(UTC) Posts: 1,740 Was thanked: 318 time(s) in 268 post(s)
|
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 |
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!" |
1 user thanked omorr for this useful post.
|
|
|
Rank: Advanced Member Groups: Registered, Advanced Member Joined: 13/01/2012(UTC) Posts: 2,648 Location: Italy Was thanked: 1331 time(s) in 876 post(s)
|
|
If you like my plugins consider to support SMath Studio buying a plan; to offer me a coffee: paypal.me/dcprojects |
1 user thanked Davide Carpi for this useful post.
|
|
|
Rank: Guest
Groups: Registered
Joined: 04/07/2015(UTC) Posts: 6,866 Was thanked: 981 time(s) in 809 post(s)
|
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
|
|
|
|
Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.