"unable to classify the variable in the body of the parfor-loop"

21 views (last 30 days)
I tried
X=ones(b*n,5)
parfor (a=1:n, 12)
Y=X((a-1)*b+1:1:a*b,3:4);
sorted=sort(Y(:));
Z=sorted(end-2);
X((a-1)*b+1:1:a*b,5)=Z;
end
and obtained
Error: Unable to classify the variable 'bidder_samples' in the body of the parfor-loop. For more information, see Parallel for Loops in MATLAB, "Solve Variable Classification Issues in parfor-Loops".
What would be the next step?

Answers (1)

Edric Ellis
Edric Ellis on 5 Aug 2020
The doc page you mention describes the valid ways of getting results out of a parfor loop. In your case, you appear to be computing distinct chunks of column 5 of X based on chunks of columns 3:4 of X. To fit in with the parfor rules though, you must re-write your code a little to make the references into X be compatible with "slicing". One way to do that would be to make X be n-by-b-by-5, and then do something like this (completely untested):
X34 = ones(n, b, 2); % corresponds to X(:,3:4)
Xout = ones(n, b); % corresponds to X(:,5)
parfor a = 1:n
Y = X34(a,:,:);
% compute Z
Xout(a,:) = Z;
end
  5 Comments
Martin Grden
Martin Grden on 17 Jun 2022
General question on parfor:
Mathworks, why do you make this so complicated (classifications, slicing) ?
I spend hours on finding out how to accommodate the demands regarding multidimensional arrays with computed indices and was still unsuccessful !
This is how it should be done in my opinion (OpenMP example):
#pragma omp parallel for default(none) num_threads(numthreads) private(i)
for (i = 0; i < 100; i++)
{
int tid = omp_get_thread_num();
...I do what I want in thread tid...
}
Edric Ellis
Edric Ellis on 20 Jun 2022
@Martin Grden I totally agree that the constraints of parfor make it harder to use than we'd like, and the error messages / code suggestions you get don't always help. I am very keen for us to improve in this area. In my mind, I distinguish between the constraints that are based on the "philosophy" of parfor, and those that are "just" limitations of the current implementation.
The "philosophy" (and this is just my opinion, based on working on parfor for many years) of parfor is definitely different to the OpenMP approach (with which I must confess I'm not hugely familiar). From the outset, parfor is designed to have a number of attributes:
  • Work across multiple processes on multiple machines
  • Be (hopefully) efficient in terms of data transfer
  • Be deterministic (and order-independent)
Those attributes are at the heart of what is usually the thorniest part of parfor - satisfying the "sliced output" requirements. parfor satisfies the attributes above by requiring output data to be "sliced" - that means that it must be possible up front to identify which loop iterations are going to assign to which elements of an output variable. So much for "philosophy". The implementation requires a way of ensuring that outputs are "sliced", and it is constrained to do this by analysing the parfor loop you've written. This is where the current restrictions come from - the implementation has to be able to prove that you are writing to the correct regions of the outputs, and it has to be able to do that by analysing the text of the program.
There are definitely several constraints that could (in principle) be relaxed, and hopefully some of these will be addressed in the future. For instance something like this might one day be permitted:
parfor i = 1:N
out(i,1) = 7;
out(i,2) = 8;
end
There's nothing "philosophically" wrong with that code, but the current implementation just can't handle it.
On the other hand, something like this is much less likely to be permitted, since it is not deterministic
parfor i = 1:N
out(1 + mod(i,10)) = rand();
end

Sign in to comment.

Categories

Find more on Loops and Conditional Statements in Help Center and File Exchange

Tags

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!