BUG or desired behaviour? assigning struct wont display its contents correctly

Question

Sven Larsen 2025-8-21

0
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/2179513-bug-or-desired-behaviour-assigning-struct-wont-display-its-contents-correctly

编辑： Stephen23 2025-9-4，13:27

There seems to be a bug in Matlab where structs are looking incorrect. Hard to imagine this kind of behaviour is desirable?

Struct I already have:

when I copy some fields into new struct with command:

newStruct.name = {wavFiles.name};
newStruct.startTime = {wavFiles.startTime};

I get idiotic looking struct wich is obviously erroneus:

Only way I have found to create correct looking struct is:

newStruct = struct('name', {wavFiles.name});
[newStruct.startTime] = wavFiles.startTime;

which produces this correct and beautiful looking struct:

is there any way to avoid this other than always using overly compicated:

newStruct = struct('name', {wavFiles.name});
[newStruct.startTime] = wavFiles.startTime;

One would assume intuitively that

newStruct.name = wavFiles.name;
or
newStruct.name = {wavFiles.name};

would produce correct looking struct but according to weird matlab logic i guess not :/

0 个评论
显示 -2更早的评论隐藏 -2更早的评论

请先登录，再进行评论。

请先登录，再回答此问题。

Answer 1

Stephen23 2025-8-21

1
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/2179513-bug-or-desired-behaviour-assigning-struct-wont-display-its-contents-correctly#answer_1569599

编辑：Stephen23 2025-8-21

"I get idiotic looking struct wich is obviously erroneus:"

No, it is not "obviously erroneous", nor is it a bug.

It looks like a perfectly correctly formed scalar structure with fields consisting of cell arrays. Which is exactly what you told MATLAB to create, so it is unclear what you imagine the bug to be.

You told MATLAB create one cell array containing all of those names. You then assign that one cell array to a scalar structure, so that is exactly what you get: a scalar structure with a field which consists of one cell array

If you do not want to combine all of the names into one cell array then do not combine all of the names into one cell array. Why did you do that?

https://www.mathworks.com/matlabcentral/discussions/tips/847976-tutorial-comma-separated-lists-and-how-to-use-them

"is there any way to avoid this other than always using overly compicated:"

Calling STRUCT is the standard, obvious, documented approach to generate a non-scalar structure. You could also use REPMAT, CELL2STRUCT, indexing, etc. to generate a non-scalar structure.

"One would assume intuitively that newStruct.name = wavFiles.name... would produce correct looking struct"

The LHS will be implicitly created as a scalar struct, just as documented in STRUCT. The STRUCT documentation also clearly states "You also can create a structure array using the struct function, described below. You can specify many fields simultaneously, or create a nonscalar structure array." You want a non-scalar structure, the documentation tells you how to create a non-scalar structure. It is unclear what the problem is.

See also your earlier questions related to structures, their advice would be useful to remember:

https://www.mathworks.com/matlabcentral/answers/2165363-allocate-array-to-structure-error-scalar-structure-required-for-this-assignment

https://www.mathworks.com/matlabcentral/answers/2092711-how-to-avoid-creating-1x1-struct

https://www.mathworks.com/matlabcentral/answers/2084873-cheatsheet-for-dealing-with-structures

Perhaps it would help to revise those threads and the information that they link to. Also check your intermediate data arrays, as that would also help you to know what data you are working with (for example, once you have created your cell array there is absolutely nothing in your code that refers to its contents, so whatever you asisgn will be that entire cell array).

3 个评论
显示 1更早的评论隐藏 1更早的评论

Sven Larsen 2025-8-21

编辑：Sven Larsen 2025-8-21

Hello!

Users (there are a lot questions about legendary error "Scalar structure required for this assignment.") who are time and time again confused about this overly complicated syntax should indicate Mathworks devs that perhaps they should simplify and streamline things.

