Prev: Hydraulic Pump transfer function.
Next: using rough sets for noise filtering
From: Matt J on 13 Jan 2010 09:22
"Susan " <foowidget(a)gmail.com> wrote in message <hij2uv$jj0$1(a)fred.mathworks.com>...
> > OMG not only does that sample code result in an error message, but it permanently throws my display() function out of whack. Notice below that the data is displayed to the screen without the usual line-skipping. Only by restarting MATLAB was I able to fix this.
> >
> > >> a=1
> > a =
> > 1
> > >>
>
> That was because of the "format compact" statement. "format loose" will fix it.
>
> You like the line skipping?

Ah. OK. false alarm.
From: Steven Lord on 13 Jan 2010 10:13

"Susan " <foowidget(a)gmail.com> wrote in message
news:hiivnr$og7$1(a)fred.mathworks.com...
> "Matt Fig" <spamanon(a)yahoo.com> wrote in message
> <hiiqu4$k7e$1(a)fred.mathworks.com>...
>> Can you give a realistic example of what you are trying to accomplish by
>> this syntax?
>
> Well, here's the most recent scenario, but not the only one:
>
> -----
> Base workspace - holds a set of variables to be operated on. Due to
> historical considerations, the variables might have different names. For
> example
> var1 might be called A1, A2, or A3
> var2 might be called B1, B2, or B3
> etcetera
>
> These data names are outside my control.
> -----
> Processing function "procFun" is to operate on variables in the base
> workspace.

I think this is extremely bad programming practice, but if you MUST do this,
note that EVALIN can accept one of two different inputs as the specification
of the workspace in which to evaluate the command (the ws input.)

> I want procFun to call a function that assigns them to local variable
> names. So by
> calling assignVars, the following would be achieved in the procFun
> workspace.

So you're both fiddling with the base workspace AND "poofing" variables into
the workspace of procFun? That's going to be VERY tricky to debug when (not
if) something goes wrong.

I strongly recommend rethinking this approach -- it's GOING to cause you
pain. Use Bruno's suggestion and pass variables into procFun as input
arguments. Then you KNOW what their names are inside procFun, and don't
need to worry about the names of the variables in the base workspace
conflicting with local variables you use inside procFun, or juggling three
different workspaces at once.

If you MUST do this (as in someone has a gun to your head, or you will be
fired if you don't solve the problem this particular way) you can use EVALIN
and ASSIGNIN in combination.

--
Steve Lord
slord(a)mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ


From: Foo on 13 Jan 2010 14:32
Grant that I'm stuck with multiply-named variables in the base
workspace, as described
before. It seems like I'm stuck with some messiness somewhere in my
code. Two options
are discussed below.

> So you're both fiddling with the base workspace AND "poofing" variables into
> the workspace of procFun?  That's going to be VERY tricky to debug when (not
> if) something goes wrong.

> If you MUST do this (as in someone has a gun to your head, or you will be
> fired if you don't solve the problem this particular way) you can use EVALIN
> and ASSIGNIN in combination.

The function assignVars would read variables from two levels up and
assign variables
one level up. That doesn't really seem so messy given that it's a
private subfunction of
procFun. Seriously, is it more awful than the alternate solution
discussed below?

> I strongly recommend rethinking this approach -- it's GOING to cause you
> pain.  Use Bruno's suggestion and pass variables into procFun as input
> arguments.  Then you KNOW what their names are inside procFun, and don't
> need to worry about the names of the variables in the base workspace
> conflicting with local variables you use inside procFun, or juggling three
> different workspaces at once.

To implement Bruno's suggestion, I could run a script (not a function)
from the
base workspace that figures out what variables to pass to procFun.
Potentially, a
variable in the script could overwrite a data variable with the same
name.

So the tradeoff as I see it is:

assignin/evalin - PROs - no chance of overwriting data. Variable-
sorting code is
neatly hidden away in a subroutine. CON - uses programming practice
that is not
recommended

script at base workspace - PRO - avoids assignin/evalin. Variable-
sorting code is
hidden in script. CON - possible overwriting of data in base
workspace

Is there a third option that stays inside the operating conditions?
That is, that
data is going to be loaded into the base workspace, and my processing
code must
be launched from a single simple command typed into the command line.
From: Matt J on 13 Jan 2010 15:55
Foo <foowidget(a)gmail.com> wrote in message <624af29d-ddbc-401f-b434-873fab612989(a)k17g2000yqh.googlegroups.com>...

> Is there a third option that stays inside the operating conditions?
> That is, that
> data is going to be loaded into the base workspace, and my processing
> code must
> be launched from a single simple command typed into the command line.

You haven't described why you're stuck with a multitude of possible variable names, but I'm guessing it's because you've got a bunch of .mat files from a 3rd part and are stuck with the variable names as stored by the 3rd party in the files. You are trying to write code that maps these variable names into a consistent set of names that you can use.

If I'm right, what you should really be doing is exploiting the fact that load() can return a struct, in which the loaded variable names are the fields of the struct. You can then pass this struct to a function and use whatever renaming rules you've been using to rename all the fieldnames,e.g.


S=load(FileName);

function Snew=RenameVariables(S)

f=fieldnames(S); %current variable names

fnew=regexprep(f,'\d',''); %get rid of digits in the variable names


for ii=1:length(f)
Snew.(f{ii})=S.(f{ii});
end


end



If you want to unpack the output of Snew into separate variables in your workspace you could use my structvars() FEX tool

http://www.mathworks.com/matlabcentral/fileexchange/26216-structure-fields-to-variables

in conjunction with eval().

However, you're probably better off just keeping all the variables in a struct anyway. It will make it easier to subsequently pass them to functions packed in a single object.
From: Matt J on 13 Jan 2010 16:17
"Matt J " <mattjacREMOVE(a)THISieee.spam> wrote in message <hilbv9$kf3$1(a)fred.mathworks.com>...

> Snew.(f{ii})=S.(f{ii});

Should be

Snew.(fnew{ii})=S.(f{ii});

obviously
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Hydraulic Pump transfer function.
Next: using rough sets for noise filtering