Is there the more elegant way to do this?

I have 10 matrices(10*24 size each) named A1,A2,,,,A10.Now i want this

E1=sum(A1); 
E2=sum(A2); 
till E10=sum(A10);

thus E1,E2,,,,,E10 each matrices size of 1*24 . so there is another way to write in short code ?

[Stephen Cobeldick]

"I have 10 matrices(10*24 size each) named A1,A2,,,,A10"

Well, that is a bad way to write code: trying to access those variables dynamically will be slow, buggy, obfuscated, hard to debug, etc.

"Is there the more elegant way to do this?"

Yes, there is! It would be much simpler to put all of your data into one array, then your code will be simple, efficient, neat, easy to debug, etc, etc. Some other beginners will tell you to magically create variables, but instead you might like to read what the MATLAB documentation has to say about that: "A frequent use of the eval function is to create sets of variables such as A1, A2, ..., An, but this approach does not use the array processing power of MATLAB and is not recommended." (this advice also applies to evalin and assignin. source: https://www.mathworks.com/help/matlab/matlab_prog/string-evaluation.html

Read this to know more:

https://www.mathworks.com/matlabcentral/answers/304528-tutorial-why-variables-should-not-be-named-dynamically-eval

See KSSV's much simpler, more efficient answer.

Answer 1

[John BG]

Hi Mukesh Kumar

this is John BG <mailto:[e-mail] [e-mail]>

Elegance like beauty lives in the eyes of the observer, so while some people abhor the command evalin, I consider it's a really powerful and elegant option to simplify the generation of variables.

1.

Simulating data

A1=randi([-10 10],3)

A1 =

      -2     4   -10
       3   -10    -8
      -7    -5     7

>> A2=randi([-10 10],3)

A2 =

       4   -10     6
      -4    -1     6
       9    -2    -7

>> A3=randi([-10 10],3)

A3 =

       0     4     4
      -1     5     3
       3    -5    -7

2. Code that writes code

for k=1:1:3
str1=['E' num2str(k) '=sum(A' num2str(k) ')'];
evalin('base',str1)
end

E1 =

      -6   -11   -11

E2 =

       9   -13     5

E3 =

       2     4     0

if you find this answer useful would you please be so kind to consider marking my answer as Accepted Answer?

To any other reader, if you find this answer useful please consider clicking on the thumbs-up vote link

thanks in advance

John BG

<mailto:[e-mail] [e-mail]>

[Stephen Cobeldick]

"Elegance like beauty lives in the eyes of the observer, so while some people abhor , and always respecting their opinion, there is the command evalin, that I consider is a really powerful and elegant option to simplify the generation of variables."

Luckily we do not have to rely on subjective opinions to know what is required to write efficient code. There are good objective metrics to check how well written code is: evalin is slow, removes all useful code-checking tools, and totally ruins any JIT optimization. These might not be things that beginners are expected to understand (which is why they keep recommending such bad code practices to each other), but it is why experts keep advising those beginners to avoid using them. Any one of those poor metrics would be enough to stop using such inefficient and buggy code practices, but the combination makes it quite unbelievable that anyone would even want to use them.

MATLAB even has tools and documentation to help us to write efficient code: interestingly that advice is to avoid creating variables magically. How sad that beginners so rarely read it, or think that their stomach feeling is a more reliable way of judging the quality of code.

The company I work for make safety critical products (people die if they do not work), and our external assessors would laugh themselves blue if we wrote code using anything as awful as evalin or eval: buggy, removes all debugging tools, makes debugging difficult, no separation of workspaces, untraceable changes of values... yes, clearly we should advise beginners to use bad code practices, because that will really set them up well for their professional life.

[John BG]

this is a basic MATLAB question, not the debugging of an Airbus A380 mainframe.

So, in this context evalin is the right command to dynamically generate the variables that Mr Mukesh Kumar has asked for.

[MUKESH KUMAR]

exact answer that i require...........thanks

[Stephen Cobeldick]

@John BG: It might not be the debugging of an A380 airframe, but one day this user might be doing just that. There is no reason why beginners should not learn good practices from the start: it will do them well in later life. After all, breaking bad habits later is much harder than practicing good ones right from the very start.

@MUKESH KUMAR: although your title asks for a "more elegant way to do this", what you have picked in the slowest and buggiest way. I guess if your definition of "more elegant" is slower, buggier, harder to debug, harder to follow, less efficient, specifically the opposite of industry good practice and what the MATLAB documentation advises, then you have picked the right solution.

[Jan]

@MUKESH KUMAR: No, this is not the answer you require. Trust a bunch of experienced Matlab programmers. It might seem to solve the problem fast, but it will amplify the underlying problem of hidden indices in names. Changing the programming style would not only solve this problem, but equivalent problems would not occur in the future. A clean programming style is a much better advice than suggesting the evil eval, evalin or assignin.

As you see in the comments, this topic has been discussed hundreds of times in the forum, and it was always the best solution to switch to a clean programming pattern.

I agree with Stephen: This method is slower, buggier and harder to debug, and therefore a bad programming practice. There are not only "some people" in this forum: all but one and even MathWorks suggest to avoid eval like commands.

[John BG]

Hey Stephen, :) found another evalin related question

