MathGroup Archive 2006

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

Search the Archive

Re: delayed rule evaluation order

  • To: mathgroup at smc.vnet.net
  • Subject: [mg68020] Re: [mg67967] delayed rule evaluation order
  • From: "Chris Chiasson" <chris at chiasson.name>
  • Date: Thu, 20 Jul 2006 06:04:59 -0400 (EDT)
  • References: <200607190921.FAA21363@smc.vnet.net> <44BE2B26.70206@wolfram.com> <acbec1a40607190940k511a06b0ue9e47405a39fe651@mail.gmail.com> <44BE6CF2.6090605@wolfram.com>
  • Sender: owner-wri-mathgroup at wolfram.com

From Carl Woll's commentary, it appears PatternTest was the "culprit".
When rule evaluation is done outside the HoldForms that Trace
produces, the PatternTest (the infixed question mark in
blah_?ExactNumberQ) starts causing the unwanted evaluations. A way to
get around that is to require that the candidate expression have an
appropriate Head. In this example, the appropriate Head is Integer, as
Dr. Woll pointed out. In my actual problem, the appropriate Head is
Real.

Thank you to the respondents:
Peter Pein
Bob Hanlon
Andrzej Kozlowski
Carl Woll
David Park


On 7/19/06, Carl K. Woll <carlw at wolfram.com> wrote:
> Chris Chiasson wrote:
> > This is a fairly interesting replacement technique; it reminds me of
> > the one David Park used for capturing side-effects of Condition
> > processing.
> >
> > http://forums.wolfram.com/mathgroup/archive/2006/May/msg00621.html
> >
> > Unfortunately, it is causing unwanted evaluations. Why does it do this?
> >
> > In[1]:=
> > f[1]=1;
> > f[n_Integer]=n f[n-1];
> > f[2`3]
> > z=Trace[f[2]]
> > z/.{blah_?ExactNumberQ\[RuleDelayed]With[{p=SetPrecision[blah,3]},p/;True]}
> >
> > Out[3]=
> > f[2.00]
> >
> > Out[4]=
> > {f[2],2 f[-1+2],{{-1+2,1},f[1],1},2 1,2}
> >
> > Out[5]=
> > {2.00,2.00,{{1.00,1.00},1.00,1.00},2.00,2.00}
> >
>
> Chris,
>
> First let's look at the input form of z:
>
> In[7]:= z // InputForm
>
> Out[7]//InputForm=
> {HoldForm[f[2]], HoldForm[2*f[-1 + 2]], {{HoldForm[-1 + 2],
> HoldForm[1]}, HoldForm[f[1]], HoldForm[1]},
>   HoldForm[2*1], HoldForm[2]}
>
> So, your question is why HoldForm[f[2]] is being replaced with 2.00.
>
> In[7]:= HoldForm[f[2]] /.
>   blah_?ExactNumberQ :> With[{p = SetPrecision[blah, 3]}, p /; True]
>
> Out[7]= 2.00
>
> Let's use Reap/Sow to find out what blah is:
>
> In[8]:= HoldForm[f[2]] /.
>    blah_?ExactNumberQ :>
>     With[{p = SetPrecision[blah, 3]}, Sow[Hold[blah]]; p /; True] // Reap
>
> Out[8]= {2.00, {{Hold[f[2]]}}}
>
> So, M-- looks at f[2], which when evaluated is 2, an exact number:
>
> In[9]:= ExactNumberQ[f[2]]
>
> Out[9]= True
>
> Hence, f[2] is replaced with 2.00.
>
> I don't know what you are trying to accomplish here, but two
> possibilities are:
>
> In[10]:= Block[{f},
>   z /. blah_?ExactNumberQ :> With[{p = SetPrecision[blah, 3]}, p /; True]]
>
> Out[10]= {f[2.00], 2.00 f[1.00], {{1.00, 1.00}, f[1.00], 1.00}, 2.00, 2.00}
>
> and
>
> In[11]:= z /. blah_Integer :> With[{p = SetPrecision[blah, 3]}, p /; True]
>
> Out[11]= {f[2.00], 2.00 f[-1.00 + 2.00], {{-1.00 + 2.00, 1.00}, f[1.00],
> 1.00}, 2.00 1.00, 2.00}
>
> Carl Woll
> Wolfram Research
>
> > The output is humorous (in a demented way, I guess) if With is
> > replaced with Module.
> >
> > Thanks,
> >
> > On 7/19/06, Carl K. Woll <carlw at wolfram.com> wrote:
> >
> >> Chris Chiasson wrote:
> >> > Hold[{2, 3}] /. {{x_, y_} :> x^y}
> >> >
> >> > the result is Hold[Power[2,3]]
> >> >
> >> > I would like the result to be Hold[8]
> >> >
> >> > The original context is post-processing of a large Trace output (via
> >> > SetPrecision to get rid of digits and improve readability).
> >> >
> >> > Any ideas?
> >> >
> >>
> >> This is not an easy one to figure out. One possibility is given in the
> >> help for ReplaceAll in the last example of the Further Examples section.
> >> In this example the following construct is used:
> >>
> >> In[27]:= Hold[{2, 3}] /. {x_, y_} :> With[{p = x^y}, p /; True]
> >>
> >> Out[27]= Hold[8]
> >>
> >> Carl Woll
> >> Wolfram Research
> >>
> >
> >
>
>


-- 
http://chris.chiasson.name/


  • Prev by Date: Re: delayed rule evaluation order
  • Next by Date: Re: hadamard finite part
  • Previous by thread: Re: delayed rule evaluation order
  • Next by thread: Re: delayed rule evaluation order