assignin and eval functions
Show older comments
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.
Accepted Answer
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.
8 Comments
It is always possible to write bad code, no matter what features a language has. For example using a loop might be a really inefficient way to solve a particular problem: you would say that MATLAB should remove for and while, just because someone might use it inefficiently?
If you spend a few minutes searching this forum you will find plenty of examples of people writing inefficient code for all kinds of reasons (and dynamic variable names is just one of many!), and the answers often give advice on how to improve that code. Would you say that MATLAB should remove every feature that beginners use to write inefficient code? Would that really be a useful solution to the problem?
After removing all of these features, there would not be much left of the language... and then you might start to realize, that those features, when used correctly, are actually quite useful.
"Why using assignin or eval while there are more efficient and secure ways?"
Why are you asking me that? I don't use eval or assignin, I do use the more efficient and secure ways of writing code. If you want to know why people use those methods, there are plenty of threads where beginners state why they use those methods. Go and read them.
Birdman
on 3 Nov 2017
Birdman
on 3 Nov 2017
"...many of inefficient coding discussions mainly focus on the usage of assignin and eval functions..."
It seems to be a common way to write inefficient MATLAB code. There is always going to be some inefficient practices in any language, and with MATLAB this happens to be one of them: if it was not this then it would be something else. In other languages you will find other inefficient practices, depending on how that language works and what features it has. The task of the programmer is to write efficient algorithms, which relies on learning how to use that language effectively. Do you imagine that it is possible to create a language in which it is not possible to write inefficient code?Please develop and release it publicly: I would love to give it a try, to see how it would resolve my totally inefficient algorithm: would it simply refuse to run it?
"...I am really tired to see those discussions"
What can we do to help you?
"I did not see many discussions about inefficient usage of for or while loop."
I totally disagree. There are many discussions advising people to replace loops with vectorized code, or to preallocate variables before the loop, and giving other advice on how to improve and simplify their code. I would estimate that half of the posts on this forum involve some advice on how to improve the code algorithm or use simpler or more efficient methods. Every discussion on floating point numbers is also a discussion on making the OP's code better. And that is the common factor: how to make the code simpler, more efficient, neater, more robust, easier to debug.
"Do for and while loop cause such a situation? I did not read anything like this anywhere. If there is a discussion, I would like you to share it with me."
You obviously haven't searched very hard: search this forum for "vectorize" or "preallocate" and tell me how many threads you find. They both significantly affect code efficiency, compactness, and readability too. Why do you imagine that we keep giving advice on code vectorization and array preallocation?
Birdman
on 3 Nov 2017
Steven Lord
on 3 Nov 2017
One way to think about this situation: eval is a chainsaw. There are a few problems for which a chainsaw is the correct tool to use. But there are many common problems for which a chainsaw could work but is not the right tool for the job.
- You could use a chainsaw to cut your food at the dinner table, but some sort of knife (depending on the food either a butter knife, a steak knife, or maybe a carving knife) is a better choice.
- You could use a chainsaw to destroy papers containing sensitive information that are no longer needed, but a paper shredder is better suited for the task.
- You could use a chainsaw to cut down a tree that's 3 feet in diameter as part of a logging operation in a forest, and in fact then it's the right tool for the job.
If you need to write MATLAB code for eating dinner, or shredding paper, or cutting small pieces of balsa wood to build a model airplane, don't use a chainsaw. It may look and sound cool, but it can be dangerous and/or overkill.
On the other hand, if you're a trained lumberjack hopefully you know how and when to use the chainsaw and when not to use 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.
More Answers (1)
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:
- 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.
- 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.
Categories
Find more on Parallel Computing Toolbox in Help Center and File Exchange
