MathGroup Archive 2006

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Problems with Set, SetDelayed and replacement rules...

  • To: mathgroup at smc.vnet.net
  • Subject: [mg72279] Re: Problems with Set, SetDelayed and replacement rules...
  • From: "Chris Chiasson" <chris.chiasson at gmail.com>
  • Date: Mon, 18 Dec 2006 06:55:40 -0500 (EST)
  • References: <em3a6c$7fq$1@smc.vnet.net>

Johannes wrote:
> If I am now calculating f1[1,1], f2[1,1] and f3[1,1], f1 and f2 deliver as expected a numerical value, but for f3[1,1] p isn't replaced by its value 1.
>
> Can anybody explain me the differences, especially the differences between f2 and f3? I suspected it to be exactly identical.

In f1, the right hand side, f[x]/.params, is evaluated before the rule
is stored since you use Set. Thus, in memory, an entry of
DownValues[f1] of the form HoldPattern[f1[x_,p_]]:>rhs has p in the
rhs, where I use rhs to mean "right hand side".

In f2, the right hand side, f[x] /. {g->g[p],h->h[p]}, is not evaluated
before the rule is stored since you use SetDelayed. However, the
unevaluated rhs still has p in it.

In f3, the right hand side, f[x]/.params, is not evaluated before the
rule is stored since you use SetDelayed. For this reason, the
corresponding entry of DownValues[f3] having the form
HoldPattern[f3[x_,p_]]:>rhs does not have p in the rhs.

The presence of p in the rhs of the DownValues is what governs p's
automatic replacement via the pattern matcher. If you want to make sure
p is replaced, you must cause a rhs to have p in it.

Does that answer your question?


  • Prev by Date: Re: simplifying inequalities
  • Next by Date: Re: Limit and Root Objects
  • Previous by thread: Re: Problems with Set, SetDelayed and replacement rules...
  • Next by thread: RE: Problems with Set, SetDelayed and replacement rules...