Convert class types in table

I have a table with different variables consisting of different class elements. Call the table T & the variables A1, A2, A3.

So, class(T.A1) is cell, and class of each individual entry in T.A1 is double.

Class(T.A2) is cell, and class of each individual entry in T.A2 is char.

Class(T.A3) is cell, and class of some entries here is double & some others is char. It appears that the char values are all char([]).

For further operations, I need to convert all values in A1 & A3 to numeric (say double). I tried to replace all the char([]) in T.A3 with []. This works & class of each element in T.A3 now reports as double. However, when I further try:

T.A3 = cell2mat(T.A3)

I get the error: "Brace indexing is not supported for variables of this type. Error in cell2mat..." etc.

Please help figure out what may be wrong, and alternatively suggest how to accomplish the above.

[Stephen23]

Please upload your table in a MAT file by clicking the paperclip button.

"I tried to replace all the char([]) in T.A3 with []."

How did you do that?

"This works & class of each element in T.A3 now reports as double."

How did you check that?

[AR]

Replacing the char with double:

tempcells = find(strcmp(T.A3, char([])));
if ~isempty(tempcells)
    T.A3(tempcells) = {[]};
end

Checking that all of A3 report as double:

for i = 1:size(T,1)
    b{i} = transpose(class(T.A3{i}));
end
find(~strcmp(b, 'double')
find(strcmp(b, 'double')

The first find yields 0x1 empty double column vector. The second find yields all the row numbers of T.

[dpb]

As @Stephen23 says, if you want specific help directly applicable to your case, attach a pertinent section of the table with code.

I'd venture it could/would probably be better to go back a step to the creation of the table from the file and fix the import object to read the data correctly to start with...generally such issues are caused by missing or malformed data in the input files that can be (usually, anyway) fixed with an import object if not just command switches/parameters.

So, attach the input file and the code used to bring it in to the table...

[AR]

Thanks for the suggestions. I doubt that I can upload the actual data file or table, as this is proprietary customer information. Your suggestions make sense, in that it's probably better to fix at the source or during import. The former is hard as the file usually contains tens of thousands of rows. The latter may be possible and I will take a look at this.

[dpb]

I'd be almost certain you can create a file of a few (30 or so) records that illustrates the format and the issues you're having importing the data that can be obfuscated enough to avoid giving away in trade secrets...if it's empty fields and the like that are the issues, they're not real data anyways.

Unless there are actual real data identified as to what and to whom it belongs along with context of what it is, there's essentially no chance anybody could make any use of it, anyway.

[AR]

Thanks for the comments & suggestions. I was able to revisit the import, and customize it to eliminate data-type problems. I suppose I was using the "raw" read-in data which contains a combination of char & double to formulate the table. By instead using the numeric and char outputs separately and synthesizing the table that way, these problems were taken care of.

[dpb]

".... I was using the "raw" read-in data which contains a combination of char & double to formulate the table. By instead using the numeric and char outputs separately..."

That implies you were/are using the deprecated xlsread instead of readtable -- I strongly recomend looking at readtable and its boon companion detectImportOptions instead.

[AR]

Noted, for future reference. I forget about readtable although I think I have used it in the past.