Particularly strange bug using the eval function

In the MWE below, I define a bunch of parameters using an eval command. I know that the experts recommend against using eval, as in this thread, but I don't really see an alternative in this instance. I also know that MATHWORKS would prefer me not to define variables that clash with their own builtins. However, the code still should work properly, but doesn't in this example.

The class for rho is correctly defined as double. But the fourth last line returns an error, as does the second last line. In both cases the code still thinks gamma is matlab's built-in function. Yet the third last line indicates that gamma is correctly defined as 0.6. Note that if I remove the first line of the code, and thus run the code in the base workspace, everything works as expected.

Could somebody please explain a) what's causing this bug and b) a simple alternative to my use of the eval function?

function nothing 
rhoY			= 0.8; 
phiY			= 0.8; 
gammaY			= 0.6; 
etaY			= 0.05;
muY				= .5;  
ecLetter		= 'Y';		
Params			= {'phi','rho','eta','gamma','mu'};
nParam			= numel(Params);
for ii=1:nParam;
	thisParam		= Params{ii};
	eval([thisParam '=' thisParam ecLetter ';']);
end;
%This kludge fixes the problem
tmp=gamma;
gamma=tmp;
class(rho)
class(gamma)
gamma
3*gamma
keyboard;

Answer 1

[per isakson]

I reproduced the issue you report on R2018b, Win10.

I noticed that if

• I put a breakpoint at the line "class(gamma)"
• run the function, nothing
• execute "class(gamma)" by select, right click, Evaluate Selection
• "class(gamma)" returns the result that you expect

