Re: What is the point of having Initializations in
- To: mathgroup at smc.vnet.net
- Subject: [mg123034] Re: What is the point of having Initializations in
- From: Mike H <mike.honeychurch at gmail.com>
- Date: Mon, 21 Nov 2011 04:27:28 -0500 (EST)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- References: <CAAMnnc-C7WfLx2oteGLxGTGohKURwpqGSPT8ThDM2x8L8WKPwQ@mail.gmail.com>
On Mon, Nov 21, 2011 at 3:14 PM, John Fultz <jfultz at wolfram.com> wrote:
> 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*.
So the output cell containing the list {plot, "Silder", g[0]} is not a
display of the DynamicModule?
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"? 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.
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.
> , 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.
>
And it is this statement I have been using when trying to understand this.
This is also the statement I cited to tech support when I asserted that the
behaviour was wrong -- in so far as the initialization was not being
evaluated first -- i.e. prior to the main body -- and not behaving as
documented.
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?
FWIW I had assumed a display to be the rendered output.
thanks
Mike
>
> 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
>
>
>