# DistributeDefinitions doesn't work as expected when used for table iterator bounds?

I am new to parallelization in Mathematica, so this question may reflect some elementary confusion. I am attempting to parallelize a rather complicated module which, as part of its internal operation, builds some tables. I ran into some mysterious-looking errors, and the code doesn't work. It turns out that the errors occur even when I try to run some very simple code:

K=3;
DistributeDefinitions[K];
ParallelEvaluate[Table[0, {i, 1, K}]]


I am using 2 parallel kernels, so I would expect this to generate the result

{{0, 0, 0}, {0, 0, 0}}


It actually does generate this result but it also generates errors:

(kernel 1) Table::iterb: Iterator {i,1,K} does not have appropriate bounds.
(kernel 2) Table::iterb: Iterator {i,1,K} does not have appropriate bounds.


I suppose that this means the parallel kernels are returning the command unevaluated, and then it's being evaluated by the master kernel before the output is printed. What's going on -- how can I get the parallel kernels to use the value of K?

I am using Mathematica 8.0.4.0. Thanks in advance for any insight!

-

The problem is that capital-K is a reserved word.

?K


K is a default generic name for a summation index in a symbolic sum.

Other single-character variables to avoid are:

C, D, E, I, N, O


Generally, you should avoid using variables that start with a capital character. It is not forbidden, but starting with a lowercase character will prevent you from colliding with built-in definitions that all start with a uppercase character.

-
Oh, fantastic, thank you! I'll change the name. It's funny: if I try to assign a value to C, D, E, I, N, or O, I get an immediate complaint that the symbol is protected. On the other hand Mathematica is perfectly happy to let me use K, and indeed I have been using it for quite some time; everything works fine AS LONG AS I don't try to distribute it to some other parallel kernels! –  Andrew Neitzke Apr 24 '12 at 21:29
@AndrewNeitzke K is the only one that doesn't have the attribute Protected, which is why it lets you assign a value to it. Not knowing that K is built-in can bite you at times (and be hard to spot if you didn't know). See here for an example –  rm -rf Apr 24 '12 at 21:37