MathGroup Archive 2011

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

Search the Archive

Re: What is the point of having Initializations in

  • To: mathgroup at
  • Subject: [mg123032] Re: What is the point of having Initializations in
  • From: Mike H <mike.honeychurch at>
  • Date: Mon, 21 Nov 2011 04:27:06 -0500 (EST)
  • Delivered-to:
  • References: <>

On Mon, Nov 21, 2011 at 1:02 PM, John Fultz <jfultz at> wrote:

> This is no accident.  It's very carefully thought out design.
> Question...what do I do if I want thing A to evaluate before thing B?
>  Why, of
> course, use any number of Mathematica paradigms for sequential evaluation.
>  The
> semicolon, representing CompoundExpression, for example.  No need to invent
> anything here.
> Further question...what if I want thing A to evaluate before thing B, but
> thing
> B is part of a dynamic interface.  This is the interesting question.
>  There are
> absolutely no guarantees about the order in which two discrete Dynamics
> will
> evaluate, so I can't set up multiple Dynamics in a row to evaluate in
> sequence.
> I could nest Dynamics (outer ones always evaluate before inner ones), but
> then I
> may have to play some tricky games with Refresh to prevent code from
> evaluating
> which should only ever evaluate once.
> So, what I want is an Initialization option.  Guaranteed to only ever
> evaluate
> once, and always evaluates before its Dynamic contents.  So, we added the
> Initialization option to Dynamic.
> 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 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.

(BTW I didn't expect the initialization to evaluate more than once only. My
point/question is that it should evaluate "initially" which you seem to be
confirming it should in your previous paragraph)

> So, what about the issue of code inside a DynamicModule which is not
> wrapped in
> Dynamic?  Well, it's very important to understand that this code will
> never,
> never, ever evaluate again after the Shift+Enter evaluation.  It does not
> evaluate when you load the notebook in a new session, for example.  So,
> any code
> inside of a DynamicModule, but not wrapped inside of a Dynamic, is UTTERLY
> USELESS, except insofar as it has side effects on setting DynamicModule
> variables which might be remembered in future sessions.  Any code which
> does
> anything else is going to not be remembered in future sessions, and
> therefore
> risks creating interfaces which are busted in ways which aren't obvious
> unless
> you're testing for this sort of thing.

this is all ok. I have no argument with any of it but it is unrelated to my
example. In my example plot and g[0] would be considered utterly useless
but this doesn't change the fact that initialization hasn't occured prior
to the evaluation of the contents -- which is my sole question.

> Furthermore, it introduces a weird evaluation order problem because you're
> mixing code evaluated at Shift+Enter time with code evaluated when the
> DynamicModule is actually displayed onscreen.  It's more bizarre than
> I've mentioned before, the result of evaluating:
> Dynamic[a=5];
> does *not* set a because the contents of the Dynamic never evaluate
> because the
> contents were never displayed onscreen.  DynamicModule inherently wants to
> be,
> by design, a Dynamic-like construct...i.e., it does what it does when
> displayed
> onscreen, and in tandem with dependent Dynamics or DynamicModules.  But
> unlike
> Dynamic, DynamicModule does actually evaluate its contents at Shift+Enter
> time,
> to allow for the convenience of introducing non-trivial code for setting
> the
> variables.
> Now, let's suppose that you wanted the Initialization option to evaluate
> before
> that code.  What you would get is something even more bizarre and
> confusing.
> You would have to do one of two things...

> Option 1: Evaluate the Initialization option during Shift+Enter evaluation
> *and*
> when the FE instantiates/displays the DynamicModule.  Which means that you
> get a
> double-evaluation affecting the same DynamicModule variables.  I hope I
> don't
> have to say why double-evaluations are bad in the general case.
> Option 2: The Initialization option would have to work differently for
> DynamicModules depending upon how and when the results were created.
>  I.e., it
> would fire during Shift+Enter evaluations sometimes, and during FE
> instantiation/display sometimes.  Which would also make the results much
> more
> difficult to understand, and I'm frankly not even sure how I would handle
> some
> of the corner cases to read the user's intent (what should a DynamicModule
> in an
> ExpressionCell do, for example?).
> 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:



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?

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.

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.



> Sincerely,
> John Fultz
> jfultz at
> 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

  • Prev by Date: Re: What is the point of having Initializations in
  • Next by Date: Re: problem in minimization of a matrix
  • Previous by thread: What is the point of having Initializations in DynamicModule and Manipulate?
  • Next by thread: Re: What is the point of having Initializations in DynamicModule and Manipulate?