MATLAB Answers

1

Parfor loop introduces strange R%1 variable when using 2 reduction variables

Asked by Wouter Grimme on 4 Jan 2019
Latest activity Commented on by Yair Altman on 7 Jan 2019
Problem:
When I run my code that has two reduction variables, a strange R%1 variable gets created.
If you were to run the following example code, resembling the syntax of my real code:
clear all;
N = 100;
A = 0;
B = 0;
parfor n = 1:N
A = A + 3;
B = B + 4;
end
Matlab creates a strange R%1 variable in the workspace:
Screenshot_1.png
If one were to click on the variable, Matlab throws an error that the variable is an invalid expression.
When you comment out either A or B in the parfor loop, the variable is not created:
clear all;
N = 100;
A = 0;
B = 0;
parfor n = 1:N
A = A + 3;
%B = B + 4;
end
Screenshot_2.png
Two questions:
  1. What am I doing wrong/missing here?
  2. Is the result affected? i.e. is R%1 a warning that my result is not what I would expect it to be?
A big thank you to anyone who can help me out!

  0 Comments

Sign in to comment.

2 Answers

Answer by Wouter Grimme on 4 Jan 2019
Edited by Wouter Grimme on 4 Jan 2019
 Accepted Answer

The reply on the submitted service request:
This is a known bug which is fixed with R2019a. The bug relates to the parfor transformation in scripts. We denote synthetic temporary variables with a percent. One way to avoid having R%1 in the Workspace would be to wrap the parfor call in a function, as a function's Workspace is cleared once it returns its output. You can also simply ignore these variables as they have no impact on the calculation itself.

  1 Comment

I took the time to research and answer your question, and then you go ahead and post and accept your own answer, which basically just confirms and repeats my original answer. That's low. Don't expect me to take time to assist you ever again. And if I ever come across any other question that you will post, I'll make sure that readers know that this is how you treat their time.

Sign in to comment.


Answer by Yair Altman on 4 Jan 2019
Edited by Yair Altman on 4 Jan 2019

I was able to reproduce your problem on my R2018a and R2018b Windows10 installation, but not in 19a.
Apparently this bug (it is definitely one) was fixed for the upcoming 19a release. This being said, I don't believe that the results are affected - it looks like an interim value that was simply left un-cleared by the parallelization engine.
If this bothers you in 18a and you are unable to use 19a, then contact MathWorks and ask them if they could give you a workaround or patch that will fix the problem in 18a.

  1 Comment

I have created a support request, maybe it is a known bug that is fixed in R2019a.
Might give R2019a a try, but I must be sure that the computations are not affected by the bug.

Sign in to comment.