Comma-separated assignment to a table variable

The code below tests assignment by comma-separated expansion to a cell array in 3 different scenarios. In the specific case when the cell array X is the variable of a table, it fails. Why is that?

X=cell(1,3);
S.X=X;
T=table(X);

[X{:}]=deal(1,2,3)  %Case (1) : works fine

X = 1×3 cell array
    {[1]}    {[2]}    {[3]}

[S.X{:}]=deal(1,2,3)  %Case (2) : works fine

S = struct with fields:
    X: {[1]  [2]  [3]}

[T.X{:}]=deal(1,2,3)  %Case (3) : fails

Error using deal (line 37)
The number of outputs should match the number of inputs.

[Stephen23]

Table overloads both subsref and subsasgn. Its indexing is nothing like any other class.

[Paul]

Why does the second call to deal result in three copies of the same displayed output?

X = cell(1,3);
T = table(X);
[X{:}] = deal(1,2,3)

X = 1×3 cell array
    {[1]}    {[2]}    {[3]}

[T.X{1},T.X{2},T.X{3}] = deal(1,2,3)

T = table
               X           
    _______________________

    {[1]}    {[2]}    {[3]}

T = table
               X           
    _______________________

    {[1]}    {[2]}    {[3]}

T = table
               X           
    _______________________

    {[1]}    {[2]}    {[3]}

[Matt J]

Table overloads both subsref and subsasgn.

Does that explain why comma-separated assignment would not be supported?

[Matt J]

Why does the second call to deal result in three copies of the same displayed output?

@Paul It is normal for unsuppressed output of CSL assignment to make nargout displays if it thinks the outputs are separate and unrelated variables, e.g.,

[a,b]=deal(1,2)

a = 1

b = 2

When you assign to separately indexed regions of the same variable, it apparently cannot tell they are related,

[X{1},X{2}] = deal(4,5)

X = 1×2 cell array
    {[4]}    {[5]}

X = 1×2 cell array
    {[4]}    {[5]}

as distinct from,

[X{1:2}]=deal(6,7)

X = 1×2 cell array
    {[6]}    {[7]}

[Stephen23]

"Does that explain why comma-separated assignment would not be supported?"

No, it explains why comparisons to other data types are not particularly useful.

[Matt J]

No, it explains why comparisons to other data types are not particualrly useful.

I don't know about that. This is a built-in Matlab data type meant as a general kind of container. All other containers support the full range of indexing.

[dpb]

" All other containers support the full range of indexing."

"All"?

map, timeseries, dataset, ...???

[Matt J]

All containers within the set of Fundamental Classes. Regardless, the main thing was that there doesn't seem to be a good reason for tables not to allow this.

[dpb]

I note there that the table/timetable are notably missing the "Use in comma separated lists" line item in the "Intended Use" column....guess it also shows how long it's been since I did more than look up individual functions in the doc -- I had forgotten about that overview page existing.

While I'd never attempted the addressing to a table in that fashion and wouldn't have thought of doing so in all likelihood anyway, I'll confess I don't know enough about the internals for it to be apparent to me why it couldn't be done; I would presume adding the additional complexity on top of existing logic could be a performance issue in adding yet another layer of complexity.

[Paul]

AFAICT, numArgumentsFromSubscript alway returns 1 for a table for assignment, at least for the various cases that I tried, which is why deal fails for the example at hand. But that also means that deal works for assigning to a scalar cell in the table variable

X = cell(1,1);
T = table(X);
[T.X{:}] = deal(pi)

T = table
        X     
    __________

    {[3.1416]}

or to one element of vector cell

X = cell(1,3);
T = table(X)

T = table
                         X                      
    ____________________________________________

    {0×0 double}    {0×0 double}    {0×0 double}

[T.X{2}] = deal(pi)

T = table
                        X                     
    __________________________________________

    {0×0 double}    {[3.1416]}    {0×0 double}

And deal can expand the table variable

[T.X{4}] = deal(8)

T = table
                             X                         
    ___________________________________________________

    {0×0 double}    {[3.1416]}    {0×0 double}    {[8]}

[T.X{2,3}] = deal(100)

T = 2×1 table
                                 X                              
    ____________________________________________________________

    {0×0 double}    {[  3.1416]}    {0×0 double}    {[       8]}
    {0×0 double}    {0×0 double}    {[     100]}    {0×0 double}

[Peter Perkins]

Paul, I can't tell what you are trying to demonstrate. Putting square brackets around things like X{2} and then using deal makes no sense to me. T.X{2} is one thing, i.e. "the contents of" the 1x3 cell array t.X. You don't need square brackets or deal for this any more than you need them for X{2} = pi.

>> X = cell(1,3);
>> T = table(X)
T =
  table
                         X                      
    ____________________________________________
    {0×0 double}    {0×0 double}    {0×0 double}
>> T.X{2} = pi
T =
  table
                        X                     
    __________________________________________
    {0×0 double}    {[3.1416]}    {0×0 double}

Even assigning two elements:

>> T.X(1,2:3) = {100}
T =
  table
                    X                 
    __________________________________
    {0×0 double}    {[100]}    {[100]}

I will also say that

>> table(cell(3,1))
ans =
  3×1 table
        Var1    
    ____________
    {0×0 double}
    {0×0 double}
    {0×0 double}

is probably what you want, not

>> table(cell(1,3))
ans =
  table
                        Var1                    
    ____________________________________________
    {0×0 double}    {0×0 double}    {0×0 double}

but I can't say for sure.

[Matt J]

