From: Maarten van Reeuwijk on
> > ... Not using eval or renaming beta are no options.
>
> I strongly, STRONGLY encourage you to reconsider your position that "Not
> using eval or renaming beta are no options". Search this newsgroup for the
> term "poofing" (think of a magician making a rabbit appear in a puff of
> smoke) to understand why this is a VERY BAD IDEA.

I understand. The data I generate for my research requires a lot of flexibility of the general routines, because each time the simulation output will differ. In order to avoid having to pass hundreds of variables to my subroutines I group everything in a structure sim.

I then use the following fragment to unpack the structure.

vnam = fieldnames(sim);
for i=1:length(vnam); eval([vnam{i},'=sim.',vnam{i}, ';']); end

I do this because calculations are generally rather complex, the code will get very cluttered if I have to prefix all the variables . However, I am open to better suggestions on how to unpack this structure in a generic way.

> a.beta = 2;
> beta = 0;
> eval('beta = a.beta;')

Thank you, that does solve the problem. beta is the only variable causing problems.

Maarten
From: Matt J on
"Maarten van Reeuwijk" <m.van.reeuwijk(a)erase.gmx.net> wrote in message <i0ieh4$7ht$1(a)fred.mathworks.com>...

> I do this because calculations are generally rather complex, the code will get very cluttered if I have to prefix all the variables . However, I am open to better suggestions on how to unpack this structure in a generic way.
==============

See the following FEX submission for a safer compromise

http://www.mathworks.com/matlabcentral/fileexchange/26216-structure-fields-to-variables
From: Steven Lord on

"Maarten van Reeuwijk" <m.van.reeuwijk(a)erase.gmx.net> wrote in message
news:i0ieh4$7ht$1(a)fred.mathworks.com...
>> > ... Not using eval or renaming beta are no options.
>>
>> I strongly, STRONGLY encourage you to reconsider your position that "Not
>> using eval or renaming beta are no options". Search this newsgroup for
>> the term "poofing" (think of a magician making a rabbit appear in a puff
>> of smoke) to understand why this is a VERY BAD IDEA.
>
> I understand. The data I generate for my research requires a lot of
> flexibility of the general routines, because each time the simulation
> output will differ. In order to avoid having to pass hundreds of variables
> to my subroutines I group everything in a structure sim.
> I then use the following fragment to unpack the structure.
> vnam = fieldnames(sim);
> for i=1:length(vnam); eval([vnam{i},'=sim.',vnam{i}, ';']); end
>
> I do this because calculations are generally rather complex, the code will
> get very cluttered if I have to prefix all the variables . However, I am
> open to better suggestions on how to unpack this structure in a generic
> way.

Are you certain you'll always need all the variables in the struct array in
your code? If not, unpack them as needed by the calculation you're about to
perform (or if you only need it once in the calculation, just refer to it
rather than creating a whole new variable.)

>> a.beta = 2;
>> beta = 0;
>> eval('beta = a.beta;')
>
> Thank you, that does solve the problem. beta is the only variable causing
> problems.

.... _that you're aware of right now_. Since you have a variable named beta,
I assume you may also have a variable named ALPHA?

http://www.mathworks.com/access/helpdesk/help/techdoc/ref/alpha.html

How about GAMMA?

http://www.mathworks.com/access/helpdesk/help/techdoc/ref/gamma.html

EVAL definitely has a negative impact on the readability of code and can
have a negative impact on the performance of code. Don't use it unless you
ABSOLUTELY have to.

--
Steve Lord
slord(a)mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ
To contact Technical Support use the Contact Us link on
http://www.mathworks.com


From: Maarten van Reeuwijk on
"Matt J " <mattjacREMOVE(a)THISieee.spam> wrote in message <i0iiij$2pu$1(a)fred.mathworks.com>...
> "Maarten van Reeuwijk" <m.van.reeuwijk(a)erase.gmx.net> wrote in message <i0ieh4$7ht$1(a)fred.mathworks.com>...
>
> > I do this because calculations are generally rather complex, the code will get very cluttered if I have to prefix all the variables . However, I am open to better suggestions on how to unpack this structure in a generic way.
> ==============
>
> See the following FEX submission for a safer compromise
>
> http://www.mathworks.com/matlabcentral/fileexchange/26216-structure-fields-to-variables

Many thanks for this excellent idea. I thought I would write the commands to a file

function unpackstruct(S, name)
str = structvars(S);
h = fopen(['unpack_', name, '.m'], 'w');
vnam = fieldnames(S);
for i=1:length(vnam);
fprintf(h, [vnam{i},'=',name,'.',vnam{i}, ';\n']);
end
fclose(h);

and then include the file in my function and execute

unpackstruct(sim, 'sim');
unpack_sim;

but this has exactly the same problems as the original method using eval.

Is there a way to include code in MATLAB, so it gets parsed when the function is parsed? I am thinking something like the 'source' command in bash.

Many thanks,

Maarten
From: Jan Simon on
Dear Maarten,

> function unpackstruct(S, name)
> str = structvars(S);
> h = fopen(['unpack_', name, '.m'], 'w');
> vnam = fieldnames(S);
> for i=1:length(vnam);
> fprintf(h, [vnam{i},'=',name,'.',vnam{i}, ';\n']);
> end
> fclose(h);
>
> and then include the file in my function and execute
>
> unpackstruct(sim, 'sim');
> unpack_sim;
>
> but this has exactly the same problems as the original method using eval.
>
> Is there a way to include code in MATLAB, so it gets parsed when the function is parsed? I am thinking something like the 'source' command in bash.

I'd really recommend not to do that. At first it is very susceptible for errors, at second it is really hard to debug, at third it is remarkably slow.

It is much faster, safer and easier to use dynamic field names instead of variables:
name = 'theName';
value = rand(10);
Variables.(name) = value.
This does not collide with any function names or other variables.
Read the FAQ concerning this topic - or read the full FAQ.

Kind regards, Jan