Re: Combining Slider and SetterBar in Manipulate
- To: mathgroup at smc.vnet.net
- Subject: [mg115275] Re: Combining Slider and SetterBar in Manipulate
- From: DrMajorBob <btreat1 at austin.rr.com>
- Date: Thu, 6 Jan 2011 02:04:11 -0500 (EST)
More doubled "=" signs. What's up with that? How long will it go on?
Bobby
On Wed, 05 Jan 2011 04:47:35 -0600, John Fultz <jfultz at wolfram.com> wrote:
> On Tue, 4 Jan 2011 18:53:35 -0500 (EST), AES wrote:
>> In article <ifup6c$cnr$1 at smc.vnet.net>,
>> JohnH <ununquadium113 at yahoo.com> 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 wolfram.com
> User Interface Group
> Wolfram Research, Inc.
>
--
DrMajorBob at yahoo.com