for example is user wants to create new strct from one of old strucs fields. syntax should very, very obviously be newStruct.field = oldStruc.field. NOT [newStruct.field] = oldStruc{:}.field or alike wayyyy overcomplicated syntax.

This is why so many nonexpert users find this fustrating, is because even the basic syntaxes considering structs (which are by far most useful and visual data storing method in matlab) are overly complicated which makes absolutely no sense.

in one of your answer you wrote:

Storing lots of scalar numerics in a non-scalar structure will generally make processing your data harder and less efficient than storing numeric arrays in a scalar structure. A table might be a better choice for your requirements.

this is users choice and should never discourage user to not use method of choice just because something is not effective. I deal with statistics and big data quite often, and visuall see what those structs contain is vital to me. Perhaps now you understand why I have asked for cheatsheets etc to help dealing with structures. Because people are tired of guessing does assigning values to structure require today perhaps [] notion in new structure? or perhaps {:} on old structure? or maybe its deal() this time, no wait it actually might be num2cell()

Sven Larsen 2025-8-21

在 MATLAB Online 中打开

as for my post/question, I still dont know other way to create my struct other than lines

newStruct = struct('name', {wavFiles.name});
[newStruct.startTime] = wavFiles.startTime;

and I find this simple example good one arguing my point. Lets dissect those two lines:

newStruct = struct('name', {wavFiles.name});

in laymans terms read "I want to create stuct called 'newStruct' that contains field named 'name' and associate all data from struct wavFiles.name

which intuitively SHOULD be identical to command:

newStruct.name = wavFiles.name

...but they are not. And this right here is the culprit; intuitive syntax is not the correct one, which is sign of bad design.

Stephen23 2025-8-21

编辑：Stephen23 2025-9-4，13:27

"syntax should very, very obviously be newStruct.field = oldStruc.field"

Lets consider your proposed syntax and see what it implies.

Accessing the field of a structure generates a comma-separated list. Lets first look at the RHS of your proposed syntax, it is equivalent to

LHS = oldStruc(1).field, oldStruc(2).field, .. , oldStruc(end).field

In general this is not valid syntax on the RHS for multiple assignments to the LHS. However, the interesting situation occurs on the LHS. What you are suggesting is that the LHS should be parsed as:

newStruct(1).field, newStruct(2).field, .., newStruct(end).field = RHS

where you assign to multiple arrays at once. Again we note that your proposed syntax is inconsistent with MATLAB, which clearly documents that multiple assignments on the LHS require square brackets. With square brackets on the LHS is therefore valid syntax (if newStruct already exists and has a suitable size) for multiple assignments on the LHS:

[newStruct.field] = RHS

and is equivalent to:

[newStruct(1).field, newStruct(2).field, .., newStruct(end).field] = RHS

So instead of following the one rule that already exists and works for all output arguments you want to create new, special-case rules. But lets press on, because your proposed syntax creates a much more interesting conflict. In order for your proposal to work a comma-separated list on the LHS would have to be somehow "greedy", sucking up as many outputs as the RHS can produce. That produces an immediate and obvious conflict with functions like NDGRID, MESHGRID, IND2SUB, SIZE, etc. that can produce an unlimited number of output arguments. Your proposal requires that this syntax:

S.field = NDGRID(..)

would have to force NDGRID to return unlimited output arguments and generate a structure with unlimited size. Your proposed syntax would also make this common and simple syntax impossible to use:

[S.field,Y,Z] = RHS

because instead of implicitly creating S as a scalar structure with one field (if S does not already exist) then your proposed concept would require that S is created with a size that "vacuums up" as many outputs from the RHS as it can, leaving nothing left over for assigning to Y and Z. I struggle to see how that would be an improvement on the current behavior.

Of course you might now argue that all of these contradictions (and the other ones that I have not thought of yet) could be resolved by adding lots of new rules and new special cases... which is probably true, if you want to work with a language full of special cases and special rules.

No thanks, I would rather stick to the simpler (mostly) consistent syntax that MATLAB currently uses.

请先登录，再进行评论。