MATLAB Answers

Birdman
0

assignin and eval functions

Asked by Birdman
on 3 Nov 2017
Latest activity Edited by Stephen Cobeldick 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.

  2 Comments

Adam
on 3 Nov 2017
It isn't the responsibility of a language to enforce good programming standards. You can hang yourself in appalling ways with memory leaks in C++ and misuse of pointers and any number of things in any language I imagine.
Birdman
on 3 Nov 2017
I agree with you but anyway, I got what I need. Thanks.

Sign in to comment.

2 Answers

Answer by Stephen Cobeldick on 3 Nov 2017
Edited by Stephen Cobeldick on 11 Dec 2017
 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

Birdman
on 3 Nov 2017
Thank you for your attention.
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.

Sign in to comment.


Jan
Answer by Jan
on 5 Nov 2017
Edited by 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.

  0 Comments

Sign in to comment.