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

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:

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

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!

Answer 1

[Wouter Grimme]

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.

[Yair Altman]

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.

Answer 2

[Yair Altman]

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.

[Wouter Grimme]

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.