"renamevars" doesn't return output

I tried renaming a table variable, first without assigning the new table to a destination, then assigning to a destination:

>> x=[1;2;3]; y=[5;6;7]; z=table(x,y) % Create test table
z = 3×2 table
    x    y
    _    _
    1    5
    2    6
    3    7

>> renamevars(z,"x","xx") % Rename without assigning
Error using tabular/renamevars Using RENAMEVARS
without assigning to a workspace variable does not
modify the table's variable names.  Use t =
renamevars(t,vars,newnames).

>> a=renamevars(z,"x","xx") % Rename with assigning
a = 3×2 table
    xx    y
    __    _
    1     5
    2     6
    3     7

Without assigning to a destination, "renamevars" actually errors out rather than issue a warning. I've always been able to view the result of an operation before assigning to a destination. To not support this seems extremely un-MATLAB-ish (and unlike most languages I've used) This is especially important when debugging in MATLAB, as one should not create objects that aren't already present in the code.

[Jan]

I agree. What is your question?

[FM]

Is there a way to mimic MATLAB-ish behaviour to work around this limitation? In debugging mode, the options are limited. Even outside of debugging mode, you end up creating throw-away objects that cognitively pollute the workspace.

[Steven Lord]

Suppose that your no-output call ran without throwing an error. You display z afterwards, potentially dozens or hundreds of lines of code later. Are you surprised that z still has a variable named x and does not have a variable named xx?

IIRC our belief was that users would be surprised by that behavior, that they might expect renamevars to "reach into its caller's workspace" and modify the variable in that workspace (or may similarly think that table arrays have handle behavior.) That error was our attempt to forestall that user surprise/confusion.

[FM]

There are many table column manipulation commands that don't behave like this. Bringing "removevars" in line would make it consistent with the majority of these kinds of commands. Maybe in later releases? The user can still be forewarned via a warning.

[Eric Sofen]

Thanks for bringing this up. The renamevars behavior is consistent with categorical renamecats, but I agree it is inconsistent with other table behavior. I have an enhancement request to revise the renamevars behavior.

c = categorical(["a" "b" "c"])

c = 1×3 categorical array
     a      b      c 

renamecats(c,"a","z")

Error using categorical/renamecats
Using RENAMECATS without assigning to a workspace variable does not modify the array's properties. Use C = RENAMECATS(C,OLDNAMES,NEWNAMES).

[FM]

Thanks, Eric.

Answer 1

[Jan]

If you want to change this behavior, login with admin privileges and modify the file renamevars.m. You find the check of nargout==0 on top.

As usual for modifying built-in functions: Strange side-effects might occur. Be careful and document the changes exhaustively. Remember that the changes might vanish during an update.

What about asking the MathWorks team for an explanation? Maybe this was a mistake only or there are some good reasons to avoid assigning ans utomatically.

Writing renamevars(z,"x","xx") instead of a=renamevars(z,"x","xx") saves 2 keystrokes. Is this useful?

[FM]

I'm not interested in saving keystrokes. I'll leave the hacking of commands to TMW. I mean, a safer option is to write a wrapper function around "renamevars".

You suggested asking the Mathworks team why it was designed this way. My technical support seems to come and go. Would the MathWorks team see the question here?

[Jan]

The MathWorks team does not scan the contents of the public forum. Writing a bug report or enhancement request is much better, because then the the information is forwarded directly to the support team.

A wrapper is an efficient idea also:

function Reply = myren(varargin)
Reply = renamevars(varargin{:});
end

[FM]

Yes, that means that your code is portable so long as you share your wrapper as well (but probably easier than convincing a receiving party to modify renamevars.m).

Steven Lord's response to this question must have been happenstance. I'm appreciative that TMW staff sometimes take the time to respond here.