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