FindRoot with NDSolve inside of it doesn't work
in [Mathematica]
|
From: Sam Takoy on 29 Jul 2010 06:42 Thank you as always. Perfect. ________________________________ From: Leonid Shifrin <lshifr(a)gmail.com> To: Sam Takoy <sam.takoy(a)yahoo.com>; mathgroup(a)smc.vnet.net Sent: Wed, July 28, 2010 2:52:56 PM Subject: Re: FindRoot with NDSolve inside of it doesn't work Sam, The difference is that in your last example with exponents the r.h.s of the function does not necessarily involve numerical steps, while when you invoke NDSolve, it does. So, for functions of the former type, you can get away with generic patterns, while for functions of the latter type you can not. This is related to the order in which expressions are evaluated. Inside FindRoot there is f[x0, y0] == {2.7, 5.4}. When this is evaluated, first f[x0, y0] is evaluated. If you have generic patterns x_,y_ in the definition of <f>, then the definition for <f> happily applies at this moment, while x0 and y0 are still symbolic. This is wrong since then NDSolve can not do its job and returns back the set of equations. To postpone the evaluation of <f> until numeric values are supplied by FindRoot in place of x0, y0, we restrict the pattern. Then, evaluation of f[x0, y0] == {2.7, 5.4} just yields back f[x0, y0] == {2.7, 5.4}, since the pattern is not matched by symbolic x0,y0, and then later x0 and y0 are bound to (replaced by) the numeric values generated by FindRoot, which results in correct execution. Cases where one needs to use this trick are interesting since the interaction between built-in functions (FindRoot here) and user - defined ones (f here) mediated by this trick are rather non-trivial. In some sense, we go a little under the hood of the built-in commands here. However they work, we know for sure that they are bound to call Mathematica evaluator on <f> at some point since <f> was defined at top level. And that means that we have all the usual possibilities to alter that part of evaluation that the evaluator normally gives us. Now, since FindRoot holds all its arguments, one may ask why does it not bind equations to numerical arguments right away. My guess is that sometimes it attempts to do some symbolic preprocessing with the equations, a possibility which would be ruled out in the latter scenario. FindRoot does not really care which type the equation is, symbolic or numeric or mixed, but the real problem was in the way you defined <f> - on some (symbolic say) arguments it can produce nonsense, and that means a flawed design of your function. If it makes sense to call it only on numeric arguments (like in your original case), this should be reflected in its definition. In all other cases, it should return unevaluated (this is a general rule for functions in Mathematica), and this is what the pattern-based definition semantics gives you. Hope this helps. Regards, Leonid On Wed, Jul 28, 2010 at 9:17 PM, Sam Takoy <sam.takoy(a)yahoo.com> wrote: Hi, > > >Thanks for the response. > > >I have determined that introducing ?NumericQ alone works and I am wondering >why? > > >How is the "f" that involves NDSolve fundamentally different from > > >f[x0_,y0_]:={x0 Exp[1],y0 Exp[1]} > > >? > > >Thanks again, > >Sam > > > ________________________________ From: Leonid Shifrin <lshifr(a)gmail.com> >To: Sam Takoy <sam.takoy(a)yahoo.com>; mathgroup(a)smc.vnet.net >Sent: Wed, July 28, 2010 6:03:47 AM >Subject: Re: FindRoot with NDSolve inside of it doesn't work > > > >Sam, > >This modification will work: > > >In[31]:= >Clear[f]; >f[x0_?NumericQ, y0_?NumericQ] := > Module[{sol, x, y}, > (sol = NDSolve[{x'[t] == x[t], y'[t] == y[t], x[0] == x0, > y[0] == y0}, {x, y}, {t, 0, 1}]; > {x[1], y[1]} /. sol[[1]])] > > >In[33]:= > (*f[x0_,y0_]:={x0 Exp[1],y0 Exp[1]};(*Works for this f*)*) >FindRoot[f[x0, y0] == {2.7, 5.4}, {{x0, 1}, {y0, 2}}] > > > > >Out[33]= {x0 -> 0.993274, y0 -> 1.98655} > > >Apart from localizing your variables, the main thing here was to restrict x0 and >y0 >as input parameters to <f>, to only numeric values, by appropriate patterns. > > >Regards, >Leonid > > > >On Wed, Jul 28, 2010 at 10:54 AM, Sam Takoy <sam.takoy(a)yahoo.com> wrote: > >Hi, >> >>I think it's completely self-explanatory what I'm trying to do in this >>model example: >> >>f[x0_, y0_] := ( >> sol = NDSolve[{x'[t] == x[t], y'[t] == y[t], x[0] == x0, >> y[0] == y0}, {x, y}, {t, 0, 1}]; >> {x[1], y[1]} /. sol[[1]] >> ) >> >>(*f[x0_, y0_]:={x0 Exp[1], y0 Exp[1]}; (* Works for this f *) *) >>FindRoot[f[x0, y0] == {2.7, 5.4}, {{x0, 1}, {y0, 2}}] >> >>Can someone please help me fix this and explain why it's not currently >>working? >> >>Many thanks in advance! >> >>Sam >> >> > >
From: Sam Takoy on 29 Jul 2010 06:43 One more question. I noticed that I do have to "Clear[f]", otherwise the change is not made. How come? I don't have that problem here: f[x_] := 5 f[x_] := 6 f[x] Thanks again, Sam ________________________________ From: Leonid Shifrin <lshifr(a)gmail.com> To: Sam Takoy <sam.takoy(a)yahoo.com>; mathgroup(a)smc.vnet.net Sent: Wed, July 28, 2010 2:52:56 PM Subject: Re: FindRoot with NDSolve inside of it doesn't work Sam, The difference is that in your last example with exponents the r.h.s of the function does not necessarily involve numerical steps, while when you invoke NDSolve, it does. So, for functions of the former type, you can get away with generic patterns, while for functions of the latter type you can not. This is related to the order in which expressions are evaluated. Inside FindRoot there is f[x0, y0] == {2.7, 5.4}. When this is evaluated, first f[x0, y0] is evaluated. If you have generic patterns x_,y_ in the definition of <f>, then the definition for <f> happily applies at this moment, while x0 and y0 are still symbolic. This is wrong since then NDSolve can not do its job and returns back the set of equations. To postpone the evaluation of <f> until numeric values are supplied by FindRoot in place of x0, y0, we restrict the pattern. Then, evaluation of f[x0, y0] == {2.7, 5.4} just yields back f[x0, y0] == {2.7, 5.4}, since the pattern is not matched by symbolic x0,y0, and then later x0 and y0 are bound to (replaced by) the numeric values generated by FindRoot, which results in correct execution. Cases where one needs to use this trick are interesting since the interaction between built-in functions (FindRoot here) and user - defined ones (f here) mediated by this trick are rather non-trivial. In some sense, we go a little under the hood of the built-in commands here. However they work, we know for sure that they are bound to call Mathematica evaluator on <f> at some point since <f> was defined at top level. And that means that we have all the usual possibilities to alter that part of evaluation that the evaluator normally gives us. Now, since FindRoot holds all its arguments, one may ask why does it not bind equations to numerical arguments right away. My guess is that sometimes it attempts to do some symbolic preprocessing with the equations, a possibility which would be ruled out in the latter scenario. FindRoot does not really care which type the equation is, symbolic or numeric or mixed, but the real problem was in the way you defined <f> - on some (symbolic say) arguments it can produce nonsense, and that means a flawed design of your function. If it makes sense to call it only on numeric arguments (like in your original case), this should be reflected in its definition. In all other cases, it should return unevaluated (this is a general rule for functions in Mathematica), and this is what the pattern-based definition semantics gives you. Hope this helps. Regards, Leonid On Wed, Jul 28, 2010 at 9:17 PM, Sam Takoy <sam.takoy(a)yahoo.com> wrote: Hi, > > >Thanks for the response. > > >I have determined that introducing ?NumericQ alone works and I am wondering >why? > > >How is the "f" that involves NDSolve fundamentally different from > > >f[x0_,y0_]:={x0 Exp[1],y0 Exp[1]} > > >? > > >Thanks again, > >Sam > > > ________________________________ From: Leonid Shifrin <lshifr(a)gmail.com> >To: Sam Takoy <sam.takoy(a)yahoo.com>; mathgroup(a)smc.vnet.net >Sent: Wed, July 28, 2010 6:03:47 AM >Subject: Re: FindRoot with NDSolve inside of it doesn't work > > > >Sam, > >This modification will work: > > >In[31]:= >Clear[f]; >f[x0_?NumericQ, y0_?NumericQ] := > Module[{sol, x, y}, > (sol = NDSolve[{x'[t] == x[t], y'[t] == y[t], x[0] == x0, > y[0] == y0}, {x, y}, {t, 0, 1}]; > {x[1], y[1]} /. sol[[1]])] > > >In[33]:= > (*f[x0_,y0_]:={x0 Exp[1],y0 Exp[1]};(*Works for this f*)*) >FindRoot[f[x0, y0] == {2.7, 5.4}, {{x0, 1}, {y0, 2}}] > > > > >Out[33]= {x0 -> 0.993274, y0 -> 1.98655} > > >Apart from localizing your variables, the main thing here was to restrict x0 and >y0 >as input parameters to <f>, to only numeric values, by appropriate patterns. > > >Regards, >Leonid > > > >On Wed, Jul 28, 2010 at 10:54 AM, Sam Takoy <sam.takoy(a)yahoo.com> wrote: > >Hi, >> >>I think it's completely self-explanatory what I'm trying to do in this >>model example: >> >>f[x0_, y0_] := ( >> sol = NDSolve[{x'[t] == x[t], y'[t] == y[t], x[0] == x0, >> y[0] == y0}, {x, y}, {t, 0, 1}]; >> {x[1], y[1]} /. sol[[1]] >> ) >> >>(*f[x0_, y0_]:={x0 Exp[1], y0 Exp[1]}; (* Works for this f *) *) >>FindRoot[f[x0, y0] == {2.7, 5.4}, {{x0, 1}, {y0, 2}}] >> >>Can someone please help me fix this and explain why it's not currently >>working? >> >>Many thanks in advance! >> >>Sam >> >> > >
From: Leonid Shifrin on 29 Jul 2010 06:43 When you define function through patterns, older pattern-based definitions remain, unless the pattern is exactly the same modulo dummy pattern variable names. Therefore, both f[x0_,y0_] and f[x0_?NumericQ, x0_?NumericQ] defs remain. Now, here is what generally happens: first, more specific defs are placed earlier even if they were entered later (you may check this on this example by typing ?f). The notion of more specific is not sharply defined and it is not always possible to determine, even in principle. If Mathematica can not determine which definition is more specific, it stores those in the order they were entered. Now, when the f[x0,y0] is evaluated inside FindRoot, all definitions are tried until the first one that matches is found. The one f[x0_?NumericQ, x0_?NumericQ] is tried first and does not match. But then the older one is tried and matches of course! So you still have the problem until you remove it, with Clear or whatever. In your last example, the patterns are identical, so the new definition replaces an old one and explicit removal of an old one is unnecessary. I discuss these issues in my book somewhat, here : http://www.mathprogramming-intro.org/book/node87.html <http://www.mathprogramming-intro.org/book/node87.html>,here: http://www.mathprogramming-intro.org/book/node47.html <http://www.mathprogramming-intro.org/book/node47.html>and here a little bit: http://www.mathprogramming-intro.org/book/node509.html <http://www.mathprogramming-intro.org/book/node509.html>Regards, Leonid On Thu, Jul 29, 2010 at 12:21 AM, Sam Takoy <sam.takoy(a)yahoo.com> wrote: > One more question. > > I noticed that I do have to "Clear[f]", otherwise the change is not made. > How come? > > I don't have that problem here: > > f[x_] := 5 > f[x_] := 6 > f[x] > > Thanks again, > > Sam > > ------------------------------ > *From:* Leonid Shifrin <lshifr(a)gmail.com> > *To:* Sam Takoy <sam.takoy(a)yahoo.com>; mathgroup(a)smc.vnet.net > *Sent:* Wed, July 28, 2010 2:52:56 PM > > *Subject:* Re: FindRoot with NDSolve inside of it doesn't work > > Sam, > > The difference is that in your last example with exponents the r.h.s of the > function > does not necessarily involve numerical steps, while when you invoke > NDSolve, > it does. So, for functions of the former type, you can get away with > generic patterns, > while for functions of the latter type you can not. > > This is related to the order in which expressions are evaluated. Inside > FindRoot there is > f[x0, y0] == {2.7, 5.4}. When this is evaluated, first f[x0, y0] is > evaluated. If you have > generic patterns x_,y_ in the definition of <f>, then the definition for > <f> happily applies > at this moment, while x0 and y0 are still symbolic. This is wrong since > then NDSolve > can not do its job and returns back the set of equations. To postpone the > evaluation of > <f> until numeric values are supplied by FindRoot in place of x0, y0, we > restrict the pattern. > Then, evaluation of f[x0, y0] == {2.7, 5.4} just yields back f[x0, y0] == > {2.7, 5.4}, since the > pattern is not matched by symbolic x0,y0, and then later x0 and y0 are > bound to (replaced by) > the numeric values generated by FindRoot, which results in correct > execution. > > Cases where one needs to use this trick are interesting since the > interaction between > built-in functions (FindRoot here) and user - defined ones (f here) > mediated by this > trick are rather non-trivial. In some sense, we go a little under the hood > of the built-in > commands here. However they work, we know for sure that they are bound to > call Mathematica > evaluator on <f> at some point since <f> was defined at top level. And that > means that > we have all the usual possibilities to alter that part of evaluation that > the evaluator normally > gives us. Now, since FindRoot holds all its arguments, one may ask why > does it not > bind equations to numerical arguments right away. My guess is that > sometimes it attempts > to do some symbolic preprocessing with the equations, a possibility which > would be ruled > out in the latter scenario. > > FindRoot does not really care which type the equation is, symbolic or > numeric or mixed, > but the real problem was in the way you defined <f> - on some (symbolic > say) arguments it can > produce nonsense, and that means a flawed design of your function. If it > makes sense to > call it only on numeric arguments (like in your original case), this should > be reflected in its > definition. In all other cases, it should return unevaluated (this is a > general rule for functions > in Mathematica), and this is what the pattern-based definition semantics > gives you. > > Hope this helps. > > Regards, > Leonid > > > > > On Wed, Jul 28, 2010 at 9:17 PM, Sam Takoy <sam.takoy(a)yahoo.com> wrote: > >> Hi, >> >> Thanks for the response. >> >> I have determined that introducing ?NumericQ alone works and I am >> wondering why? >> >> How is the "f" that involves NDSolve fundamentally different from >> >> f[x0_,y0_]:={x0 Exp[1],y0 Exp[1]} >> >> ? >> >> Thanks again, >> >> Sam >> >> ------------------------------ >> *From:* Leonid Shifrin <lshifr(a)gmail.com> >> *To:* Sam Takoy <sam.takoy(a)yahoo.com>; mathgroup(a)smc.vnet.net >> *Sent:* Wed, July 28, 2010 6:03:47 AM >> *Subject:* Re: FindRoot with NDSolve inside of it doesn't work >> >> Sam, >> >> This modification will work: >> >> In[31]:= >> Clear[f]; >> f[x0_?NumericQ, y0_?NumericQ] := >> Module[{sol, x, y}, >> (sol = NDSolve[{x'[t] == x[t], y'[t] == y[t], x[0] == x0, >> y[0] == y0}, {x, y}, {t, 0, 1}]; >> {x[1], y[1]} /. sol[[1]])] >> >> In[33]:= >> (*f[x0_,y0_]:={x0 Exp[1],y0 Exp[1]};(*Works for this f*)*) >> FindRoot[f[x0, y0] == {2.7, 5.4}, {{x0, 1}, {y0, 2}}] >> >> >> Out[33]= {x0 -> 0.993274, y0 -> 1.98655} >> >> Apart from localizing your variables, the main thing here was to restrict >> x0 and y0 >> as input parameters to <f>, to only numeric values, by appropriate >> patterns. >> >> Regards, >> Leonid >> >> >> On Wed, Jul 28, 2010 at 10:54 AM, Sam Takoy <sam.takoy(a)yahoo.com> wrote: >> >>> Hi, >>> >>> I think it's completely self-explanatory what I'm trying to do in this >>> model example: >>> >>> f[x0_, y0_] := ( >>> sol = NDSolve[{x'[t] == x[t], y'[t] == y[t], x[0] == x0, >>> y[0] == y0}, {x, y}, {t, 0, 1}]; >>> {x[1], y[1]} /. sol[[1]] >>> ) >>> >>> (*f[x0_, y0_]:={x0 Exp[1], y0 Exp[1]}; (* Works for this f *) *) >>> FindRoot[f[x0, y0] == {2.7, 5.4}, {{x0, 1}, {y0, 2}}] >>> >>> Can someone please help me fix this and explain why it's not currently >>> working? >>> >>> Many thanks in advance! >>> >>> Sam >>> >>> >> >> > >
First
|
Prev
|
Pages: 1 2 Prev: NDSolve for catenary Next: Student's T Confidence Interval [StudentTCI] |