MathGroup Archive 2007

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

Search the Archive

Re: Monitor bug or feature

  • To: mathgroup at smc.vnet.net
  • Subject: [mg84110] Re: Monitor bug or feature
  • From: Jean-Marc Gulliet <jeanmarc.gulliet at gmail.com>
  • Date: Mon, 10 Dec 2007 20:38:24 -0500 (EST)
  • Organization: The Open University, Milton Keynes, UK
  • References: <fjj1nk$g5b$1@smc.vnet.net>

Mark Fisher wrote:

> Monitor[Table[Pause[.1]; i, {i, 10}], i]
> 
> works as I expected, but

By that you mean one can see a temporary cell which displays an 
increasing counter, then this temporary cell is discarded and the result 
of Table is printed.

> Table[Pause[.1]; i, {i, 10}] // Monitor[#, i] &
> 
> does not: It does not produce any "monitoring".

And this is perfectly correct since there is nothing to monitor :)

What the difference in behavior?

Attributes[Monitor] ---> {HoldAll, Protected, ReadProtected}

Because Monitor has the attribute HoldAll so in the first form you used, 
Monitor does not evaluate immediately its arguments but put them on 
hold, so it has time to build whatever is required to set up the 
counter, the temporary cell, etc, and only then the evaluation of 
Table[...] is going  to take place.

The second form you use to call Monitor prevents the holding of the 
arguments; that is Table[...] is evaluated first then the result (a list 
of ten numbers) is passed on to Monitor that now put its argument on 
hold, build whatever it has to build, then evaluate its arguments. But 
hold on, the expression it has to evaluate is just a list of numbers, 
ready to be displayed, which is independent of any variable called 'i'. 
So the monitoring is finished and the list is returned.

Note you can get a feeling of what's going on by using Trace. You will 
see that in the first case the counter and dynamic variable are set up 
first, then Table is evaluated, while in the second case, Table is 
evaluated first.

Monitor[Table[Pause[.1]; i, {i, 10}], i] // Trace

Table[Pause[.1]; i, {i, 10}] // (Monitor[#, i] &) // Trace

> Are there other examples where
> 
> f[x, a]
> 
> and
> 
> f[#,a]&[x]
> 
> produce different "effects". (Clearly the Heads of the expressions are
> different.)

Here, I am not sure to follow or understand what you are talking about. 
Both returned expressions are identical, heads included.

In[1]:= f[x, a]

Out[1]= f[x, a]

In[2]:= % // Head

Out[2]= f

In[3]:= f[#, a] &[x]

Out[3]= f[x, a]

In[4]:= % // Head

Out[4]= f

In[5]:= %%%% === %%

Out[5]= True

> I'm guessing my surprise regarding this feature of Monitor reflects
> the fact that I really haven't made any attempt to understand Dynamic
> etc.

Well, the issue is more about function attributes and order of 
evaluation. In contrast to Monitor, take the function N, for instance. 
It has no special attribute so the calling sequence N[Pi,20] is 
identical in terms of effect to Pi//N[#,20]& and both yield the same result.

Regards,
-- 
Jean-Marc


  • Prev by Date: Re: Inset problems & Export
  • Next by Date: FullSimplify with Pi
  • Previous by thread: Re: Monitor bug or feature
  • Next by thread: Re: Monitor bug or feature