https://uk.mathworks.com/matlabcentral/answers/164603-suppression-failure-on-evalin-command?s_tid=srchtitle

Perhaps you would like to append your long list of comments to Misha's answer with evalin too?

[John BG]

Just for the record, the problems with evalin do not come from the command itself, but from the over complicated or inadequate structuring of the data attempted on evalin.

Yes, evalin is an edged command, handle with care, freedom comes at a price, but please Stephen answer the following questions if you know the answers:

1.

Why is that Mathworks doesn't remove it from the common toolbox? or locks it under a pile of forbidden regulations or warnings?

2.

Stephen, do you think that command evalin shouldn't exist?

3.

or do you think that Mathworks should keep it like fire arms in Europe? restricted with special licenses to just a few?

[Stephen Cobeldick]

"Just for the record, the problems with evalin do not come from the command itself, but from the over complicated or inadequate structuring of the data attempted on evalin."

Not at all, the problems really come from the command itself. The data structure is not the cause (but it might be a symptom). The problems come from the fact that eval, evalin and assignin totally destroy any JIT optimization, the interference in other workspaces makes code unreliable and non-deterministic, the difficulty in debugging, the speed, the obfuscation, etc. None of these are related to how complex the data is, or how data is structured. Using evalin, eval, etc to assign a simple scalar value still suffers all of these problems.

To answer your questions:

1. Like any language, MATLAB lets people write code as badly or as well as they wish. Once could also write a loop and expand an array within that loop: it will be slow and inefficient, but it is possible to do. Why would it be MATLAB's job to stop people doing this?
2. No.
3. ???

I don't see what any of those questions have to do with the topic at hand, which is that using eval, evalin, etc, to work with a sequence of variables is inefficient, slow, buggy, hard to debug, obfuscated, and a poor use of MATLAB. Apparently for some people those metrics count as being a "more elegant way to do this".

[Adam]

There's nothing more elegant than a workspace of 20 variables when 2 will do! All the more so when you find you need another 10 too. That feeling of scrolling down them all in your workspace or opening them all individually in the variable editor is so much fun.

The 'need' to use evalin or eval is like a lighthouse telling you you've gone the wrong way and should turn around rather than plough on. I'm sure there are more appropriate languages to code in though than Matlab when you ignore the things Matlab is built for!

[Jan]

 Just for the record, the problems with evalin do not come from the
 command itself, but from the over complicated or inadequate
 structuring of the data attempted on evalin.

I agree with Stephen's answer: "Not at all, the problems really come from the command itself." +10

[John BG]

If you all consider that the command evalin has problems,

have you already reported to Mathworks?

