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.

11 个评论

Table overloads both subsref and subsasgn. Its indexing is nothing like any other class.
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]}
Table overloads both subsref and subsasgn.
Does that explain why comma-separated assignment would not be supported?
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
Stephen23 2026-6-20,12:14
编辑:Stephen23 2026-6-20,13:33
"Does that explain why comma-separated assignment would not be supported?"
No, it explains why comparisons to other data types are not particularly useful.
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.
" All other containers support the full range of indexing."
"All"?
Matt J
Matt J 2026-6-20,14:16
编辑:Matt J 2026-6-20,14:19
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
dpb 2026-6-20,14:25
编辑:dpb 2026-6-20,14:29
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.
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}
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
Matt J 2026-6-22,14:57
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.

2 个评论

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.
Hi @Jack,
More commonly, users have a cell array and not a comma-separated list, so these alternatives are usually sufficient.
I wonder how anyone would know that. How common such things are seems like a difficult thing to track.
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 the container type the output is going to. 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 scenarios, but not tables.
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

请先登录,再进行评论。

更多回答(1 个)

dpb
dpb 2026-6-19,20:38
编辑:dpb 2026-6-19,20:39
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'}

2 个评论

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
Matt J about 3 hours 前
编辑:Matt J about 3 hours 前
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.

请先登录,再进行评论。

类别

帮助中心File Exchange 中查找有关 Tables 的更多信息

产品

版本

R2024b

提问:

2026-6-19,19:41

编辑:

about 6 hours 前

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by