Table function with Part[] call misbehaving, but only after initial startup of Mathematica

I am getting errors like:

Part::partd:
Part specification standardBasis[[1]] is longer than depth of object.


with the following Manipulate expression:

Clear[  e1, e2, standardBasis, y]
e1 := {1, 0}
e2 := {0, 1}
standardBasis := {e1, e2}
y := 3
Manipulate[
p := {x, y} ;
Clear[j];
arrowsReference = Table[Arrow[{p, p + Part[standardBasis, j]}], {j, 2}]
, {{x, 1}, -10, 10} ]


The odd thing about it is that this only occurs immediately after starting Mathematica, on the source file that contains this manipulate. A second shift-enter on the expression after that works without complaint and I get the desired result.

This appears to be related to the startup of mathematica using specific notebooks. The sequence I'm using is:

• go to windows explorer.
• double click on a .nb or .cdf file with this source.
• click enable-dynamics.
• get the error.
• shift-enter: error goes away.

whereas if I take a notebook that is blank and already opened and then cut and paste this source into it, I don't get any errors about the Part[] expressions.

-
Are you sure you want the Clear[j] in your Manipulate. Doesn't seem to make sense here. –  Sjoerd C. de Vries Feb 12 '12 at 16:05
I'd tried it as an experiment ... it didn't help and I forgot to remove it. I suspect that j in such an expression is local anyways. –  Peeter Joot Feb 12 '12 at 17:15

One way to deal with problems like this is to use DynamicModule inside the Manipulate:

Manipulate[
DynamicModule[{e1, e2, standardBasis, y, p}
, e1 := {1, 0}
; e2 := {0, 1}
; standardBasis := {e1, e2}
; y := 3
; Dynamic[
p := {x, y}
; arrowsReference =
Table[Arrow[{p, p + Part[standardBasis, j]}], {j, 2}]
]
]
, {{x, 1}, -10, 10}
]


The example localizes all of the symbols except arrowsReference. In the original example, it seemed like arrowsReference was meant to "escape" the Manipulate. Adjust these decisions to meet your needs.

The expressions that initialize e1, e2, standardBasis and y will each be evaluated exactly once (each session) as the Manipulate is initialized. Only the contents of the Dynamic expression will be re-evaluated each time the controls are manipulated.

This approach saves the state of the localized variables across Mathematica front-end sessions. Also, the output cell can be copied and pasted to create a new independent cell with its own state -- a desirable attribute when creating CDFs and demonstrations.

All this works because of the unusual evaluation sequence documented under the More Information section of DynamicModule. Essentially, there is a kind of "double evaluation" at work. The initial definitions (e1 := ... through Dynamic[...]) are evaluated in the first pass as if they were defined within a Module. Then, the final result (in this case Dynamic[...]) is wrapped into a new DynamicModule and that becomes the content of the the Manipulate.

-
What are your thoughts on putting DynamicModule outside of Manipulate versus inside? (+1) –  Mr.Wizard Feb 13 '12 at 1:51
@Mr.Wizard I think it is somewhat arbitrary. I tend to put it outside myself. But I've answered quite a few questions on this topic in the context of a Wolfram Demonstration (as I know you have) so I put it inside the Manipulate as a reflex. –  WReach Feb 13 '12 at 3:26
I assume this is caused by the dynamic content becoming active and trying to run its internal code involving standardBasis which is at that moment undefined (and you can't do a Parton an undefined variable). You may add SaveDefinitions->True to your manipulate to store definitions it depends on.
SaveDefinitions has the disadvantage that it may cause external definitions to be made inadvertently if you don't take care.