Re: What is the point of having Initializations in DynamicModule and Manipulate?
- To: mathgroup at smc.vnet.net
- Subject: [mg123033] Re: What is the point of having Initializations in DynamicModule and Manipulate?
- From: John Fultz <jfultz at wolfram.com>
- Date: Mon, 21 Nov 2011 04:27:17 -0500 (EST)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- Reply-to: jfultz at wolfram.com
On Mon, 21 Nov 2011 14:06:18 +1100, Mike H wrote:
> On Mon, Nov 21, 2011 at 1:02 PM, John Fultz <jfultz at wolfram.com> wrote:
>
>> But we later realized that a similar problem comes up with
>> DynamicModule. It's quite reasonable to want to "prime" a DynamicModule
>> when the FE instantiates/displays it, which might involve setting
>> initial values of the DynamicModule variables, but it might also involve
>> a bunch of other related code evaluation (common example, loading a
>> package). So, we added the same concept of an Initialization option of
>> DynamicModule as to Dynamic. And it works in exactly the same way...it
>> does not evaluate until the FE is ready to display the DynamicModule,
>> and then it queues to the Initialization option to happen first,
>> and once only.
>
>
> If the initialization is evaluated first then in the example I provided
> why is the output {plot, "slider", g[0]} and not {actual graphic,
> "slider", Cos[0]} ? That is essentially the ONLY question I have. On my
> system the initialization is clearly not occuring FIRST in the queue.
Because your output is not Dynamic output...it is the result of Shift+Enter
output. As I said, the Initialization option is kicked off by FE-instantiated
evaluation. No part of your evaluation is FE-instantiated.
>> DynamicModule lives firmly in the world of FE-instantiated evaluation,
>> despite the ability to initialize its variables at Shift+Enter time.
>> The correct design is for all of its options to similarly live in the
>> world of FE- instantiated evaluation.
>
>
> Earlier in your comment I thought you were saying that initialization
> would occur once only and it would occur first. In these later comments
> you seem to be saying that won't happen??? Could we come back to the
> comment I posted. If you have a cell with this code:
>
>
> DynamicModule[{stuff},
>
>
> content,
>
>
> Initialization:>(some more stuff)
>
>
> ]
>
>
> and you press Shift+Enter should the user expect expect the
> initialization to take place prior to the evaluation of the "content" --
> even if the contents are utterly useless -- and therefore for that to be
> reflected in the rendered output?
No, the user should not. The Initialization option, as I indicated, is invoked
under the same circumstances that Dynamic evaluation would be invoked. It's all
under the FE's control, and happens completely separately from Shift+Enter
evaluation. If you had terminated the DynamicModule with a semicolon, for
example, the code in the Initialization option would never, ever be evaluated
because the DynamicModule never existed in the FE. For *exactly* the same
reason that
Dynamic[a=5];
does not set a to 5.
> This is the essence of my question. A lot of the other stuff about
> initializing only once and so on is fine and I have no disagreement with,
> but is unrelated to this simple question.
It's not unrelated...you're suggesting the design is flawed, and I'm giving you
a detailed analysis of why the design is the way it is. As a colleague of mine
has said, DynamicModule is not a scoping construct...it *produces* a scoping
construct. That's a bit of a philosophical statement, but what he means by that
is that the only useful ways in which DynamicModule does scoping is by producing
a typeset front end construct that scopes. You can't call it a real scoping
construct because, unlike With/Block/Module/Function, if you put it behind a
semicolon, it produces no useful results.
I.e., DynamicModule lives in the world of the front end, and all of its
behaviors are consistent with that.
> On my system it can be shown that the initialization does not occur
> before the content of the DM is evaluated and rendered in the output
> cell. I expected that it would.
Your expectation is simply incorrect. The documentation for DynamicModule also
makes a very clear statement about Initialization, saying:
"an expression to evaluate when the DynamicModule is first displayed."
Notice...*displayed*, not *evaluated*. Unfortunately, the DynamicModule
documentation goes on to make another statement about Initialization which is
still consistent with my point, but is ambiguous and not entirely correct in the
general case:
"When DynamicModule is first evaluated, initial assignments for local variables
are made first, and then any setting for the Initialization option is
evaluated."
It's not entirely correct because the Initialization option will never fire if
the DynamicModule is never displayed. It's ambiguous because it's not specific
about the evaluation in the DynamicModule's body.
Trust the first statement, which is 100% correct and unambiguous. I'm going to
go clean up that documentation now.
Sincerely,
John Fultz
jfultz at wolfram.com
User Interface Group
Wolfram Research, Inc.
>
>
> thanks
>
> Mike
>>
>>
>> Sincerely,
>>
> John Fultz
> jfultz at wolfram.com
> User Interface Group
> Wolfram Research, Inc.
>
>
> On Sat, 19 Nov 2011 06:46:53 -0500 (EST), Armand Tamzarian wrote:
>> I'd be interested in feedback from other users about the way in which
>> Initializations works within DynamicModule (and Manipulate?). It is
>> fair to say that I expected an initialization to occur "initially."
>> That is to say I expected Initialization content to be evaluated prior
>> to the body of the DynamicModule. I have exchanged emails with tech
>> support about this. Attached is an example sent to me by tech support.
>>
>> ClearAll[plot, g];
>>
>> (* and in a separate cell *)
>> DynamicModule[{c}, {plot, Slider[Dynamic[c]], g[Dynamic@c]},
>> Initialization :> (g[x_] := Cos[x]; plot = Plot[g[x], {x, 1, 10}]),
>> UntrackedVariables -> {g}]
>>
>> It is important for this example to keep the ClearAll line in a
>> separate cell so that the global variables are only cleared once. On
>> my system (OS X 10.6.8, Mathematica 8.0.4) the output is a list
>>
>> {plot, "slider", g[0.]}
>>
>> where "slider" is the actual rendered slider but plot is the word
>> (unset variable) plot. In other words Global`plot has no value at the
>> time the body of the DynamicModule is evaluated. Ditto Global`g.
>>
>> If you evaluated the cell (the second cell with the DynamicModule) a
>> second time a plot graphic appears in the list and g[0.] becomes
>> Cos[0.]. This is not surprising because Global`plot and Global`g now
>> have a value.
>>
>> Wolfram have indicated that this is working as designed -- which is
>> presumably why this example was sent to me of how this should work. If
>> that is the case it seems poorly designed because (and it is here I
>> would like feedback) users would expect initializations to be
>> evaluated prior to the body of the DynamicModule -- otherwise what is
>> the point?
>>
>> I'd appreciate the thoughts of other users about this.
>>
>> Additionally I have been told by Wolfram that wrapping Dynamic around
>> the variable(s) that are not being evaluated will trigger the
>> evaluation. But why would a user want to make plot or g Dynamic? It
>> seems to me that the entire purpose of having an Initialization is to
>> evaluate this "one off" variable/functions.
>>
>> thanks
>>
>> Mike