parfor unable to classify, why?

Can someone explain why the ind2sub first statement triggers the error, but the second works fine?

m = 2;
n = 3;
mycell = cell(m,n);
parfor k = 1:numel(mycell)
    [i,j] = ind2sub(size(mycell), k); % MATLAB complains cannot classify mycell because of this
    %[i,j] = ind2sub([m n], k); % this iis however accepted
    mycell{k} = 1;
end

Error: Unable to classify the variable 'mycell' in the body of the parfor-loop. For more information, see Parallel for Loops in MATLAB, "Solve Variable Classification Issues in parfor-Loops".

Answer 1

[Matt J]

I suspect it is because mycell is intended to be a sliced variable, but the code violates the fixed indexing rule,

Fixed Index Listing. Within the first-level indexing of a sliced variable, the list of indices is the same for all occurrences of a given variable.

since in one place you index mycell with {k} and elsewhere you do not index it at all. Notice that this also doesn't work:

m = 2;
n = 3;
mycell = cell(m,n);
parfor k = 1:numel(mycell)
    mycell;
    mycell{k} = 1;
end

I also vaguely wonder if it makes sense for a parpool worker to try to determine the size() of a sliced variable when it only receives a piece of it.

[Bruno Luong]

Hmm I still don't understand.

Yes mycell is intended to be sliced variable, the only place where the first-level indexing is

mycell{k} = 1;

so to me it is the same for all occurences of a given variable. So I don't see why violate the rule.

I can understand about the size statement, the worker indeed receive a piece of it, and the internal detail of how the data are transmitted is not user issue, but here I use the meta data of the variable and then the error message is completely missleading IMO.

[Matt J]

So I don't see why violate the rule.

I believe the indexing rule is to imply that all occurences of the variable have to be indexed, not just that the indexing has to take the same form. It is as if you had tried to do,

m = 2;
n = 3;
mycell = cell(m,n);
parfor k = 1:numel(mycell)
    [i,j] = ind2sub(size(mycell(:,:)), k); 
    mycell{k} = 1;
end

This makes sense as well because suppose someone tried to do this:

m = 2;
n = 3;
A=rand(m,n)
parfor k = 1:numel(A)
    s=myfunc(A);
    A(k)=1;
end

function s=myfunc(A)
 s=sum(A);
end

The operation s=sum(A) requires the entire matrix A, and so the parser does not know if it is free to send just a slice of A to the worker.

[Edric Ellis]

@Matt J is exactly correct. For a variable to be a sliced output, every occurrence inside the parfor loop must be indexed, and indexed in the same way. Unfortunately, the parfor analysis indeed isn't smart enough to realise that an expression like size(mycell) doesn't need the values. (And yes, the error messages / code analyzer messages you get when you encounter this sort of problem can be hard to interpret - we're hoping to improve these).

[Matt J]

@Edric Ellis If mycell were sliced, is it even possible for a parpool worker to determine its original size? Putting it another way, does a sliced variable somehow carry the metadata of the original, unsliced variable?

[Edric Ellis]

@Matt J no, the sliced portion on the worker doesn't directly know the metadata of the original array (but the code running on the worker does know enough to make sure it writes the correct piece of the sliced portion that it is working with) - this is just one reason why it's not valid to attempt to access the "whole" variable in any way in the body of the loop.