Why do the values of a NaN matrix change to zero inside a parfor?

I am using parfor to compute certain values. These values only need to be computed for certain iterations. However, for the iterations that I don't need to compute them, it appears that parfor is assigning the value 'zero' to the output even though the output has been preallocated as NaN.

The behavior that I described can be replicated through this code

result_size =[1,1,3,3,3,1,1,2,1,5,7,7,5];
total_conf=prod(result_size);
t_out = NaN(result_size);
parfor i=1:total_conf
  temp1 = rand();
  if (temp1>0.5)
      %t_out(i)=NaN;
      continue;
  else
      t_out(i)=5;
  end
end
s1=sprintf('\nNumber of elements equal to zero in the output %d',sum(t_out(:)==0));
disp(s1);

At the end of this procedure, the result is that several elements in the output have been set to zero, even though the code inside parfor does not specify such assignment. If the line

%t_out(i) = NaN;

is uncommented and the script is run again, then at the end of the procedure it is correctly reported that there are no values in the output that were set to zero.

My question is: why does parfor assigns the value 'zero' to some elements of the pre-allocated NaN array?

[Edric Ellis]

I don't see this. Which version of MATLAB/PCT are you using? In R2015a, I ran the following code and the assertion at the end passed:

out = NaN(1,10);
parfor idx = 1:10
  if idx > 5
      continue;
  else
      out(idx) = 1;
  end
end
assert(sum(isnan(out)) == 5);

[Elias]

Hi Edric,

Thank you for your comment. I am using Matlab R2014a.

When I ran your code, the assertion also passed.

Based on your code, I created a simpler example where the error happens:

out = NaN(2,3,4);
parfor idx = 1:24
  if idx < 12
    continue;
  else
    out(idx) = 1;
  end
end
assert(sum(out(:) == 0) == 0);

When I run this code, the assertion fails.

[the cyclist]

I am running R2015a. Your assertion (in your simplified example) fails for me, too. It passes if I just use a for loop, rather than parfor.

[Elias]

Indeed, if I use the for loop, the assertion passes. Nonetheless, I originally expected the assertion to also pass when using the parfor loop.

If possible, I would like to understand whether the parfor has a bug in its implementation, or if there is some particular guideline/documentation regarding the use of a "continue" inside a parfor that would explain why the assertion is failing.

[the cyclist]

This definitely seems like a bug to me. I think you should submit it to support.

[Elias]

Thanks for the response. I will submit the bug to support.