The issue has something to do with the Just-In-Time (JIT) accelerator, I think. You could report it as a bug. (However, DB's answer make me believe they already knows about a bunch of similar cases.)

IMO:

• Experiments with this kind of code is a waste of time. However, the group working on the JIT should be interested in your observation.
• "but I don't really see an alternative in this instance." Describe "this instance" and someone here might come up with a better alternative.

[Leo Simon]

I'm running from the command line, so can't proceed as you suggest. But I do suspect you identified the problem. See my kludgy fix, added to my original post.

[per isakson]

I think, I more or less understand why your fix works.

The first time a function is called Matlab pre-compiles it and puts it in memory. If all variables are known at this point in time, that process works better. That's the reason why users are discouraged to use statements like "eval([thisParam '=' thisParam ecLetter ';']);" and "load mydata.mat". These statements creates new variables in the function workspace at execution time.

Your statements "tmp=gamma; gamma=tmp;" makes the variable gamma availble at pre-compile time. However, these statements requires that you know about gamma beforehand.

I would prefer to add the line

gamma = nan;    % shadow the built-in function

at the top of the function.

[Leo Simon]

Your suggestion does indeed solve my problem, thanks very much indeed. It's always been a problem for me that matlab has "dibs" on variables like alpha, beta and gamma, which I'm always wanting to use, especially when doing symbolic arithmetic. Presumably, this trick will free me up in symbolic analysis also.

[per isakson]

If this issue applies to a few or more names and to several of your functions, I propose that you create a script (not function) with the name shadow_matlab_functions.m. It might need a second thought where to put it.

shadow_matlab_functions.m shall look something like

% Concise description
% Detailed description
alpha = nan; 
beta = nan;
gamma = nan;
%
% NOTE: 2020-08-02, ...
% TODO: 
% FIXME: 

Then

• add the line shadow_matlab_functions to the top of your files when appropriate
• "run the code in the base workspace" run shadow_matlab_functions in the command window (whether needed or not)
• make annotations in the file when you learn more or encounters issues
• use Matlab's TODO/FIXME-report

This proposal is in line with first work around in Walter's list.

[Leo Simon]

Thanks Per, presumably I could just put them into my startup.m file? Unless I want to use matlab's builtins for these variab les, there doesn't seem to be any obvious downsides. If I do want to use the built-ins, I can just clear the nan-ed variablees first,

[per isakson]

I've never tried anything like that and I'm sceptical to it. One tends to forget what's in startup.m and one day three month from now one cannot understand what's going on. I was about to call the file SHADOW_MATLAB_FUNCTIONS (upper case) to make it more visible. Here our admin has configured Windows so that the users must type the user_name every time they login. When automatic it happened that user forgot their user_name and asked the helpdesk for support.

If you are the only one affected put it in startup.m and see if it works for you. (Nothing very bad will happen, I think.)

Anecdote: Twenty plus years ago I made a "smart" file that messed with the display of errors. We discussed the idea at the predecessor of this forum. One day a friend of mine told me that he failed to start Matlab after installing a new release. He was a bit desperate. Luckily enough I remebered the file.

[per isakson]

I've been luckily unaware of changes introduced in R2019b. (I still use R2018b.) Bruno Luong provides the link R2019b release note in his answer.

Very relevant to my answer is this change. The function (copied from the release note) below works in R2019a and earlier

function myfunc2
    myscript; % Contains variable x
    disp(x(:))
end

but needs to be changed for R2019b and later

function myfunc2
    x = [];
    myscript;
    disp(x(:))
end

Thus, my shadow_matlab_functions.m isn't useful in user functions with R2019b and later.

The release note refers to Function Precedence Order for more information. That page doesn't help me much regarding the current issue. However, I won't blame the page until I made a serious effort to read it.

[Stephen23]

"You could report it as a bug"

Not a bug, rather a fix to earlier ambiguous syntaxes. The general problem is NOT just related to changes in R2019b, because these ambiguous syntaxes have existed in many forms:

https://www.mathworks.com/matlabcentral/answers/28676-why-use-x-load-myfile-mat#answer_37821

https://www.mathworks.com/matlabcentral/answers/338434-how-do-i-force-matlab-treat-my-variable-range-as-a-variable-instead-of-a-function#answer_265415

https://www.mathworks.com/matlabcentral/answers/410758-function-call-doesn-t-work-in-script-works-in-command-window

I would not recommend using any kind of shadow script: that is just sweeping the hackery under the carpet, but does not actually fix the root cause: your "solution" will always be fragile and susceptible to any changes in precedence rules with past and future versions, as well as fragile to any changes in the path, the MATLAB installation, your own code distribution, etc.

The robust solution is to write code that does not magically name variables.

[dpb]

The OP's lament that common mthematical variables are builtin MATLAB functions is one of reality and I agree it is unfortunate that Cleve et al., didn't think of naming the functions differently initially to preserve the names for users as variables. But, hindsight is 20:20.

Name spaces or a dictionary something like Forth uses would be one way to be able to reduce some of the namespace pollution problem -- it is getting really crowded in here any more with all the new functionality even in the base space and the few toolboxes I have; by the time one has a full collection it must be getting difficult to not have name clashes.

It's not helped by the recent introduction of the multitude of similar functions for the same thing as were already provided...instead of fixing the existing ones. And, of course, hardly anything ever gets removed.

As for solving OP's problem, I think it is probably best to simply recognize that MATLAB is what MATLAB is and "go with the flow" and give in gracefully. The hacks to beat Mother Nature just aren't worth the effort; it's not like you can't accomplish the end objective otherwise.

Answer 2

[Walter Roberson]

This is defined behavior for the execution engine for the last few releases, and is not a bug. R2018b is the release that is springing to mind as when the change was made, but that would have to be re-checked.

The behavior defined is this:

Inside a function (and you are inside a function), when you have a reference to a name that MATLAB can see as a function on the search path, and there is no "plain text" assignment to a variable of that name, then MATLAB will now assume that plain-texts references to the name always refers to the function, even if the name is being assigned to by some side effect such as eval() or evalin() or executing a script.

A way of thinking about this is that MATLAB is now doing static analysis at the time the file is parsed, ignoring any potential non-obvious assignment.

The work arounds include:

• making a plain-text assignment to all variables that might be changed in non-obvious ways; or
• put the hidden assignments into a function and return the variables from the function (but this can just postpone the problem); or
• Don't Do That -- don't make hidden assignments to variables. For example, assign to fields of a struct inside a function and return the struct and access the fields; or
• use a class with static methods to create what are effectively constants

[Leo Simon]

Thanks, Walter. I think I sort of understand what you are saying. It seems that @per_Isakson's suggestion to put gamma=nan at the top of the file is a way of making an initial "plain text" assignment to gamma and thus solving the problem?

[per isakson]

"This is defined behavior for the execution engine for the last few releases" I don't find it in the on-line Help Center. Where should I look?

[Walter Roberson]

https://www.mathworks.com/help/releases/R2019b/matlab/matlab_prog/upgrade-code-for-r2019b-changes-to-function-precedence-order.html

Answer 3

[Matt J]

I also know that MATHWORKS would prefer me not to define variables that clash with their own builtins. However, the code still should work properly

I don't know why you think it should work properly. That is expected behavior and is one of the chief reasons eval is a bad idea. Also, it is unclear how you are executing your code and what errors you see. In particular, you say the 2nd and 4th last lines throw errors. But that should be impossible. If the 4th last line threw an error, the code should never reach the 2nd last line.

One easy solution is to use structs:

function nothing 
S.rho			= 0.8; 
S.phi			= 0.8; 
S.gamma			= 0.6; 
S.eta			= 0.05;
S.mu	        	= .5;  	

Params			= {'phi','rho','gamma'}; %subset
nParam			= numel(Params);
for ii=1:nParam;
	T.(Params{ii})=S.(Params{ii});
end;
class(T.rho)
class(T.gamma)
T.gamma
3*T.gamma
keyboard;

Obviously, if the goals is to copy all the fields in S, you don't need to use a for-loop. You could just do

 T=S;

[Leo Simon]

Thanks Matt, for various reasons I really don't want to use structs, though I see that it would solve the problem

[Matt J]

It's hard to see what those reasons might be. There is nothing you can do with indivdual variables that you cannot do with structs. They are basically the same thing, except one has a dot in its name.

Answer 4

[dpb]

From the doc--

Whenever possible, do not include output arguments within the input to the eval function, 
such as eval(['output = ',expression]). The preferred syntax,

  output = eval(expression)
allows the MATLAB parser to perform stricter checks on your code, preventing untrapped errors
and other unexpected behavior.

I don't see anything here that indicates any need for eval anyway over simply writing the explicit assignments; there are only five variables and it took four lines of code to write the loop and how much time and frustration debugging?

[John D'Errico]

10 upvotes to this response.

[per isakson]

The question starts: "In the MWE below, "

[dpb]

_The question starts: "In the MWE below, " _

I saw that too, and had/have no klew what it means?

[per isakson]

MWE stands for Minimal working example. Occasionally we ask for a MWE when the question includes a lot of irrelevant code. In that respect OP made an effort and ended up with only five variables.

[dpb]

A minimum would have needed only one... :)

But, same remark seems true if the workaround is to define the variable to "declare" it first...takes the same amount of code to do that as would to just define it w/o eval at all.

[Bruno Luong]

A true solution is MATLAB would allow users to define constants, not variable with unchaged value, similar to macro in C; the constant can be visible within local/global scope.

Might be the JIT accelerator does it already internally (?) who knows, as they said speed optimization is their business.

For sure it would be nice where as that kind of optimization occurs or not, at least for professional programmer. ;-)

[Walter Roberson]

some day I should test..

It is possible to subsasgn in the middle of an expression, and if I recall correctly it does change a variable in that position (that is, the new value is used in later parts of the expression.) This is similar to the way that assignin('caller') can affect a variable in an expression. I have tested these a bit for variables.

But at the moment I do not recall that I have tested for hard-coded constants: their slot can be assigned to using subsref and anonymous functions, but does that change other copies of the same literal in the line? (Though I seem to recall that I did test that once and found it did not happen, unlike the classical FORTRAN bug in early days where you could modify constants)

Answer 5

[Bruno Luong]

This is NOT a bug but documenented behavior from recent release

Read from R2019b release note

"If you intend to use x as a variable from data.mat instead of a function, explicitly declare it. Similarly, to use an identifier x as a variable obtained from a script, declare it before invoking the script. This new behavior also applies if the variable is implicitly introduced by the functions sim, eval, evalc, and assignin. "

The workaround as explained in this doc would be you "declare" your variables, e.g. initialize with variable name explicitly written down with empty value, then call EVAL to change the values. Then use it later.

I must admit that would defeat somewhat the goal.