Would comma-separated list expansion for non-cell arrays be a good thing?
Latest activity Reply by Bjorn Gustavsson
on 12 Jan 2026 at 10:03
Frequently, I find myself doing things like the following,
xyz=rand(100,3);
XYZ=num2cell(xyz,1);
scatter3(XYZ{:,1:3})
But num2cell is time-consuming, not to mention that requiring it means extra lines of code. Is there any reason not to enable this syntax,
scatter3(xyz{:,1:3})
so that I one doesn't have to go through num2cell? Here, I adopt the rule that only dimensions that are not ':' will be comma-expanded.
4 Comments
Time DescendingFor functions I repeatedly use in a project, I usually create anonymous functions that take the data as I want it
fScatter3 = @(x, varargin)scatter3(x(:,1), x(:,2), x(:,3), varargin{:});
Bonus is that, if you want, you can also put default arguments that you like, and/or do further weird stuff like
fScatter3 = @(x, varargin){figure, scatter3(x(:,1), x(:,2), x(:,3), '.', varargin{:}), legend};
I like the idea very much however, this -
I adopt the rule that only dimensions that are not ':' will be comma-expanded.
would need some tweaking. Based on your rule, an operation like [xyz{:,1:3}] should always return the original array xyz. The trouble is, there are certain non-cell array types that already have a different predefined behaviour. An example is -
xyz=string(rand(2,3)),
[xyz{:,1:3}] %not the original array
As I said, in principle this capability is appealing but you would need a different indexing character other than ':' for specifying which dimensions to keep in a page. Maybe something like -
scatter3(xyz{nan,1:3})
Sign in to participate