size of variables based on cell array of string names of the variable

Hi folks, back to the well for more cellfun fun. Or maybe dynamic field names.

I have a cell array of known work space variable names:

    mv =
      2×1 cell array
        {'llim'}
        {'ulim'}

I'd like to get the size of these variables. Against all advice, I invoked the evil EVAL functionality thusly:

        cellfun(@(x) eval(['size(' x ')']),mv,'Uni',false)

with a resulting error of: Undefined function or variable 'llim'

This of course works

    eval(['size(' mv{1} ')'])
    ans =     1     1

I'm a bit dated in matlab and ran across dynamic variable naming so attempted to approach the problem from that direction:

    wmv = struct;
    cellfun(@(x) wsv.(x) ,mv)
    error: Reference to non-existent field 'llim'.

So I'm reduced to a for loop:

    for jj = 1:length(mv)
        wsv(jj,:) = eval(['size(' mv{jj} ');']);
    end

Which is efficient enough and saves my masters money if I just go with it but it sticks in my craw, so some help making this cleaner would be appreciated.

Thanks,

-Chris

[Stephen23]

"so some help making this cleaner would be appreciated"

The cleaner (faster, simpler, easier to debug) approach would be to use one array (i.e. no dynamic variable names).

So you designed your data in such a way that you are forced to write slow, inefficient, obfuscated, complex code. And now it bugs you that your code is rather obfuscated and complex... quelle surprise!

When I designed my house I decided (against all advice) to save myself time by not bothering to build a roof. Now I have asked on some internet forums how can I keep my furniture dry, but none of the answers are very satisfactory.

[checker]

wow, that's a seriously useless response.

Answer 1

[Matt J]

You should have made all of your variables the fields of a structure to begin with. Then you could have simply used structfun, e.g.,

>> s.a=[10,20;30,40]; s.b=[30,40,50;60 70 80];
>> Sizes=structfun(@size,s,'uni',0)

Sizes = 

  struct with fields:

    a: [2 2]
    b: [2 3]

[Matt J]

To undo the damage of making separate variables, I would say that it is acceptible to use eval. When it comes to undoing the need for eval, two wrongs do make a right!

    for j = 1:length(mv)
        s.(mv{j}) = eval(['mv{j}']);
    end

[checker]

I pull the variable names from masks of various simulink blocks so my entry condition is fixed: I see no way of avoiding a cellarray containing variable names. Not sure I see an advantage of the 2nd comment over what I currently have. I'm not really interested in creating a struct, rather am looking to get the size. Thanks for posting something constructive tho!

[Matt J]

Not sure I see an advantage of the 2nd comment over what I currently have. I'm not really interested in creating a struct, rather am looking to get the size.

If these variables are things you are going to be processing downstream as a collection, you can hopefully see now that maintaining them as a struct makes this much easier: in that form you can readily loop over them using dynamic field naming or use the many struct methods provided by MathWorks expressly for doing this kind off multi-variable manipulation.

I'd be surprised if Simulink doesn't offer you a way of importing things back in the the Matlab workspace in struct form, but I am not familiar enough with Simulink to say how you would do it.