MathGroup Archive 2011

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

Search the Archive

Re: Combining Slider and SetterBar in Manipulate

  • To: mathgroup at
  • Subject: [mg115275] Re: Combining Slider and SetterBar in Manipulate
  • From: DrMajorBob <btreat1 at>
  • Date: Thu, 6 Jan 2011 02:04:11 -0500 (EST)

More doubled "=" signs. What's up with that? How long will it go on?


On Wed, 05 Jan 2011 04:47:35 -0600, John Fultz <jfultz at> wrote:

> On Tue, 4 Jan 2011 18:53:35 -0500 (EST), AES wrote:
>> In article <ifup6c$cnr$1 at>,
>> JohnH <ununquadium113 at> wrote:
>>>> Also...a bit of unsolicited advice.  Your use of Block is a *bad*  
>>>> idea.
>>>> It's always bad to reference Block-scoped or Module-scoped variables
>>>> declared outside of a Manipulate or Dynamic from within that
>>>> Manipulate/Dynamic.  If you're wanting to localize the variable
>>>> 'someData', then Manipulate offers you an easy way to do that.  Add
>>>> someData as a control variable, but no control appearance.
>> John, I haven't followed the earlier part of this thread (and scoping is
>> something I try to think about as little as possible!), but could you
>> expand on this a little?
>> As an old Fortran programmer, I think in terms of subroutines.  So, in
>> building a Manipulate I want to first define a "subroutine" (that is, a
>> Module) which depends on, say, 2 or 3 explicit arguments, plus maybe a
>> few global parameters which will have already defined values.  This
>> subroutine will then return a numerical value or maybe a graphics  
>> object.
>> Then I want to build a Manipulate in which some or all of the explicit
>> arguments are controlled by Controls (others may be explicitly set
>> within the Manipulate); call this subroutine (or maybe several such
>> subroutines) within the Manipulate; and  Plot or Show the object
>> returned by the subroutine, or something that depends closely on it,
>> still within the Manipulate.
>> I guess the primary objective of this approach is brevity of code within
>> the Manipulate, plus just general modularity. Is the above a bad
>> approach?  -- especially assuming that the overall notebook containing
>> the Manipulate will be relatively brief and self-contained, and one
>> needn't worry about side effects after the Manipulate has been used.
> Sorry, there's no way to avoid discussing some detail of scoping to  
> answer your
> question, but I'll try to make it as painless as possible.
> As you probably know, Manipulate is built on top of Dynamic.  I know  
> you're
> probably much more interested in Manipulate, but it's easier to explain  
> if I
> reference Dynamic directly.  But, in most places in my explanation, you  
> can
> replace "Dynamic" with "Manipulate" and get the basic idea.
> The important thing to understand about Dynamic is that when you  
> evaluate a
> Dynamic, it does *not* immediately evaluate its contents.  This is why,  
> for
> example, that...
> Dynamic[x==5];0
> ...does not, in fact, assign x the value 5.  A Dynamic, and therefore a
> Manipulate, only gets evaluated when it gets displayed onscreen.
> This is a real problem when you surround Dynamic or Manipulate with  
> Block or
> Module.  These scoping constructs have long since evaporated away by the  
> time
> the Dynamic gets evaluated, and so any scoping they did for the contents  
> of
> Dynamic is pretty much useless.  E.g.,
> In[1]:== Block[{x==5},Dynamic[x]]
> Out[1]== x
> Incidentally, in this case, a bit of syntax coloring warns you that  
> something
> bad may happen.  Module is worse because it's a kind of scoping  
> construct where
> the scoping implementation can leak out.  So, you might know that, for  
> example:
> In[2]:== Module[{x},x]
> Out[2]== x$139074
> But what's trickier is what happens with Dynamic.  Because at first it  
> looks
> like it works:
> In[3]:== Module[{x==5},Dynamic[x]]
> Out[3]== 5
> but this is just another form of Module leakage.
> In[4]:== %//InputForm
> Out[4]//InputForm== Dynamic[x$139080]
> Recall that Dynamic did not evaluate its argument right away, so in  
> fact, it
> just carried the substituted 'x' straight out of the Module.
> There are two scoping constructs which work well with Dynamic --  
> DynamicModule
> and With.  DynamicModule[] works because, like Dynamic, it lives inside  
> the
> front end.  So, it localizes variables exactly when the Dynamic  
> evaluates.
> With[] works because it's essentially a form of find-and-replace for  
> expression
> trees, rather than an attempt to localize variables.
> Also, substitution of named function variables works well.  Function  
> variable
> substitution is a lot like With[].  This should slot very naturally into  
> your
> Fortran experience.  And you can generally use DynamicModule[] wherever  
> you
> would have used Module[] before.  But Block[]...well, that's just not a  
> concept
> which is compatible with how Dynamic works.
> Understand that this only affects scoping constructs used outside of  
> Dynamic (or
> Manipulate).  Using them inside is just fine.
> Sincerely,
> John Fultz
> jfultz at
> User Interface Group
> Wolfram Research, Inc.

DrMajorBob at

  • Prev by Date: Re: Mathematica daily WTF
  • Next by Date: Re: about the use of button
  • Previous by thread: Re: Combining Slider and SetterBar in Manipulate
  • Next by thread: Re: Combining Slider and SetterBar in Manipulate