Thread Subject: how to rename a workspace variable in a loop?

Hi,

I was wondering how you could rename a workspace variable in a loop? What I have is a loop that generates results which are stored in a matrix. the problem is that in the 2nd loop the matrix is overwritten. I also cannot add both matrices, because they are not of the same size.

Therefore i wanted to know how to rename the workspace variable for each loop generation. for example when using a "for" loop with i=1:1:5 how can I name the matrix M for each loop with a increment, thus M1, M2, M3, etc... so that I can analyze all the data and not that of only the last loop.

any suggestions are appreciated.

thank you

Use the EVAL function

Type:

   doc eval

at the command prompt.


For example:

  for i = 1:5

     ...
     ...

     eval([ 'M' num2str(k) ' = M;' ]);

     ...
     ...

  end




"Nizar " <pakoeli@hotmail.com> wrote in message
news:f7olca$1mj$1@fred.mathworks.com...
> Hi,
>
> I was wondering how you could rename a workspace variable in a loop? What
> I have is a loop that generates results which are stored in a matrix. the
> problem is that in the 2nd loop the matrix is overwritten. I also cannot
> add both matrices, because they are not of the same size.
>
> Therefore i wanted to know how to rename the workspace variable for each
> loop generation. for example when using a "for" loop with i=1:1:5 how can
> I name the matrix M for each loop with a increment, thus M1, M2, M3,
> etc... so that I can analyze all the data and not that of only the last
> loop.
>
> any suggestions are appreciated.
>
> thank you

Sorry, make that:

    eval([ 'M' num2str(i) ' = M;' ]);




"Rick Rosson" <rrosson@mathworks.com> wrote in message
news:f7oloa$75a$1@fred.mathworks.com...
> Use the EVAL function
>
> Type:
>
> doc eval
>
> at the command prompt.
>
>
> For example:
>
> for i = 1:5
>
> ...
> ...
>
> eval([ 'M' num2str(k) ' = M;' ]);
>
> ...
> ...
>
> end
>
>
>
>
> "Nizar " <pakoeli@hotmail.com> wrote in message
> news:f7olca$1mj$1@fred.mathworks.com...
>> Hi,
>>
>> I was wondering how you could rename a workspace variable in a loop? What
>> I have is a loop that generates results which are stored in a matrix. the
>> problem is that in the 2nd loop the matrix is overwritten. I also cannot
>> add both matrices, because they are not of the same size.
>>
>> Therefore i wanted to know how to rename the workspace variable for each
>> loop generation. for example when using a "for" loop with i=1:1:5 how can
>> I name the matrix M for each loop with a increment, thus M1, M2, M3,
>> etc... so that I can analyze all the data and not that of only the last
>> loop.
>>
>> any suggestions are appreciated.
>>
>> thank you
>
>

"Nizar " <pakoeli@hotmail.com> wrote in message <f7olca$1mj$1@fred.mathworks.com>...
> Hi,
>
> I was wondering how you could rename a workspace variable in a loop? What I have is a loop that generates results which are stored in a matrix. the problem is that in the 2nd loop the matrix is overwritten. I also cannot add both matrices, because they are not of the same size.
>
> Therefore i wanted to know how to rename the workspace variable for each loop generation. for example when using a "for" loop with i=1:1:5 how can I name the matrix M for each loop with a increment, thus M1, M2, M3, etc... so that I can analyze all the data and not that of only the last loop.

Don't. See question 4.6 in the newsgroup FAQ for some of the reasons you shouldn't do this and alternatives to doing this.

http://matlabwiki.mathworks.com/MATLAB_FAQ

--
Steve Lord
slord@mathworks.com

> Don't. See question 4.6 in the newsgroup FAQ for some of the reasons you shouldn't do this and alternatives to doing this.
>
> http://matlabwiki.mathworks.com/MATLAB_FAQ

Since there's been some chatter about this topic on several threads, I thought I'd throw in a case where I think there is no recourse but to make dynamically named variables.

I''m in a situation where it would be really great to be able to save a large array X to a .mat file but later to load back only pieces of X into the workspace. Imagine for instance that X is a large 3D image and later you want to load in one slice at a time for some sort of slice-wise processing.

Unfortunately, load() doesn't let you do this. So, the only alternative I can come up with is to save each slice of X to the .mat file as an individual variable, dynamically created using eval().

