Re: What is the point of having Initializations in DynamicModule and Manipulate?
- To: mathgroup at smc.vnet.net
- Subject: [mg123052] Re: What is the point of having Initializations in DynamicModule and Manipulate?
- From: John Fultz <jfultz at wolfram.com>
- Date: Tue, 22 Nov 2011 05:32:56 -0500 (EST)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- Reply-to: jfultz at wolfram.com
Let's take the simpler case (which is no different in any fundamental way...it's
just easier to step through in a hyper-detailed way). Beginning with an
evaluation in a fresh kernel of the following:
DynamicModule[{c}, {plot},
Initialization :> (g[x_] := Cos[x]; plot = Plot[g[x], {x, 1, 10}]),
UntrackedVariables -> {g}]
* Shift+Enter evaluation occurs. It evaluates the above expression to itself
(well, except an extra option added to DynamicModule, but that's not relevant to
this discussion). You can confirm this, incidentally, by wrapping InputForm
around the expression and evaluating it in a fresh kernel.
* The kernel calls MakeBoxes on the evaluated result. The MakeBoxes result is
pretty simple for this case, so I'll print it out here so you can see it. Note
the naked "plot". This will never change from here on out, since it's not
Dynamic.
DynamicModuleBox[{c$$}, RowBox[{"{", "plot", "}"}],
Initialization :> (plot = Plot[g[x], {x, 1, 10}]),
DynamicModuleValues :> {}, UntrackedVariables -> {g}]
* The kernel sends the boxes over MathLink to the FE. As the FE reads the
boxes, it decorates the variables with $CellContext` (which you see when
toggling the cell expression). At this point, the Shift+Enter evaluation has
been fully completed as far as the kernel is concerned, and the FE has the
entire result of the Shift+Enter evaluation in memory, but has yet to display
it.
* The FE tries to display the DynamicModuleBox, but stops when encountering the
Initialization option. It now sends the body of the Initialization option to
the kernel and waits for the evaluation to finish.
* Now that the evaluation is finished, the FE now draws the DynamicModuleBox's
contents. Of course, the contents are simply RowBox[{"{", "plot", "}"}], so the
display of this static result didn't actually depend upon the code in
Initialization. Nonetheless, the FE was contractually bound to evaluate the
Initialization code before displaying *anything* inside of DynamicModule.
At this point, you'll see
{plot}
on the screen, and the symbols 'g' and 'plot' are now assigned in the kernel.
Sincerely,
John Fultz
jfultz at wolfram.com
User Interface Group
Wolfram Research, Inc.
On Mon, 21 Nov 2011 18:58:05 +1100, Mike H wrote:
> John,
>
> I do NOT expect plot or g to dynamically update. That is not what this is
> about.
>
> On Mon, Nov 21, 2011 at 5:34 PM, John Fultz <jfultz at wolfram.com> wrote:
>> On Mon, 21 Nov 2011 15:57:00 +1100, Mike H wrote:
>> So the output cell containing the list {plot, "Silder", g[0]} is not a
>> display of the DynamicModule?
>>
>
>> To refresh, the code you included was...
>>
> DynamicModule[{c}, {plot, Slider[Dynamic[c]], g[Dynamic@c]},
> Initialization :> (g[x_] := Cos[x]; plot = Plot[g[x], {x, 1, 10}]),
> UntrackedVariables -> {g}]
>
>
>> * plot is not in a Dynamic. You get exactly what the Shift+Enter
>> evaluation
> gave you.
> * g[] is not in a Dynamic (regardless of what argument you pass it). You
> get
> exactly what the Shift+Enter evaluation gave you.
>
> The Shift+Enter evaluation has completed long before the DynamicModule is
> displayed and the Initialization is executed.
>
> And the fact that you expected g[Dynamic@c] and/or Cos[Dynamic@c] to
> return
> anything sensible (which I had overlooked in your example before)
> indicates that
> you are failing to understand some really fundamental stuff about Dynamic.
>
>
> On the contrary I have already repeatedly explained what I expect: that
> is that plot would appear as the rendered plot because its global value
> was set during the initialization. As far as my lack fundamental
> understanding of Dynamic goes I repeat again that the example was
> provided to me by Wolfram Research Inc. It is also worth noting that when
> given the example I was also advised by Wolfram Research that "The
> evaluation of g here is triggered by making the argument to g dynamic."
>
>
> I actually disagree with that advice provided to me by *your company* and
> in fact it is wrong -- making the argument does not trigger the
> evaluation of g. So rather than cast aspersions about my understanding of
> Dynamic you might want to consider the knowledge base within Wolfram.
>
>
>> See
> here:
>
> http://forums.wolfram.com/mathgroup/archive/2010/May/msg00440.html
>
> and especially the post I link to here:
>
> http://forums.wolfram.com/mathgroup/archive/2009/Feb/msg00424.html
>>
>>
>> Simply put, what is the value of?
>>
> Cos[Dynamic[Pi]]
>
> Answer...Cos[Dynamic[Pi]], but because of the way Dynamic typesets, it
> will look
> like Cos[Pi] (because Dynamic[Pi] looks like Pi). That is because
> Dynamic[Pi],
> in the Shift+Enter evaluation, always evaluates to Dynamic[Pi]. Dynamic
> is a
> HoldFirst function which never evaluates its argument...it merely creates
> a
> front end construct which evaluates and displays its argument.
>
>
> yes. I agree but repeat that it is your colleagues providing this example
> g[Dynamic[c]]
>
> My question is solely about why the global value is not rendered. I am
> not suggesting or expecting these variables to be dynamic so lets get
> back on point.
>
>
>>> I understand the point you make about if a colon were placed and no
>> output were generated but what is your definition of "first displayed"?
>>
>
>> It actually shows up in the front end.
>>
>
>>> I
>> guess this must be another point of difference because I would consider
>> the first display of the dynamic module as being the first time I see
>> the
>> list {plot, "slider", g[0]} rendered.
>>
>
>> Yes, that's correct. But why would you expect 'plot' or 'g' to
>> magically
> update, since they are not inside of Dynamic?
>
>
> I don't expect them to "update." I expect them to have global values at
> the time of the rendering. The values are set once only. Based on the
> language which you say you are going to re-write, I expect an
> initialization to set plot to the graphic (once) and then when the
> dynamicmodule content is evaluated and the rendered output shows the
> graphic.
>>
>
>>> So when I first see {plot, "slider", g[0]} the initialized value of
>>> plot
>> and g are not rendered. Apologies if it seems I'm laboring this point
>> but
>> it remains confusing.
>>
>
>>> So it seems that the key to understanding this now becomes what the
>> definition of "display" is. Am I correct is saying that if a
>> DynamicModule is displayed -- and I await what this means -- the
>> initialization will have taken place and therefore the initialized value
>> will be shown in the display?
>>
>
>> The initialization will have taken place, but initialized values will
>> only show
> if the FE is kicking off further evaluations to actually display
> them...which is
> what Dynamic does.
>
>
> We're going in circles here, I do not understand how, if the
> initializations have taken place, prior to the evaluation of the the list
> (contents of the DM) that plot is not rendered as a graphic. If the
> initialization has taken place then Global`plot must surely have a value
> at the time the next step is executed -- which is the evaluation of the
> DM body.
>
>
> If I had evaluated plot=Plot[x,{x,0,1}] in a separate cell prior to
> evaluating the DM the global value of plot would be (and is) shown in the
> display. It is not a question of whether plot is updated -- I don't
> expect it to be and don't want it to be (otherwise I would use Dynamic)
> it is a question of whether the global value of plot is set in the
> initializations prior to the evaluation of the body. If you have an
> evaluation order like this:
>
>
> evaluate initialization plot = plot[....]
>
>
> then
>
>
> evaluate {plot, slider, g[0]}
>
>
> then I am still struggling to see how the global value of plot would not
> be used in the displayed list.
>
>
> Mike
>>
>>
>>> FWIW I had assumed a display to be the rendered output.
>>>
>
>> That is correct.
>
>
>>> thanks
>>>
>>
>> Mike
>>
> Sincerely,
>
> John Fultz
> jfultz at wolfram.com
> User Interface Group
> Wolfram Research, Inc.