Re: Re: Derivatives D[ ] as Functions: Summary (LONGISH)

*To*: mathgroup at smc.vnet.net*Subject*: [mg13333] Re: [mg13253] Re: Derivatives D[ ] as Functions: Summary (LONGISH)*From*: David Withoff <withoff>*Date*: Mon, 20 Jul 1998 02:49:54 -0400*Sender*: owner-wri-mathgroup at wolfram.com

> I recently posed the question of defining a function f2 as the > derivative of another function f1, e.g. > > Remove["Global`*"]; > > f1[a_,x_] :=a Cos[x] + a^2 Sin[x]; > f2[a_,x_] := D[f1[a,x],x]; > > and then finding that f2 would not behave "as expected" in a subsequent > Plot[ ] or Table[ ]. > > Thanks to several people for their responses, and apologies for my > several typos in earlier postings. It's clear what my difficulty was. So what was the difficulty? I wasn't sure what you meant when you said that f2 didn't behave as expected. I don't know what you tried, or what happened, or what you were expecting. Unless the guesses below address the problem, could you fill us in? My initial guess was that you tried something like In[1]:= f1[a_,x_] :=a Cos[x] + a^2 Sin[x] In[2]:= f2[a_,x_] := D[f1[a,x],x] In[3]:= Table[f2[1,x],{x,2}] General::ivar: 1 is not a valid variable. General::ivar: 2 is not a valid variable. Out[3]= {D[Cos[1] + Sin[1], 1], D[Cos[2] + Sin[2], 2]} which fails because the example has been set up so that Table inserts numerical values for the differentiation variable before the differentiation can be completed. It's a question of the order in which things happen. This particular problem is resolved by doing the differentiation first, as in In[4]:= f2[a_,x_] = D[f1[a,x],x] 2 Out[4]= a Cos[x] - a Sin[x] In[5]:= Table[f2[1,x],{x,2}] Out[5]= {Cos[1] - Sin[1], Cos[2] - Sin[2]} What left me puzzled, and led me to believe that I must have misunderstood the question, was the subsequent question about FullForm. Based on the above understanding of the question, FullForm is very nearly irrelevant here, and I wasn't able to think of any other interpretation of your question in which FullForm might be useful. With the following remark I am even more puzzled: > However, let's look at the general issue a little further. If for > example we do the above and then look at the FullForm version of the > two functions, they look very similar: > > f1[a,x]//FullForm > > Plus[Times[a,Cos[x]],Times[Power[a,2],Sin[x]]] > > f2[a,x] // FullForm > > Plus[Times[Power[a,2],Cos[x]],Times[-1,a,Sin[x]]] > > Note that these FullForm results, if not misleading, certainly give no > clue that f2 has a different character than f1 and will behave totally > differently if you try to use it in Plot[ ] or Table[ ] . This doesn't make any sense to me. The FullForm looks quite explicit, and tells me exactly how this expression will be treated in Plot or Table. My guess now is that my original interpretation of your question was correct, and that all of the discussion of FullForm is not only irrelevant, it has served to make a very simple and straightforward issue appear to be something deep and difficult. My guess is that this is an issue of evaluation order -- it is necessary to evaluate the derivative before inserting numerical values for the differentiation variable, and problems will come up (there will be attempts to differentiate with respect to a number) if Table, Plot, or some other operation replaces the differentiation variable by a number before the differentiation is done. On an unrelated issue: > A general and frequent and serious problem with Mathematica, in fact, > is that it often does things that may be totally logical and even > necessary by its rules, but that can be mysterious, non-intuitive, and > frustrating to ordinary users; and the nature of the beast often makes > these problems obscure and hard to find. > > [As another example of Mathematica's penchant for obscure difficulties, > note that if you follow the usual practice that you are allowed to use > for (all? most?) other compound expressions and include the "Remove[ > ]" expression in the same cell as the two function definitions above, > the two definitions will be Removed, even though they come AFTER the > Remove[ ]. Tell me why this makes sense? -- not what combination of > rules makes Remove[ ] function this way, but why setting it up in this > way makes sense? Also, tell me where you're warned about this in the > Mathematica Book?] One answer to those questions is that that is just the way that computer languages work. Input is processed in two stages. In the first stage the computer figures out what the input means, and in the second stage the computer does what it was asked to do. Anything that happens in the first stage will inevitably be done before anything that happens in the second stage. It's another question of the order in which things happen. Consider, for example, processing the input x+y. After reading only the "x", or only the "x+", the computer still won't know what the input means. It needs to read all the way to the "y", and detect that there is nothing after the "y", before it knows what you want to do. After reading the complete input "x+y", the computer knows what the input means. Now it can go back and do what it was asked to do: look up the value of x, look up the value of y, and add them. The essential point of this example is that, even though "y" comes after "x" in this input, the computer looks at "y" *before* it looks up the value of x, and anything that the computer does with the "y" when it first looks at it will happen *before* the computer evaluates x. That is also what happens in an input such as Remove[x];x=3. This is an ambiguous input. If the computer processes this input all at once, then it seems reasonable for the computer to guess that the first x refers to the same thing as the second x. That is the way that Mathematica works. One can entertain a variety of alternate designs -- parsing and evaluating the compound expression in pieces, deferring the creation of a symbol to represent "x", and so forth -- but all of these alternatives are more complicated, and none of them completely eliminate the problem. > [Another general observation is that when problems -- or anyway > "apparent problems" -- with Mathematica's ways of doing things are > pointed out, I find it's much more common to get a detailed explanation > of why Mathematica does what it does, rather than any discussion of the > design choices, or design necessities, that make it necessary -- if it > is necessary -- for Mathematica to function in this way.] In Mathematica, I would describe all of the behaviors mentioned here as "design necessities", in the sense that, while there are other ways to do these things, none of the alternatives are very appealing. Dave Withoff Wolfram Research