On Dec 16, 6:05=A0pm, "Matt" <mjacobson.removet...@xorantech.com> wrote:
> > Don't. =A0See question 4.6 in the newsgroup FAQ for some of the reasons=
 you shouldn't do this and alternatives to doing this.
>
> >http://matlabwiki.mathworks.com/MATLAB_FAQ
>
> Since there's been some chatter about this topic on several threads, I th=
ought I'd throw in a case where I think there is no recourse but to make dy=
namically named variables.
>
> I''m in a situation where it would be really great to be able to save a l=
arge array X to a .mat file but later to load back only pieces of X into th=
e workspace. Imagine for instance that X is a large 3D image and later you =
want to load in one slice at a time for some sort of slice-wise processing.
>
> Unfortunately, load() doesn't let you do this. So, the only alternative I=
 can come up with is to save each slice of X to the .mat file as an individ=
ual variable, dynamically created using eval().

Alternatively, you could dynamically create file names. Something
file_0001.tif, file_0002.tif, ... and save the images with 'imwrite'
as uncompressed 16-bit tiff. Then you read them as needed for 2D
processesing.

HTH

Jomar

Jomar Bueyes <jomarbueyes@hotmail.com> wrote in message <3223d164-db24-4ffd-ac94-b5b0ed67a57a@d42g2000prb.googlegroups.com>...
> On Dec 16, 6:05=A0pm, "Matt" <mjacobson.removet...@xorantech.com> wrote:
> > > Don't. =A0See question 4.6 in the newsgroup FAQ for some of the reasons=
> you shouldn't do this and alternatives to doing this.
> >
> > >http://matlabwiki.mathworks.com/MATLAB_FAQ
> >
> > Since there's been some chatter about this topic on several threads, I th=
> ought I'd throw in a case where I think there is no recourse but to make dy=
> namically named variables.
> >
> > I''m in a situation where it would be really great to be able to save a l=
> arge array X to a .mat file but later to load back only pieces of X into th=
> e workspace. Imagine for instance that X is a large 3D image and later you =
> want to load in one slice at a time for some sort of slice-wise processing.
> >
> > Unfortunately, load() doesn't let you do this. So, the only alternative I=
> can come up with is to save each slice of X to the .mat file as an individ=
> ual variable, dynamically created using eval().
>
> Alternatively, you could dynamically create file names. Something
> file_0001.tif, file_0002.tif, ... and save the images with 'imwrite'
> as uncompressed 16-bit tiff. Then you read them as needed for 2D
> processesing.
>
> HTH

That's not really what I'd prefer. For one thing, I think you want to have all the slices in the same file so that it's easier to transport around (okay, you could use .zip...)

Also, I'd really like it to be a .mat file so that I can pile in other related variables, like a structure variable that could act as a header...

Matt wrote:
 
> I''m in a situation where it would be really great to be able to save a large array X to a .mat
> file but later to load back only pieces of X into the workspace. Imagine for instance that X
> is a large 3D image and later you want to load in one slice at a time for some sort of
> slice-wise processing.

> Unfortunately, load() doesn't let you do this. So, the only alternative I can come up with
> is to save each slice of X to the .mat file as an individual variable, dynamically
> created using eval().

Nope.

