Shadow error when trying to use ParallelTable
in [Mathematica]
|
From: Todd Allen on 14 Feb 2010 05:59 Hi Everyone, I am trying to accelerate some code using ParallelTable, but when I do , I get the following error message: list::shdw: Symbol list appears in multiple contexts {Parallel`Preferences`,Global`}; definitions in context Parallel`Preferences` may shadow or be shadowed by other definitions. >> ---------------------- The basic outline of my code, which itself is INSIDE a module is: DistributeDefinitions[degenes, subraw, addonpos]; finaldegenes = Partition[ Flatten[ParallelTable[ Append[degenes[[i]], Flatten[Select[subraw, #1[[1]] == degenes[[i, 1]] &]][[ addonpos]]], {i, 1, Length[degenes]}, Method -> "CoarsestGrained"]], (Length[degenes[[1]]] + Length[addonpos])]; ------------------- All the variables are themselves in the Global context and I can say that the code does work without error, if I comment out the DistributeDefinitions statement, and revert to a Table command rather than ParallelTable. I have tried to fix this problem by referring to the variables by their full context name, such as: Parallel`Preferences`degenes without success. I have also tried localizing all variables inside the module, and I still get the shadow error regardless. Do you see anything obviously wrong? What strategies do you use to figure out shadow problems in your own code? The reason I ask, is because I have tried to further isolate this problem to see if the variable contexts are changing....but it is not obvious to me they are. This is a frustrating one. Thank you for any thoughts you might have! Todd
From: Norbert P. on 15 Feb 2010 05:45 Hey Todd, it's not really an error message, it's just a warning. And it appears only the first time you use Parallel functions. I don't think it will lead to any problems in your code. It's most likely caused by some omission in the built-in code, somebody forgot to put variable list into a Private section of the Parallel`Preferences` package. I just ignore the message. If you are really worried, don't use the variable named "list" in your code. Your message can be easily reproduced, this is what happens on a fresh kernel: In[1]:= list = 1; In[2]:= ParallelTable[1, {3}] During evaluation of In[2]:= list::shdw: Symbol list appears in multiple contexts {Parallel`Preferences`,Global`}; definitions in context Parallel`Preferences` may shadow or be shadowed by other definitions. >> Out[2]= {1, 1, 1} Actually, someone screwed up big time, these are the names in Parallel`Preferences` that will produce this shadowing warning: In[3]:= Names["Parallel`Preferences`*"] Out[3]= {Parallel`Preferences`add,Parallel`Preferences`addPreference,Parallel`Preferences`clear,Parallel`Preferences`debugPreference,Parallel`Preferences`debugQ,Parallel`Preferences`exists,Parallel`Preferences`get,Parallel`Preferences`InitializePreferences,Parallel`Preferences`list,Parallel`Preferences`load,Parallel`Preferences`Preferences,Parallel`Preferences`prefs,Parallel`Preferences`Scope,Parallel`Preferences`set,Parallel`Preferences`tr} As you can see, many of these are quite common names that people might use in their programs. Best, Norbert On Feb 14, 2:59 am, Todd Allen <genesplice...(a)yahoo.com> wrote: > Hi Everyone, > > I am trying to accelerate some code using ParallelTable, but when I do , I get the following error message: > > list::shdw: Symbol list appears in multiple contexts {Parallel`Preferences`,Global`}; definitions in context Parallel`Preferences` may shadow or be shadowed by other definitions. >> > > ---------------------- > > The basic outline of my code, which itself is INSIDE a module is: > > DistributeDefinitions[degenes, subraw, addonpos]; > > finaldegenes = > Partition[ > Flatten[ParallelTable[ > Append[degenes[[i]], > Flatten[Select[subraw, #1[[1]] == degenes[[i, 1]] &]][[ > addonpos]]], {i, 1, Length[degenes]}, > Method -> "CoarsestGrained"]], (Length[degenes[[1]]] + > Length[addonpos])]; > > ------------------- > > All the variables are themselves in the Global context and I can say that the code does work without error, if I comment out the DistributeDefinitions statement, and revert to a Table command rather than ParallelTable. > > I have tried to fix this problem by referring to the variables by their full context name, such as: Parallel`Preferences`degenes without success. I have also tried localizing all variables inside the module, and I still get the shadow error regardless. > > Do you see anything obviously wrong? > > What strategies do you use to figure out shadow problems in your own code? The reason I ask, is because I have tried to further isolate this problem to see if the variable contexts are changing....but it is not obvious to me they are. > > This is a frustrating one. Thank you for any thoughts you might have! > > Todd
From: Emily Reiss on 15 Feb 2010 05:46 It does indeed seem that there is a variable called "list" in parallel`Preferences`: In[34]:= Names["Parallel`Preferences`*"] Out[34]= {"Parallel`Preferences`add", \ "Parallel`Preferences`addPreference", "Parallel`Preferences`clear", \ "Parallel`Preferences`debugPreference", \ "Parallel`Preferences`debugQ", "Parallel`Preferences`exists", \ "Parallel`Preferences`get", \ "Parallel`Preferences`InitializePreferences", \ "Parallel`Preferences`list", "Parallel`Preferences`load", \ "Parallel`Preferences`Preferences", "Parallel`Preferences`prefs", \ "Parallel`Preferences`Scope", "Parallel`Preferences`set", \ "Parallel`Preferences`tr"} It surely seems to me that whoever did the design review at WRI of the code in the Parallel`Preferences` context was not paying enough attention to the rules. First of all, the exposed variables should conform to the "CamelCase" convention. Second, any variables that are not needed in an exposed context should be in the *`Private` context. What I suspect though is the the developer of the Parallel`Preferences` code did not expect that Needs would ever be called on the context. But, to get back to your problem, if at any point in your code you use a variable called list, then perhaps simple renaming of it would remove the shadowing messages... --David On Feb 14, 5:59 am, Todd Allen <genesplice...(a)yahoo.com> wrote: > Hi Everyone, > > I am trying to accelerate some code using ParallelTable, but when I do , I get the following error message: > > list::shdw: Symbol list appears in multiple contexts {Parallel`Preferences`,Global`}; definitions in context Parallel`Preferences` may shadow or be shadowed by other definitions. >> > > ---------------------- > > The basic outline of my code, which itself is INSIDE a module is: > > DistributeDefinitions[degenes, subraw, addonpos]; > > finaldegenes = > Partition[ > Flatten[ParallelTable[ > Append[degenes[[i]], > Flatten[Select[subraw, #1[[1]] == degenes[[i, 1]] &]][[ > addonpos]]], {i, 1, Length[degenes]}, > Method -> "CoarsestGrained"]], (Length[degenes[[1]]] + > Length[addonpos])]; > > ------------------- > > All the variables are themselves in the Global context and I can say that the code does work without error, if I comment out the DistributeDefinitions statement, and revert to a Table command rather than ParallelTable. > > I have tried to fix this problem by referring to the variables by their full context name, such as: Parallel`Preferences`degenes without success. I have also tried localizing all variables inside the module, and I still get the shadow error regardless. > > Do you see anything obviously wrong? > > What strategies do you use to figure out shadow problems in your own code? The reason I ask, is because I have tried to further isolate this problem to see if the variable contexts are changing....but it is not obvious to me they are. > > This is a frustrating one. Thank you for any thoughts you might have! > > Todd
From: David Reiss on 16 Feb 2010 03:52 Of course this message was from me, not my alter-ego Emily. I suppose it's probably good to check who is logged in when using a different computer in the house! --david On Feb 15, 5:46 am, Emily Reiss <> wrote: > It does indeed seem that there is a variable called "list" in > parallel`Preferences`: > > In[34]:= Names["Parallel`Preferences`*"] > > Out[34]= {"Parallel`Preferences`add", \ > "Parallel`Preferences`addPreference", "Parallel`Preferences`clear", \ > "Parallel`Preferences`debugPreference", \ > "Parallel`Preferences`debugQ", "Parallel`Preferences`exists", \ > "Parallel`Preferences`get", \ > "Parallel`Preferences`InitializePreferences", \ > "Parallel`Preferences`list", "Parallel`Preferences`load", \ > "Parallel`Preferences`Preferences", "Parallel`Preferences`prefs", \ > "Parallel`Preferences`Scope", "Parallel`Preferences`set", \ > "Parallel`Preferences`tr"} > > It surely seems to me that whoever did the design review at WRI of the > code in the Parallel`Preferences` context was not paying enough > attention to the rules. First of all, the exposed variables should > conform to the "CamelCase" convention. Second, any variables that are > not needed in an exposed context should be in the *`Private` context. > What I suspect though is the the developer of the > Parallel`Preferences` code did not expect that Needs would ever be > called on the context. > > But, to get back to your problem, if at any point in your code you use > a variable called list, then perhaps simple renaming of it would > remove the shadowing messages... > > --David > > On Feb 14, 5:59 am, Todd Allen <genesplice...(a)yahoo.com> wrote:> Hi Every= one, > > > I am trying to accelerate some code using ParallelTable, but whe= n > > I do , I get the following error message: > > > > > > > list::shdw: Symbol list appears in multiple contexts {Parallel`Preferen= ces`,Global`}; definitions in context Parallel`Preferences` may shadow or b= e shadowed by other definitions. >> > > > ---------------------- > > > The basic outline of my code, which itself is INSIDE a module is: > > > DistributeDefinitions[degenes, subraw, addonpos]; > > > finaldegenes = > > Partition[ > > Flatten[ParallelTable[ > > Append[degenes[[i]], > > Flatten[Select[subraw, #1[[1]] == degenes[[i, 1]] &]][[ > > addonpos]]], {i, 1, Length[degenes]}, > > Method -> "CoarsestGrained"]], (Length[degenes[[1]]] + > > Length[addonpos])]; > > > ------------------- > > > All the variables are themselves in the Global context and I can say th= at the code does work without error, if I comment out the DistributeDefinit= ions statement, and revert to a Table command rather than ParallelTable. > > > I have tried to fix this problem by referring to the variables by their= full context name, such as: Parallel`Preferences`degenes without succes= s. I have also tried localizing all variables inside the module, and I s= till get the shadow error regardless. > > > Do you see anything obviously wrong? > > > What strategies do you use to figure out shadow problems in your own co= de? The reason I ask, is because I have tried to further isolate this pr= oblem to see if the variable contexts are changing....but it is not obvious= to me they are. > > > This is a frustrating one. Thank you for any thoughts you might have= ! > > > Todd
From: David Reiss on 16 Feb 2010 03:53 I think that it's worth noting that these problems (poor attention to conventional Mathematic coding rules) appear throughout a number of non-Private` contexts of the form Parallel`*`*`. These contexts appear when the Parallel Kernel Configuration panel is opened (under the Evaluation Menu) is opened, Once that is done execute Names["Parallel`*`*"] and see the various parameter names. --David On Feb 15, 5:46 am, Emily Reiss <shirahs...(a)gmail.com> wrote: > It does indeed seem that there is a variable called "list" in > parallel`Preferences`: > > In[34]:= Names["Parallel`Preferences`*"] > > Out[34]= {"Parallel`Preferences`add", \ > "Parallel`Preferences`addPreference", "Parallel`Preferences`clear", \ > "Parallel`Preferences`debugPreference", \ > "Parallel`Preferences`debugQ", "Parallel`Preferences`exists", \ > "Parallel`Preferences`get", \ > "Parallel`Preferences`InitializePreferences", \ > "Parallel`Preferences`list", "Parallel`Preferences`load", \ > "Parallel`Preferences`Preferences", "Parallel`Preferences`prefs", \ > "Parallel`Preferences`Scope", "Parallel`Preferences`set", \ > "Parallel`Preferences`tr"} > > It surely seems to me that whoever did the design review at WRI of the > code in the Parallel`Preferences` context was not paying enough > attention to the rules. First of all, the exposed variables should > conform to the "CamelCase" convention. Second, any variables that are > not needed in an exposed context should be in the *`Private` context. > What I suspect though is the the developer of the > Parallel`Preferences` code did not expect that Needs would ever be > called on the context. > > But, to get back to your problem, if at any point in your code you use > a variable called list, then perhaps simple renaming of it would > remove the shadowing messages... > > --David > > On Feb 14, 5:59 am, Todd Allen <genesplice...(a)yahoo.com> wrote:> Hi Every= one, > > > I am trying to accelerate some code using ParallelTable, but whe= n > > I do , I get the following error message: > > > > > > > list::shdw: Symbol list appears in multiple contexts {Parallel`Preferen= ces`,Global`}; definitions in context Parallel`Preferences` may shadow or b= e shadowed by other definitions. >> > > > ---------------------- > > > The basic outline of my code, which itself is INSIDE a module is: > > > DistributeDefinitions[degenes, subraw, addonpos]; > > > finaldegenes = > > Partition[ > > Flatten[ParallelTable[ > > Append[degenes[[i]], > > Flatten[Select[subraw, #1[[1]] == degenes[[i, 1]] &]][[ > > addonpos]]], {i, 1, Length[degenes]}, > > Method -> "CoarsestGrained"]], (Length[degenes[[1]]] + > > Length[addonpos])]; > > > ------------------- > > > All the variables are themselves in the Global context and I can say th= at the code does work without error, if I comment out the DistributeDefinit= ions statement, and revert to a Table command rather than ParallelTable. > > > I have tried to fix this problem by referring to the variables by their= full context name, such as: Parallel`Preferences`degenes without succes= s. I have also tried localizing all variables inside the module, and I s= till get the shadow error regardless. > > > Do you see anything obviously wrong? > > > What strategies do you use to figure out shadow problems in your own co= de? The reason I ask, is because I have tried to further isolate this pr= oblem to see if the variable contexts are changing....but it is not obvious= to me they are. > > > This is a frustrating one. Thank you for any thoughts you might have= ! > > > Todd
|
Next
|
Last
Pages: 1 2 Prev: Polar coordinates - ReplaceAll issue Next: need help determined time to travel a path |