This is just to point out that the issue affects table variables that are struct-valued as well.

[Sarr(1:3,1).X]=deal(0,0,0)

Sarr = 3×1 struct array with fields:
    X

S.Sarr=Sarr;  %Contain in struct
T=table(Sarr); %Contain in table

[S.Sarr.X]=deal(1,2,3); S.Sarr.X

ans = 1

ans = 2

ans = 3

[T.Sarr.X]=deal(4,5,6); T.Sarr.X

Error using deal (line 37)
The number of outputs should match the number of inputs.

[Paul]

@Peter Perkins

I was just trying to show that deal works when assigning scalar to scalar when using the general form

[CSL] = deal(CSL)

even though deal doesn't work for other cases as shown. That seemed like an inconsistency to me, even if one would never need to use deal for those scalar to scalar assignments.

I used table(cell(1,3)) because that was the example used in the Question that started this thread.

Answer 1

[Matt J]

According to Tech support, it is not a bug, just something that wasn't implemented for tables. However, they see it as a legitimate enhancement, and have filed it as an enhancement request.

[Jack]

Hi Matt,

Yes, we're aware of this indexing inconsistency and consider it a valid enhancement. Do you have any examples of workflows or use-cases where comma-separated list assignment comes up/is more suitable than its alternatives?

Like @dpb pointed out, there are other ways to do this kind of assignment. More commonly, users have a cell array and not a comma-separated list, so these alternatives are usually sufficient.

[Matt J]

Hi @Jack,

More commonly, users have a cell array and not a comma-separated list, so these alternatives are usually sufficient.

I assume you meant to say "more commonly users have a cell array and not a struct array"? Comma-separated-list assignment is not a distinct thing from cell arrays. It is an operation that both struct and cell arrays support.

The alternative assignment methods you mention appear to apply only to cells and not to structs. If struct assignment were uncommon compared to cell assignment, I guess that limitation wouldn't matter as much, but I don't know how anyone could know which is more common.

Do you have any examples of workflows or use-cases where comma-separated list assignment comes up/is more suitable than its alternatives?

The use cases are those where you want to populate a container with varargout. The advantage of varargout in conjunction with comma separated lists is that you don't have to write the function with any prior knowledge of whether the output is going to be assigned to brace-indexed or to dot-indexed containers. As an example, the function dealfun below is a utility I use to invoke a function on a series of inputs and send the results to a container. It works for at least 3 different container forms, but not when the container is a table variable.

X=cell(1,3);
S.X=X;
Sarr(3).X=[];
T=table(X);

[X{:}]=dealfun(@(x) x.^2, 2,3,4)

X = 1×3 cell array
    {[4]}    {[9]}    {[16]}

[Sarr(1:3).X] = dealfun(@(x) x.^2, 2,3,4); Sarr.X

ans = 4

ans = 9

ans = 16

[S.X{:}]=dealfun(@(x) x.^2, 2,3,4)

S = struct with fields:
    X: {[4]  [9]  [16]}

[T.X{:}]=dealfun(@(x) x.^2, 2,3,4)

Error using . (line 514)
Assigning to 3 elements using a simple assignment statement is not supported. Consider using comma-separated list assignment.

function [varargout]=dealfun(fun,varargin)
%Apply function to all arguments and deal() the results


 varargin=cellfun(fun,varargin,'uni',0);

 varargout=varargin(1:nargout);

end

Answer 2

[dpb]

As @Stephen23 notes, table addressing is its own animal...

The table is a one-row cell array in one vairable so it can be assigned directly as a cell can be...

X=cell(1,3);
T=table(X)

T = table
                         X                      
    ____________________________________________

    {0×0 double}    {0×0 double}    {0×0 double}

T.X={1 2 3}

T = table
               X           
    _______________________

    {[1]}    {[2]}    {[3]}

No need for deal() here as the dot-X notation returns the cell array in its entirety. Of course, in a table cell, it can contain anything any other cell can

T.X(1:2)={1 2};
T.X(3)={'Fred Flintstone'}

T = table
                      X                  
    _____________________________________

    {[1]}    {[2]}    {'Fred Flintstone'}

T.X

ans = 1×3 cell array
    {[1]}    {[2]}    {'Fred Flintstone'}

[Peter Perkins]

Ah, I see that dpb has beat me to it. I will just add: If you find yourself relying on CSLs and/or deal anywhere in MATLAB, there is almost certainly a better way to do it.

In this case, the better way is, leave the cell array (whether it be X or T.X) as a cell array. Don't CSL expand it. I'm skeptical (but of course might be wrong) that deal(1,2,3) represents a real use case where there are three separate things in separate workspacce vars. But even if it is, just wrap them in braces and assign to the cell array:

>> X = cell(3,1);
>> T = table(X)
T =
  3×1 table
         X      
    ____________
    {0×0 double}
    {0×0 double}
    {0×0 double}
>> T.X = {1;2;3}
T =
  3×1 table
      X  
    _____
    {[1]}
    {[2]}
    {[3]}
>> T.X(:) = {11;22;33}
T =
  3×1 table
      X  
    _____
    {[11]}
    {[22]}
    {[33]}
>> T.X(2:3) = {222;333}
T =
  3×1 table
      X   
    ______
    {[ 11]}
    {[222]}
    {[333]}

[Matt J]

But even if it is, just wrap them in braces and assign to the cell array:

But you don't always know that the comma-separated assignment destination will be a cell array. It could equally well be a struct array. The advantage of deal, and other functions employing varargout, is that you don't have to care.