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'})

myTable =

  0×1 empty table

summary(myTable)

Variables:

    Var1: 0×1 cell array of character vectors

myTable.Var1{2} = 'Char Vector'

myTable = 2×1 table
         Var1      
    _______________

    {0×0 double   }
    {'Char Vector'}

class(myTable.Var1{1})

ans = 'double'

Answer 1

[dpb]

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.

[Assen Koev]

Thanks for confirming and the details, @dpb.

I can see how the the cell functionality you noted may be driving the functionality in Tables.

But cells have no predefined data types for elements, Tables do.

The way this issue is handled right now, literally overrides without warning the definition by the user. See the "summary" command results below. Not sure how allowing elements of class "double" in variables defined as "cellstr" is WAD and why cellstr definition cannot be enforced when, for example, cellstr(1) returns an error, as expected.

In any case, info was most appreciated.

myTable = table('Size',[0,1],'VariableNames',{'Var1'},'VariableTypes',{'cellstr'});
summary(myTable)

Variables:

    Var1: 0×1 cell array of character vectors

myTable.Var1{2} = 'Char Vector';
summary(myTable)

Variables:

    Var1: 2×1 cell

[dpb]

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]

@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.

[dpb]

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...