If so, what has been the answer?

So, just for the understanding of the readers, in your opinion:

Stephen Cobeldick, Jan Simon, Adam

all problems related to command evalin, do come from highly likely ill-posed input data, but it is always a problem of the command evalin?

in any case, why do you choose to ignore the human factor for this command, yet we all know that it must always be considered when attempting to solve MATLAB questions?

[Jan]

@John BG: Nobody claims, that evalin has a problem or bug, but it is inefficient by design. This cannot and need not be fixed, because it is the nature of this command. You cannot fix the language to avoid a forgotten pre-allocation also, or a hammer, when you hit on your thumb: The user is responsible for a careful work.

If you read the links, which have been posted already, you know MathWorks answers, e.g. Loren: evading eval and Matlab docs: Why Avoid the eval Function?.

Nobody ignores the additional mistakes in the construction of the string to be evaluated. But fixing the string is a too short-dated solution only, because the inherent problems remain - and they have been explained more then enough already.

You decide if you ignore or consider the clear and exhaustive arguments given by experienced programmers and MathWorks. We will proceed to explain the concerning drawbacks to beginners and teach good (better!) programming practices.

If you are interested in reputation points: eval got 4 points, and 20 for eval free suggestions.

Obviously, no new serious arguments occur in this discussion anymore and I leave it.

[Stephen Cobeldick]

"If you all consider that the command evalin has problems"

No one has said that the command itself is buggy, because the problems are simply inherent in what it does. The problems with evalin and its relatives are much more general and are not even specific to MATLAB: the issues are fundamental to how JIT compilers work, about the inefficiency of string evaluation, about how static code checking works, about how objects are identified in workspaces, about interference between threads or workspaces, about the risks of evaluating arbitrary code, and other aspects of high-level computing. Together these cause code that uses evalin (and eval, etc.), to be buggy, slow, unreliable, a security risk, hard to debug, obfuscated, etc., etc..

"have you already reported to Mathworks? If so, what has been the answer?"

Seriously, anyone can read the documentation: "Avoid functions such as eval, evalc, evalin, and feval(fname)". source: https://www.mathworks.com/help/matlab/matlab_prog/techniques-for-improving-performance.html

"in any case, why do you choose to ignore the human factor for this command, yet we all know that it must always be considered when attempting to solve MATLAB questions?"

We do consider the human factor: the factor that your own example clearly shows how using evalin turned a bug in a trivially simple one-line piece of code into something that the user could not solve by themselves. And that is why we recommend people to use methods that are simpler, faster, less buggy, easier to debug, more reliable, more secure, where the MLINT and Editor warnings help them, etc., etc. Which just happen to be the same methods that the MATLAB documentation recommends.

"...while some people abhor the command evalin, I consider it's a really powerful and elegant option to simplify the generation of variables."

You still have not explained why writing slower, buggier, inefficient, hard-to-debug, insecure code is "elegant". You have provided us with one example of where a user got completely flummoxed trying to fix code that used exactly that buggy and hard-to-debug coding method that you call "elegant" (code that should have been trivial to fix). I would be interest what magic secrets you know about evalin that no one else knows (including the authors of MATLAB who wrote the documentation advising to avoid evalin).

Answer 2

[KSSV]

You make A1,A2,...A10 matrices a 3D matrix while computing or defining them..and the call sum..

Read about sum..you can specify dimension there and you can apply this function on 3D matrix also.

A = rand(10,24,10) ;
B = sum(A) ;

[Stephen Cobeldick]

+1 simple and perfect. Nice work, KSSV.

[KL]

+1

[Jan]

+1. Exactly: 3D arrays solve the problem very efficiently from the view point of clarity and maintainability of the code, as well as concerning the run time.

Answer 3

[Walter Roberson]

http://matlab.wikia.com/wiki/FAQ#How_can_I_create_variables_A1.2C_A2.2C....2CA10_in_a_loop.3F