S = cell2struct(mat2cell(X,size(X,1),size(X,2),ones(1,size(X,3))),num2str((1:size(X,3)).','slice%d'),3);
save(OutputFileName,'S', '-struct');

Or use dynamic field names in building up S and then use the save -struct approach.

--
.signature note: I am now avoiding replying to unclear or ambiguous postings.
Please review questions before posting them. Be specific. Use examples of what you mean,
of what you don't mean. Specify boundary conditions, and data classes and value
relationships -- what if we scrambled your data or used -Inf, NaN, or complex(rand,rand)?

Walter Roberson <roberson@hushmail.com> wrote in message <WlX1l.5935$%z5.391@newsfe09.iad>...
> Matt wrote:
>
> > I''m in a situation where it would be really great to be able to save a large array X to a .mat
> > file but later to load back only pieces of X into the workspace. Imagine for instance that X
> > is a large 3D image and later you want to load in one slice at a time for some sort of
> > slice-wise processing.
>
> > Unfortunately, load() doesn't let you do this. So, the only alternative I can come up with
> > is to save each slice of X to the .mat file as an individual variable, dynamically
> > created using eval().
>
> Nope.
>
> S = cell2struct(mat2cell(X,size(X,1),size(X,2),ones(1,size(X,3))),num2str((1:size(X,3)).','slice%d'),3);
> save(OutputFileName,'S', '-struct');
>
> Or use dynamic field names in building up S and then use the save -struct approach.

Well, okay. If you're point was that you don't need to use eval(), then yes.

My point was more that this is an application requiring that arrays be assigned to dynamically named variables. The use of arrays, as encouraged by the FAQ, is not enough
here.

Matt wrote:
> Walter Roberson <roberson@hushmail.com> wrote in message <WlX1l.5935$%z5.391@newsfe09.iad>...

>> S = cell2struct(mat2cell(X,size(X,1),size(X,2),ones(1,size(X,3))),num2str((1:size(X,3)).','slice%d'),3);
>> save(OutputFileName,'S', '-struct');

> Well, okay. If you're point was that you don't need to use eval(), then yes.
 
> My point was more that this is an application requiring that arrays be assigned to
> dynamically named variables.

The application only really required dynamically named -fields-. And using dynamically
named -fields- is one of the recommended ways to avoid eval().

> The use of arrays, as encouraged by the FAQ, is not enough here.

The FAQ is only as good as its contributors make it. The Matlab Central team welcomes
enhancements.

--
.signature note: I am now avoiding replying to unclear or ambiguous postings.
Please review questions before posting them. Be specific. Use examples of what you mean,
of what you don't mean. Specify boundary conditions, and data classes and value
relationships -- what if we scrambled your data or used -Inf, NaN, or complex(rand,rand)?

"Matt" <mjacobson.removethis@xorantech.com> wrote in message
news:gib8ib$p3p$1@fred.mathworks.com...
> Walter Roberson <roberson@hushmail.com> wrote in message
> <WlX1l.5935$%z5.391@newsfe09.iad>...
>> Matt wrote:
>>
>> > I''m in a situation where it would be really great to be able to save a
>> > large array X to a .mat
>> > file but later to load back only pieces of X into the workspace.
>> > Imagine for instance that X
>> > is a large 3D image and later you want to load in one slice at a time
>> > for some sort of
>> > slice-wise processing.
>>
>> > Unfortunately, load() doesn't let you do this. So, the only alternative
>> > I can come up with
>> > is to save each slice of X to the .mat file as an individual variable,
>> > dynamically
>> > created using eval().
>>
>> Nope.
>>
>> S =
>> cell2struct(mat2cell(X,size(X,1),size(X,2),ones(1,size(X,3))),num2str((1:size(X,3)).','slice%d'),3);
>> save(OutputFileName,'S', '-struct');
>>
>> Or use dynamic field names in building up S and then use the save -struct
>> approach.
>
> Well, okay. If you're point was that you don't need to use eval(), then
> yes.

If you don't like Walter's two-liner, try:


for k = 1:size(X, 3)
    S.(sprintf('slice%d', k)) = X(:, :, k);
end
save(OutputFileName,'S', '-struct');


Yes, it has a FOR loop. Unless your X has a lot of pages, though, the FOR
loop won't have to execute for very long. And IMO it's more easily read
than Walter's two-liner.

> My point was more that this is an application requiring that arrays be
> assigned to dynamically named variables. The use of arrays, as encouraged
> by the FAQ, is not enough
> here.

The use of an array is insufficient in this case. The use of a combination
of dynamic field names and the -struct flag for SAVE is sufficient to
accomplish the goal as you stated: "later you want to load in one slice at
a time for some sort of slice-wise processing."

--
Steve Lord
slord@mathworks.com

> for k = 1:size(X, 3)
> S.(sprintf('slice%d', k)) = X(:, :, k);
> end
> save(OutputFileName,'S', '-struct');
>
>
> Unless your X has a lot of pages, though, the FOR
> loop won't have to execute for very long. And IMO it's more easily read
> than Walter's two-liner.

It has about 600 pages, but it doesn't matter. The actual execution of the save() command will clearly be the bottleneck here, regardless of the number of pages.


> The use of an array is insufficient in this case. The use of a combination
> of dynamic field names and the -struct flag for SAVE is sufficient to
> accomplish the goal as you stated: "later you want to load in one slice at
> a time for some sort of slice-wise processing."

I don't draw much of a distinction between dynamic field names and dynamic variable names. They're about the same in their internal implementation anyway, no?

On Dec 18, 7:10=A0am, "Matt" <mjacobson.removet...@xorantech.com> wrote:
> > for k =3D 1:size(X, 3)
> > =A0 =A0 S.(sprintf('slice%d', k)) =3D X(:, :, k);
> > end
> > save(OutputFileName,'S', '-struct');
>
> > Unless your X has a lot of pages, though, the FOR
> > loop won't have to execute for very long. =A0And IMO it's more easily r=
ead
> > than Walter's two-liner.
>
> It has about 600 pages, but it doesn't matter. The actual execution of th=
e save() command will clearly be the bottleneck here, regardless of the num=
ber of pages.
>
> > The use of an array is insufficient in this case. =A0The use of a combi=
nation
> > of dynamic field names and the -struct flag for SAVE is sufficient to
> > accomplish the goal as you stated: =A0"later you want to load in one sl=
ice at
> > a time for some sort of slice-wise processing."
>
> I don't draw much of a distinction between dynamic field names and dynami=
c variable names. They're about the same in their internal implementation a=
nyway, no?

Seems to me that a .mat file is not appropriate here.
You need a database that allows random access.
I'd use netCDF for such a task, with the page no. having zero
dimension (meaning it can be expanded indefinitely).

In article <gibfac$j94$1@fred.mathworks.com>,
mjacobson.removethis@xorantech.com says...
>
> I don't draw much of a distinction between dynamic field names and dynamic variable names.
> They're about the same in their internal implementation anyway, no?
>
>

They are VERY different in terms of their implications for MATLAB to be
able to parse and reliably execute the code. And the internals are
different as a result - at least in terms of recognizing what's a
variable.


--
Loren
http://blogs.mathworks.com/loren

On 17 Des, 00:05, "Matt" <mjacobson.removet...@xorantech.com> wrote:
> > Don't. =A0See question 4.6 in the newsgroup FAQ for some of the reasons=
 you shouldn't do this and alternatives to doing this.
>
> >http://matlabwiki.mathworks.com/MATLAB_FAQ
>
> Since there's been some chatter about this topic on several threads, I th=
ought I'd throw in a case where I think there is no recourse but to make dy=
namically named variables.
>
> I''m in a situation where it would be really great to be able to save a l=
arge array X to a .mat file but later to load back only pieces of X into th=
e workspace. Imagine for instance that X is a large 3D image and later you =
want to load in one slice at a time for some sort of slice-wise processing.
>
> Unfortunately, load() doesn't let you do this. So, the only alternative I=
 can come up with is to save each slice of X to the .mat file as an individ=
ual variable, dynamically created using eval().

You may be right about LOAD, but that doesn't mean that EVAL is
necessary; only that LOAD (or rather, the .mat interface) might
be flawed. I remember seeing some threads here a few months
ago where LOAD was modified to read specified variables from
a .mat file. Somebeody else requested the functionality you ask
for, so if you submit a product enhancement request to TMW
you might get this functionality in a later version of matlab.

In the mean time, you can easily avoid the problem by using some
other file format than .mat. The naive way would be to use a
binary format where the first entries are the (n,m,p) dimensions
of the image stored on some specified integer format, and then
the data stored on the relevant format as p consecutive (n,m)
frames. With this type of data format it would be no big deal
to read only parts of a larger image.

Such formats might already exist, for all I know. If so,
it would be a matter of obtaining the documentation for
the format (which might not be quite as easy as it sounds)
and implement an I/O interface.

Rune

> In the mean time, you can easily avoid the problem by using some
> other file format than .mat. The naive way would be to use a
> binary format where the first entries are the (n,m,p) dimensions
> of the image stored on some specified integer format, and then
> the data stored on the relevant format as p consecutive (n,m)
> frames. With this type of data format it would be no big deal
> to read only parts of a larger image.

Yes, it's clear that you could do that, but my aim here is to have the advantages of .mat capabilities. If I have the data in a .mat file , I can throw in additional related variables, like a structure variable H to contain header info. I also wouldn't have to keep track manually of the byte-sizes of these objects as I save/load/overwrite them.

On 17 Des, 21:04, "Matt" <mjacobson.removet...@xorantech.com> wrote:
> > In the mean time, you can easily avoid the problem by using some
> > other file format than .mat. The naive way would be to use a
> > binary format where the first entries are the (n,m,p) dimensions
> > of the image stored on some specified integer format, and then
> > the data stored on the relevant format as p consecutive (n,m)
> > frames. With this type of data format it would be no big deal
> > to read only parts of a larger image.
>
> Yes, it's clear that you could do that, but my aim here is to have the advantages of .mat capabilities.

Again, such questions concern the file format and their
interfaces. Any one format may or may not serve any
particular purpose. It is the system designer's responsibilty
to choose the correct file format for a given purpose.

> If I have the data in a .mat file , I can throw in additional related variables, like a structure variable H to contain header info. I also wouldn't have to keep track manually of the byte-sizes of these objects as I save/load/overwrite them.

You don't do this *manually* with the .mat format, but all
these things are taken care of under the hood. I don't know
exactly how things are done with .mat, but given the
flexibility of the format, it is likely that the data
either

1) have type information stored along with the contents
2) are stored on large, generic forms

or both. All of which cost space, which might be a major
issue both what disk space and RAM are concerned.

A well-designed format for the special purpose would
provide exactly what you need: A header section where
you store meta data about the contents, clearly partitioned
data on well-defined formats. And it would have a very
clear and unambiguous specification.

Check out the specs for the SEG-Y format for seismic data:

http://en.wikipedia.org/wiki/SEG_Y

particularly the references. While not perfect, this format
lets the user conveniently access protions of a large data set.

Back to where this thread started: There is nothing here
to support a claim that the function EVAL is necessary.
If you find you need EVAL you either use the wrong file
format, or the interface of the format you use is not
suitable for the purpose.

Rune

Loren Shure <loren@mathworks.com> wrote in message <MPG.23b3222320d5836698990a@news.mathworks.com>...
> In article <gibfac$j94$1@fred.mathworks.com>,
> mjacobson.removethis@xorantech.com says...
> >
> > I don't draw much of a distinction between dynamic field names and dynamic variable names.
> > They're about the same in their internal implementation anyway, no?
> >
> >
>
> They are VERY different in terms of their implications for MATLAB to be
> able to parse and reliably execute the code. And the internals are
> different as a result - at least in terms of recognizing what's a
> variable.

Yes. true.

> Again, such questions concern the file format and their
> interfaces. Any one format may or may not serve any
> particular purpose. It is the system designer's responsibilty
> to choose the correct file format for a given purpose.

True, but for the purpose of this discussion 'correct'='easy'. I'm looking for an easy, flexible, and readily available way to store a large array and related variables, and which would allow me to access smaller chunks of the array later. (In other words, I'd rather not have to go and implement my own format...)

The .mat interface would give me all of that, but for the limitations already mentioned.
 

> > If I have the data in a .mat file , I can throw in additional related variables, like a structure variable H to contain header info. I also wouldn't have to keep track manually of the byte-sizes of these objects as I save/load/overwrite them.
>
> You don't do this *manually* with the .mat format,

You misread. I said that you have do it manually with other formats.


> Back to where this thread started: There is nothing here
> to support a claim that the function EVAL is necessary.
> If you find you need EVAL you either use the wrong file
> format, or the interface of the format you use is not
> suitable for the purpose.

That is where the discussion started, but the point was already conceded a few posts back with Walter.

NZTideMan <mulgor@gmail.com> wrote in message <61c8fc70-2c72-47bc-88f0-2a559d0059a5@i20g2000prf.googlegroups.com>...

> Seems to me that a .mat file is not appropriate here.
> You need a database that allows random access.
> I'd use netCDF for such a task, with the page no. having zero
> dimension (meaning it can be expanded indefinitely).

That might be. I'm not conversant with netcdf and the material in
"doc netCDF" is not very transparent to me. In particular, there are no examples of exporting MATLAB variables to netcdf if that indeed, is what it allows you to do.

On Dec 18, 10:10=A0am, "Matt" <mjacobson.removet...@xorantech.com>
wrote:
> NZTideMan <mul...@gmail.com> wrote in message <61c8fc70-2c72-47bc-88f0-2a=
559d005...@i20g2000prf.googlegroups.com>...
> > Seems to me that a .mat file is not appropriate here.
> > You need a database that allows random access.
> > I'd use netCDF for such a task, with the page no. having zero
> > dimension (meaning it can be expanded indefinitely).
>
> That might be. I'm not conversant with netcdf and the material in
> "doc netCDF" is not very transparent to me. In particular, there are no e=
xamples of exporting MATLAB variables to netcdf if that indeed, is what it =
allows you to do.

You didn't look deep enough.
It's all here:
http://mexcdf.sourceforge.net/