The variable ... in a parfor cannot be classified?

I'm trying to a run use parfor to loop through 6 different lengths of time for a time series, find the percent changes in them, and store them in a table. I'm getting the following error, however. The variable relPerformance in a parfor cannot be classified.

The problem appears to be with the line "relPerformance.(n)('Russell3')." Does anyone know what's going on here?

parfor n =1:6 
    if length(Russell3TRSeries) > periodAdjustors(n)
        relPerformance.(n)('Russell3') = (Russell3TRSeries(...
            length(Russell3TRSeries))/Russell3TRSeries(length(Russell3TRSeries)-...
            periodAdjustors(n)))^(1/(periodAdjustors(n)/12))-1;
    end 
end

Answer 1

[Matt J]

It runs fine for me when I change relPerformance.(n)('Russell3'), which is not legal MATLAB syntax, to

relPerformance(n).('Russell3')

[Barath Balu]

Hi Matt,

I should clarify. relPerformance is a table, not an array. So relPerformance.(n)('Russell3') is the syntax I would use to write data to column n and row 'Russell3'

[Matt J]

This violates the rules for parfor sliced variables, in particular, where it says

"Type of First-Level Indexing — The first level of indexing is either parentheses, (), or braces, {}."

I recommend that within the loop you build the table in array form with plain old {}-indexing or ()-indexing. The conversion from array to MATLAB table type can be done very rapidly after the loop.

Answer 2

[Walter Roberson]

If we temporarily pretend that you are not using a table, then your code can be rewritten as

parfor n =1:6 
  if length(Russell3TRSeries) > periodAdjustors(n)
      output(n) = (Russell3TRSeries(end)/Russell3TRSeries(end - periodAdjustors(n))) ^ (1/(periodAdjustors(n)/12))-1;
  end 
end

Notice that here you have an array periodAdjustors which is being indexed at the loop variable and that is being turned into an offset. Because of this, the order in which the slices access Russell3TRSeries is not determined only by n: it depends on what periodAdjustors happens to contain. That is not legal in a parfor. Consider for example that periodAdjustors might have duplicate entries, so the same location in Russell3TRSeries might be required by different iterations of the parfor (yes, this does imply different iterations of the parfor might calculate exactly the same thing, but store it in different locations.)

If periodAdjustors is intended as a permutation vector, then you should do the calculation without permutation in the parfor, storing to an intermediate variable, and then do the permutation and final storage after the parfor.

[Matt J]

Because of this, the order in which the slices access Russell3TRSeries is not determined only by n: it depends on what periodAdjustors happens to contain.

Seems perfectly fine to me as long as Russell3TRSeries appears on the right hand side of any assignment operations (and again, MATLAB didn't complain when I ran it). Basically, it means that Russell3TRSeries will be treated as a broadcast variable rather than a sliced variable. This may be inefficient if Russell3TRSeries is a large array, but shouldn't cause any errors.