Passing who function output as input

3 views (last 30 days)
Rodolfo Villanueva
Rodolfo Villanueva on 18 Jan 2019
Answered: Jan on 18 Jan 2019
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
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.
Rodolfo Villanueva
Rodolfo Villanueva on 18 Jan 2019
I understand this issue, and I have addressed it to a certain extent.
The platform I'm designing in Simulink has a dynamic number of signals, with names which I will not know about. I already have a nice routine that dynamically gets the final signal simulation data and makes it tidy:
for i = 1:logsout.numElements
locSig = logsout.getElement(i)
Data = transpose(locSig.Values.Data)
StreamSummary = addvars(StreamSummary,Data,'NewVariableNames',locSig.Name)
end
But now this data needs to be processed, and since I do not know the name of the variables inserted by users, I need to create routines which can deal with this. This is key, since there could be 5 signals or 150 signals, and all I can do is make sure the names of them follow a pattern that I can use to search.
Right now I am attempting to search for variables which have a certain pattern in their name (such as starting with a certain phrase), and then process it. It is from this issue that the who function is pretty useful. I just need to be able to process the results of it.
Any input on this is welcomed!

Sign in to comment.

Answers (1)

Jan
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.

Products

Community Treasure Hunt

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

Start Hunting!