In the old days (before R2013a), nominal() and ordinal() were separate parallel\u00a0classes\u00a0with astoundingly\u00a0similar structures. That means there’s a lot of copy-paste-mod going on. TMW improved on it by\u00a0consolidating the ideas into a new categorical() class, which nominal() and ordinal() derives from it.<\/p>\n
The documentation mentioned that nominal() and ordinal() might be deprecated in the future, but I contacted their support urging them not to. It’s not for compatibility reasons: nominal() and ordinal() captures the common use cases that these two ideas do not need to be unified, and the names themselves clearly encodes the intention.<\/p>\n
If the user want to\u00a0exploit the commonalities between the two, either it’s already taken care of by the parent’s public methods, or the object can be sliced to make it happen. I looked into the source code for nominal() and ordinal(): it’s pretty much a wrapper over categorical’s methods yet the\u00a0interface (input arguments) are much simpler and intuitive because we don’t have to consider all the\u00a0more general cases.<\/p>\n
Back to the titled topic. Because categorical()’s properties (members) are different from\u00a0pre R2013a’s nominal() and ordinal() objects, the objects created in R2012b or before cannot be loaded correctly in newer versions. That means the backward compatibility is completely broken for nominal()\/ordinal() as far as saved objects are concerned.<\/p>\n
There’s no good incentive to solve this problem on the TMWs side because the old nominal()\/ordinal() is short-lived and they always want everybody to upgrade.\u00a0Since I use nominal() most of the time and the ones that really need to be saved are all nominal(), I recommend the converting (‘casting’) them to cellstr by<\/p>\n
>> A = nominal({'a','a','b','c'});\r\n>> A = cellstr(A)\r\nA = \r\n 'a' 'a' 'b' 'c'<\/pre>\nRemember, nominal() is pretty much compressing a ton of cellstr into a few unique items and mapping the indices.\u00a0No information is lost going back and forth between cellstr() and nominal(). It’s just\u00a0a little extra computations for the conversion.<\/p>\n
As for ordinal(),\u00a0I rarely need to save it because order\/level\u00a0assignment is almost the very last thing in the processing chain because it changes so frequently (e.g. how would you draw the lines for six levels of fatness<\/a>?), I might as well just not save it and reprocess the last step (where the code with\u00a0ordinal() sits) when I need it.<\/p>\nNonetheless, if you still want to save ordinals() instead of re-crunching\u00a0it, this time you’ll want to save it as numerical levels by casting the ordinal() into double():<\/p>\n
>> A = ordinal([1 2 3; 3 2 1; 2 1 3],{'low' 'medium' 'high'}, [3 1 2])\r\nA = \r\n medium high low \r\n low high medium \r\n high medium low \r\n>> D = double(A)\r\nD =\r\n 2 3 1\r\n 1 3 2\r\n 3 2 1\r\n>> U = unique(A)\r\nU = \r\n low \r\n medium \r\n high \r\n>> L = cellstr(U)\r\nL = \r\n 'low'\r\n 'medium'\r\n 'high'\r\n>> I = double(U)\r\nI =\r\n 1\r\n 2\r\n 3\r\n>> A_reconstructed = ordinal(D, L, I)\r\nA_reconstructed = \r\n medium high low \r\n low high medium \r\n high medium low<\/pre>\nYou’ll save (D, L, I) from old MATLAB and load it and reconstruct it with the triplets from the new MATLAB (I’d suggest using\u00a0structs to keep track of the triplets).\u00a0I know it’s a hairy mess!<\/p>\n
<\/p>\n
<\/div>\n