"Ben Ruppel" <email@example.com> wrote in message news:firstname.lastname@example.org... > "Steven_Lord" <email@example.com> wrote in message > <firstname.lastname@example.org>...
> 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 > variable.
For this particular syntax, SAVE probably could handle the expression (since you used the '-struct' flag) and generate variables with reasonable names in the MAT-file.
But what should the variable in the MAT-file generated by this call be named?
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.