http://www.mathworks.com/matlabcentral/answers/304528-tutorial-why-variables-should-not-be-named-dynamically-eval

[John BG]

Walter

If dynamic generation of variables is such bad thing, why is Mathworks keeping command evalin, and other similar commands, in the common toolbox?

Stephen Cobeldick has such a long list of links that he promptly attaches to many answers with evalin.

Yet many people find evalin useful, and indeed it has to be handled carefully, like and edged tool.

Many evalin QAs I have checked the problem originated in the over complicated structuring of the data, not the command evalin itself.

For instance, Misha suggests evalin in this question

https://uk.mathworks.com/matlabcentral/answers/164603-suppression-failure-on-evalin-command?s_tid=srchtitle

[Jan]

@John BG: No, Misha did not suggest evalin. All he did was to show, how the output can be suppressed, and he did not take the chance to mention, that the code is not efficient. But this is not a suggestion.

There is no evidence, that "many people find evalin useful". Did you take the time to read the valuable list of links provided by Stephen?

Of course MathWorks include even inefficient commands in the toolbox. It is the responsibility of the programmer to write clean code. And it is the responsibility of forum members to teach good programming practice.

In fact, many questions concern problems in the structuring of the data, e.g. mistakes in the creation of the string. But the solution is not only to fix the string, but to suggest to avoid eval at all. As Stephen, the FAQ, Matlab's docs and many threads in this forum have explained repeatedly and exhaustively already, eval impedes the interpretation of the code by Matlab and the JIT acceleration, even if applied with a correct syntax.

I can reconsider, why an inexperienced programmer accept a suggested eval method, because he sees a small part of the problem only. For short hacks in the command windows, such solutions can look handy. But I cannot imagine, how someone, who has participated in this forum for a long time and in many corresponding threads, still insists to ignore all explanations of the problems caused by eval.

The OP has accepted your answer, and you got 0 votes yet, while the suggestions to decide for a clean programming style got 10 votes. This is a strong hint to think twice.

[Stephen Cobeldick]

@John BG: thank you for bringing that question to our attention.

That question illustrates very well the problems that evalin causes, and shows that these problems are not caused by the "inadequate structuring of the data" as some beginners believe, but are actually caused by the command itself. Lets have a look:

• buggy: well, clearly the code has a bug as the code does not do what the author wants.
• hard to debug: even though what they are trying to do something that should be trivially simple (suppress display in the command window), by using evalin they could not figure out how to achieve even this simple goal.
• obfuscated: they could not figure out how to fix the bug because the actual purpose of the code is hidden amongst a whole line of apostrophes and strings. The real purpose is hidden and the evalin is just a distraction.
• removes all code checking tools: if the user had chosen to write code without evalin then the MATLAB editor would provide a warning to put a semi-colon at the end of the line, gives advice on how to fix it, and even has an auto-fix button:

• slow: this has nothing to do with the "data structure", but is due to JIT not being able to work at all with evaluated strings. By using evalin the author made their code slower than it needs to be.
• security risk: without knowing it the author increased the risk of arbitrary code being evaluated.
• etc, etc.

So there you have it: a perfect example of what should have been trivially simple task made pointlessly complicated by using evalin. The author got totally confused trying to do something that should have been easy, could not resolve their own incredibly simple piece of code, got no helpful advice from the Editor (because code hinting and warnings do not work with evaluated strings), and had to resort to asking on an internet forum. What a waste of time!

If they had written better code (such as what Jan Simon answered) then they would have found it much easier to understand their own code, it would be more efficient (without them even having to think about it), and the editor itself would have warned them to add a semi-colon.

What a great example of how using evalin is a total waste of time! Thank you for bringing it to our attention, it illustrates the points we are making quite well.

"For instance, Misha suggests evalin in this question"

Misha does not suggest evalin anywhere in their answer: the OP was already using evalin.

[Jan]

@Stephen: Please copy this nice analysis to the thread why-variables-should-not-be-named-dynamically-eval

