assignin and eval functions

19 views (last 30 days)
Birdman on 3 Nov 2017
Edited: Stephen23 on 11 Dec 2017
Hi everyone,
I have a question that really tangles my mind. The experienced contributors to the forum always emphasize avoiding usage of assignin and eval functions due to many reasons. I now know the reason for it thanks to Walter Roberson especially. Then why MATLAB does not stop their usage? I really need to be enlightened about this issue.
Birdman on 3 Nov 2017
I agree with you but anyway, I got what I need. Thanks.

Sign in to comment.

Accepted Answer

Stephen23 on 3 Nov 2017
Edited: Stephen23 on 11 Dec 2017
You totally misunderstand the issue if you think that eval, evalin or assignin are faulty.
There is nothing wrong with eval, evalin, or assignin, in the sense that they work exactly as documented and do exactly what they are supposed to do. Sometimes these functions are useful. But...
The problem is that what they do lets many beginners use them totally inappropriately, to solve tasks that would be much better solved using simpler, faster, neater, more efficient, easier to debug and much more robust methods (usually indexing is the simpler solution). Simply put, those beginners design their code in such a way that they force themselves to write bad code: slow, buggy, hard to debug, insecure, complex, ugly code. By deciding to write such bad code they remove all of the inbuilt code checking and code helper tools. They also remove any ability for the JIT compiler to speed up their code. They remove the ability to search for and locate variables. The list goes on. Even if all other things were equal, any one of these disadvantages would be reason enough to avoid dynamic variable names.
Or, to put it another way, the problem is not using eval in particular, the main problem is dynamically accessing variable names. It just happens that magically defining or accessing variable names is most commonly achieved using eval and assignin, but the problem actually occurs regardless of what tool or method is used to access them: it also applies to load, for example, when load is called without an output variable.
You need to stop asking "what is the problem with eval?", and start asking yourself "why is it so inefficient to dynamically access variable names?". To help understand some of the issues that is causes, read this thread:
You are not the first beginner to ask this question. Some of them get really confused, because they think that there is a problem with eval. For example, read this discussion, including all of the answers and comments:
"The experienced contributors to the forum always emphasize avoiding usage of assignin and eval functions due to many reasons."
You will notice that the title of my tutorial is actually "TUTORIAL: Why Variables Should Not Be Named Dynamically (eval)". All of the discussions and links within that tutorial are focused on one topic: dynamically accessing variable names. You need to start reading about this topic if you really want to understand it.
Jan on 5 Nov 2017
@cvklpstunc: "Do for and while loop cause such a situation?" Because the body of for and while loops is processed repeatedly, the JIT acceleration can have more effects than in lines, which are processed once only. Therefore loops can suffer more from impeding the JIT by dynamically created variables, e.g. by eval, assignin, and load without output argument. Under some circumstances, a vectorization of loops can increase the speed substantially, or slow it down, if large temporary arrays are needed.
"I am really tired to see those discussions" Then you can support the forum by posting useful answers.

Sign in to comment.

More Answers (1)

Jan on 5 Nov 2017
Edited: Jan on 6 Nov 2017
The actual question is:
why MATLAB does not stop their usage
The drawbacks of eval and assignin have been discussed exhaustively already and explanations of better solutions can be found in this forum and in the documentation of Matlab.
I think, MathWorks does not remove these functions from the toolboxes, because:
  1. this would break the backward compatibility of many codes. Although the usage is deprecated and the problems are known, some code does use them and they work - inefficient, hard to debug and maintain, but a kind of "successful". This applies e.g. to callbacks, which are defined as strings: They are evaluated in the base workspace, and I assume, this is performed by eval. Of course it is recommended for over 15 years now to use functions handles, but the string callbacks are still allowed.
  2. it is not the responsibility of MathWorks, if users write bad code. Even load and save can emulate an eval with all its drawbacks, or the automatic creation of an M-file as a script and the run command. There are many ways to drill a whole in your knee and it is impossible to create a programming language, which is powerful and 100% bulletproof at the same time. The users have to care for the reliability and efficiency of their codes. Therefore MathWorks can and should rely on the users to read the documentation and trust the suggestions of experienced users in the forum.
But this is my assumption only. As a member of this public forum I can speculate only - but you can do this by your own, because this speculation is rather obvious and trivial. If you want a real answer, you have to ask MathWorks, of course, not the users in the forum.

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!