Date: Nov 9, 2012 10:10 AM
Author: Steven Lord
Subject: Re: trouble saving data structure to a file
"Ben Ruppel" <firstname.lastname@example.org> wrote in message
> "Steven_Lord" <email@example.com> wrote in message
> Hi Steve,
> Thank you for the information and the useful links. While I accept it as
> the truth, I still think it's a little odd and inconsistent that some
> functions aren't smart enough to figure out when an expression points to a
For this particular syntax, SAVE probably could handle the expression (since
you used the '-struct' flag) and generate variables with reasonable names in
But what should the variable in the MAT-file generated by this call be
Okay, SIN is a function and that expression is more complicated than your
simple attempt to index into handles with the dot-notation. Fair enough.
Let's take another indexing example, though. What should the name of the
variable in the MAT-file created by this SAVE call be?
A = magic(10);
save('myfile.mat', 'A(2:3, 5:7)')
Calling it A would be misleading. I suppose we could pass that expression
through GENVARNAME but the generated variable name is kind of long and
that's a fairly simple example.
> After all, if I were to create my own function, I could pass in a variable
> name or a data structure member reference / expression and the function
> would see both as the data that is being referenced. Oh well.
There's a difference between the _data_ in a variable or returned by an
expression and the _name_ of a variable. SAVE does not accept the _data_ as
input, it accepts the _name_. Two other functions that accept names not data
are EXIST and WHOS. They have similar behavior to SAVE.
A = magic(10);
exist('A(5, 5)', 'var') % returns false even though A has an element (5, 5)
whos('A(5, 5)') % Does not display anything
On the other hand, functions like SIN accept the _data_, and they're
perfectly happy to accept the result of an expression.
sin(A(5, 5)) % sin(9)
To contact Technical Support use the Contact Us link on