MaplePrimes - answers and comments on Question, Arbitrary Close Solutions in fsolve

using avoid

acer — Sun, 10 Feb 2013 07:57:17 Z

If I understand the issue rightly, then you might be able to use fsolve's `avoid` option to find (potentially) up to all three roots. And then you could just pick whichever of those had the least `t` value.

I'm not sure that I understand why Digits=180 is necessary.

The method I've outlined will have to be allowed to fail out, by which I mean that at every iteration if will have to be allowed to search until it hits its own internal number-of-attempts-limit. This means that it will run slower as a whole.

When using a type-check to test the return value from fsolve computed at the top-level, you should use eval(soln,1), If you don't then in the case that fsolve failed the returned unevaluated `fsolve` call will get re-evaluated by virtue of its being an argument in the call to `type`.

billiard_simulatio_m.mw

Let me know if I've misunderstood.

acer

ps.

acer — Sun, 10 Feb 2013 08:14:02 Z

ps. If the suggested process makes sense, then you could tweak it a little so that it stopped looking when 3 roots were found (at a given iteration). That would save a bit of time. But it would still involve the costly fail-out for any iteration at which there were only eactly 1 or 2 roots. This is all under the assumption that, as you wrote, there are 3 roots at most for each iteration.

acer

Arbitrarily close

Carl Love — Sun, 10 Feb 2013 15:01:18 Z

Acer said:
> I'm not sure that I understand why Digits=180 is necessary.

Perhaps when the Asker said that the solutions were arbitrarily close, s/he meant that they could not be distinguished at a lower value of Digits. Perhaps an approach is needed where Digits is gradually pushed up until they can be distinguished. And perhaps this theorem will be useful:

r is a multiple root of f(r) iff D(f)(r) = 0.

So, if D(f)(r) is close to 0 (say, it fnormals to 0), then increase Digits, and redo the fsolve in a very narrow window, whlle avoiding r.

three close roots

acer — Sun, 10 Feb 2013 19:47:11 Z

@Carl Love I don't quite see how this guards against the situation that all three roots are close. If they are, then it might generate the 2nd and 3rd "highest-in-t" roots.

I don't see how to compute safely which narrow `t` range to use, either, or how high Digtit has to be at the nth step. Unless there is some more knowledge, such as (making this up now) that the close root pairs get closer from iteration to iteration, the Digits from the nth is always enough to resolve the (n+1)th close pair, the 3rd root is not as close, etc, then I don't see much that is as safe as trying to find (potentially) all three roots.

I haven't studied the modeling though. There may be justifications, based on the math.

@Carl Love your right, as far as I can

jschulzb — Sun, 10 Feb 2013 19:57:09 Z

@Carl Love your right, as far as I can tell, the solutions may be so close together fsolve cant tell them apart. So
if I start at a solution of:
t=0.00005, theta=0.00005 and the REAL next solution is
t=0.0000500001, theta= 0.0000500001,

fsolve may skip it to find something like
t=0.003, theta=0.003

(I call this teleporting) This only occurs when there exist more than one solution. In my case there are either 1 or 3 solutions which partially depend on the time (t). (Even if time allows for mulitple solutions, the trajectory of the ball may not)