From: Eric on
Thanks to everybody for their help. I skipped over reading the -STRUCT sections of the help for save() since I wasn't trying to save a structure. I'll try to be more careful in the future.

In response to Matt J's question about the utility: It's possible I might use this method from several Wavefronts to save to the same MAT file. I stripped this part out of the code that I posted to try to be brief. Without changing the variable name to something meaningful, each time ToMAT(obj, filename) is called, a variable called "obj" would be appended to the MAT file, presumably overwriting the first one.

Thus
>>W1.ToMAT('c:\temp.mat')
>>W2.ToMAT('c:\temp.mat')

in my more-detailed function would allow both W1 and W2 to exist in the temp.mat file.

I definitely agree that you have to be careful using the non-functional form of load(). I do this as rarely as possible and add comments indicating what variables are being created in the workspace to help make the code more readable. I also generally only do this in script files where there's significant overhead associated with loading or processing data which I would hope to avoid in future runs.

Thanks again,
Eric
From: us on
Walter Roberson <roberson(a)hushmail.com> wrote in message <goCGn.8258$Gx2.5836(a)newsfe20.iad>...
> us wrote:
>
> > function tom(d,fnam)
> > s.(inputname(1))=d;
> > save(fnam,'s');
> > end
>
> That would create a .mat file in which the variable name was 's', rather
> than being the variable name of the object. Adding the -struct option
> does the needed conversion work.

walter

now THAT is not (necessarily) advisable (in my view)...
the OP should learn to organize his/her data in a STRUCT...
otherwise, he/she ends up with all those zillions of variables in his/her workspace...
that's why i left this option off...

urs
From: Steven Lord on

"Eric " <not(a)givingemail.com> wrote in message
news:hset02$oa1$1(a)fred.mathworks.com...
> Thanks to everybody for their help. I skipped over reading the -STRUCT
> sections of the help for save() since I wasn't trying to save a structure.
> I'll try to be more careful in the future.
>
> In response to Matt J's question about the utility: It's possible I might
> use this method from several Wavefronts to save to the same MAT file. I
> stripped this part out of the code that I posted to try to be brief.
> Without changing the variable name to something meaningful, each time
> ToMAT(obj, filename) is called, a variable called "obj" would be appended
> to the MAT file, presumably overwriting the first one.
>
> Thus
>>>W1.ToMAT('c:\temp.mat')
>>>W2.ToMAT('c:\temp.mat')
>
> in my more-detailed function would allow both W1 and W2 to exist in the
> temp.mat file.
> I definitely agree that you have to be careful using the non-functional
> form of load(). I do this as rarely as possible and add comments
> indicating what variables are being created in the workspace to help make
> the code more readable. I also generally only do this in script files
> where there's significant overhead associated with loading or processing
> data which I would hope to avoid in future runs.
>
> Thanks again,
> Eric

So what would you expect this code to write to the MAT-file?


W = cell(1, 2);
W{1} = Wavefront(5); % Assume I used the correct constructor syntax here
W{2} = Wavefront(7);
W{1}.ToMAT('c:\temp.mat')
% or if you prefer
ToMAT(W{1}, 'c:\temp.mat')


W{1} is not a valid variable name and as such calling SAVE with W{1} as the
string corresponding to the variable to save should (and does) error. Okay,
you could say, in that case I use something like GENVARNAME.

Now how about this?


ToMAT(Wavefront(5), 'c:\temp.mat')
% or even better
ToMAT(Wavefront, 'c:\temp.mat') % using the fact that this will call the
0-input constructor


Would you attempt to save this to a variable named Wavefront in the
MAT-file? Then you'd run into problems when you LOAD it, as the variable
would then shadow the constructor of the class.

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


From: Eric on
Steve brings up an interesting point. My Wavefront class does have a "Name" member, so I switched the code to use that for the variable name in the MAT file. I first use assert(isvarname(obj.Name),...) to check that the Name is a valid Matlab variable name. If it's not, an error is reported and no saving is allowed.

I believe this also addresses the ToMAT(Wavefront, 'c:\temp.mat') problem. In this case the returned empty wavefront has a name that is an empty string. This fails the isvarname() test as well. Honestly I never use the empty constructor explicitly, though, as I'm always creating a Wavefront object from data in some form.

I'm not sure what "us" means when he says I should learn how to organize my data in a STRUCT. My data is already organized in a single object. There aren't thousands of variables in my workspace, just one. I would claim that organizing my data in a user-defined class is preferable to using a STRUCT. The object-oriented functionality of Matlab is quite powerful. I'm guessing there's been some misunderstanding of what I'm doing.

Thanks to everybody once again.

-Eric