[Walter Roberson]

"why is Mathworks keeping command evalin, and other similar commands, in the common toolbox"

Because evalin() is required to implement "syms" and cplex, and to make it possible for various graphical tools such as the curvefitting tool or Simulink to retrieve user-defined values without the user having to pass in everything that might be needed.

Answer 4

[Jan]

Not an answer, but a comment concerning the discussion:

This is another example for an inefficient debate: The group of experienced Matlab programmers provide profound arguments, and one person insists on claiming the opposite and suggesting it to beginners. Neither code examples, nor timings, nor references in Matlab's documentation can force somebody to change his opinion. But some contributors, as me, still spend time to post the important details to warn other beginners not to get trapped by the pitfall of eval.

There is a common sense about good programming practices. Voting for good solutions helps to share this knowledge. Currently there are 9 votes for the good solution, and 0 vote and 1 acceptance for a bad solution. All readers can draw their own conclusions. The only problem is, that the accepted status has such a prominent position and shiny green check mark.

The editors can un-accept an answer, but they use this power very rarely for good reasons. The drawback for the forum would be reduced, if e.g. 4 votes (of maybe MVP members) move an answer on top of the accepted one.

It will not be possible to convince all forum members to suggest good programming practices. Discussing the same point with the same person again, will not help. What can we do instead to support the quality of the forum's contents?

[Adam]

I think constantly linking to relevant threads, including tutorial threads is still the best practice. People who want to learn good programming will see that if they search, but those who don't wish to learn and want a quick fix to their immediate problem won't. That's up to them ultimately. Someone creating dynamically named variables will repeatedly come up against problems they struggle to solve or that they manage to solve until their code becomes so buggy they don't understand how it works. Then they'll give up or come back here and ask further questions. If they still don't learn they are just a lost soul to Matlab. It happens.

Ultimately though the Accepted Answer status has to be as it is because this thread is for the person who asked the question firstly. If they feel that an answer fulfils their needs, however misguided, then that is the answer to accept. There are so many threads like this that a majority of them contain the same links to places to learn.

Of course a thread is also important for future learning, but when it is such a common subject as this one individual thread is just a drop in the ocean. Only the specific tutorial threads, FAQ, etc can be considered as global answers. If people don't search hard enough then they aren't sufficiently interested to learn.

And sometimes people learn best by taking an initially easy seeming route to solve their immediate problem, only to see how much difficulty it lands them in. Learning by failure often sticks in the memory far better than just regular learning of a good solution first time round.

It would be good though if there could be a small handful of sticky threads (or even just one with links to the tutorial threads and others like them) in the forum though. Not a load though as a mass of sticky threads is just annoying. I know there is an FAQ somewhere, but even I never have a clue where to find that after 5+ years in the forum, without resorting to a regular Google search for it.

[Jan]

@Adam: I agree. The OP Mukesh did get enough information here and he will learn it sooner or later. But especially because the thread is for the author, it can be useful to emphasize a better solution than the accepted one. Nothing is lost for the author if the order is changed by votes, because he or she knows already, which answer was accepted.

The problem of the multiple meaning of the accepted status has been discussed already: 1. solved my problem. 2. thread can be closed, 3. good solution.

Including the FAQ and/or a list of sticky threads is a really good idea. More than 50% of the forum's interface are empty space, so there is more than enough space for an impressive link. A prominent location in the header [... Ask Answer Browse More ->FAQ<- Help] would be fine.

Then it is useful already to append a comment "Better solution: see [link: FAQ]" under a bad suggestion. This seems much more efficient than these fruitless discussions.

I request, that Stephen's Tutorial is included in this list. :-)

[jiro]

I'm commenting as a user, not as a MathWorks staff (despite the little indicator by my name). It would be nice that if a thread has an answer with "significantly more" votes than the accepted answer, there is an indication on that page about it. Perhaps a hyperlinked asterisk by the accepted answer that points to that popular answer.