Passing who function output as input
3 views (last 30 days)
Show older comments
I wish to be able to run a who search, to find a list of variables, and then create a cell array or table with the values of these variables.
The problem with passing the who function is that it only adds the names of the variables, not the variables themselves
table(who('A*'))
This creates a table with a list of variable names, instead of the actual variables.
Any help would be greatly appreciated!
3 Comments
Stephen23
on 18 Jan 2019
Edited: Stephen23
on 18 Jan 2019
"Any help would be greatly appreciated!"
Read this very carefully:
And then design your data better, which will in turn allow you to write better code. Usually indexing is the key, or perhaps the fieldnames of a structures, or variables of a table... there are plenty of better (neater, more efficient, less obfuscated, less buggy, easier to debug) ways to access data.
Answers (1)
Jan
on 18 Jan 2019
As mentioned already, this approach is extremely prone to bugs and unexpected behavior. As soon as someone calls a variable "table" or "who", the posted code will fail with strange error messages. I'm convinced, that the who approach means drilling a hole in your knee.
Unfortunately I do not work with Simulink and cannot suggest a better solution. Is it possible to export the data as fields of a struct? Or why not creating the table directly in Simulink? Two cell arrays would be smart also: One with the data and the other with the names.
What ever you do, avoid accessing variables dynamically. If you program is useful, others will use it also. Then any dynamical search for variables in the workspace can and will collide with other software. The new users will be extremely surprised and frustrated, because it is a mess to fix your software such that it does not interfere with other codes or any existing variables in the workspace. A fundamental idea or reliable software is to reduce the interaction with unrelated other software. An automatic import of some variables matching a specific name pattern can work under some circumstances, but if it fails, it can destroy work seriously and massively.
If your code is just a little hack and it will not be used for productive work - so it is a simple fun project -, tricks like the dynamic access of the BaseWorkspace cannot do a lot of harm. But even then I recommend to use clean programming techniques only, because it helps to be firm with a good programming style.
Although it was mentioned already, I recommend again to read and follow: How and why to avoid dynamic access of variables . Scientific work is not compatible with a "bird box" programming style.
Note: If you assume, that my answer is emotional - yes, it is. I've seen too many "working" code which suffered from eval, global variables and hardcoded dependency to GUI elements:
x = get(FigH, 'Children')
result = str2num(get(x(17), 'String')) + eval(get(x(31), 'String'))
Brrrrr. As soon as the GUI is modified or as a new Matlab version stores the children in another order, the code fails and is impossible to maintain.
Sorry that this is not a direct solution to your question. But as a brave programmer I recommend to modify the problem instead of solving it in a fragile way which is known to cause more troubles soon.
0 Comments
See Also
Categories
Find more on Whos in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!