Bug or Normal behavior in Table variable Types?
显示 更早的评论
I am defining a table variable as having class "cellstr".
But if (for reasons specific to the project) the first row is not filled and the second row is filled first, Matlab seems to insert a 'double' in the 1st line cell that is previously defined as "cellstr".
See simplified example below. Shouldn't the empty row (1st row) in the table be filled with 0x0 char rather than 0x0 double?
Is this a bug or am I missing something in the way Matlab assigns default emtpty values?
myTable = table('Size',[0,1],'VariableNames',{'Var1'},'VariableTypes',{'cellstr'})
summary(myTable)
myTable.Var1{2} = 'Char Vector'
class(myTable.Var1{1})
采纳的回答
dpb
2021-12-6
That is behavior I've observed with table from initial inception.
I, too, agree that it is not intuitive inside the table and not the way I would have designed it to work with a table, but it is consistent with the way cells work, so it's probably not going to change.
>> c{2}='String';
>> c{1}
ans =
[]
>> whos ans
Name Size Bytes Class Attributes
ans 0x0 0 double
>>
You see that if you the same thing in a cell array, the missing cell is the default double. That's "just MATLAB".
It seems like I made an enhancement request along these lines some time back specific to table and timetable, but I do not recall ever getting feedback.
I didn't report it as a bug as I was sure that would be treated as "WAD" (working as designed) owing to the above behavior.
I think you will have to store the empty cellstr in your creation code somewhere; I don't think there's any way to force MATLAB to behave as you would like with the missing assignment.
4 个评论
dpb
2021-12-6
I don't disagree and, in fact, do agree with your assessment that the current behavior inside a table "is just rude!"
My suspicion is that "WAD" would be the TMW response to a bug report, but I agree it isn't intuitive nor desirable to have the type change this way. I've run into the same issue before myself.
I'll think about how to write/submit an enhancement request or whether to submit a bug report just to get an opinion from TMW support.
Eric Sofen
2021-12-7
@dpb's take on this is pretty much in line with our thinking. Tables are containers and we try to let the types that they contain behave as they would if they were stand-alone variables in MATLAB.
Keep in mind that cellstr are a particularly troublesome pseudo-type. This is why we introduced string for working with arrays of text. I think if you preallocated your table with a string variable instead of cellstr,
myTable = table('Size',[0,1],'VariableNames',{'Var1'},'VariableTypes',{'string'})
this assignment will still work:
myTable.Var1{2} = 'Char Vector'
And the first element will be a missing string.
I dunno, @Eric, while I grok the behavior mimics the cell behavior standalone, I'm more in @Assen's corner once the variable is defined as the variable type for a table variable -- I agree with him in thinking there, that definition should be controlling within the table. I don't think that breaks expectations WITHIN THE TABLE variable even though the behavior doesn't quite mimic the outside world.
The string may be aworkabout, but sometimes strings aren't as convenient as cellstr, either, depending upon what one is doing with them.
That said, do appreicate the TMW feedback...
更多回答（0 个）
类别
在 帮助中心 和 File Exchange 中查找有关 Characters and Strings 的更多信息
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!
Translated by 
