Trouble with plotting different symbols and colors indexed by a matrix in an m-file. How do I make the m-file handle color and symbol strings that work on command line?

I have an m-file where I am trying to dynamically plot different indexed parts of a data set with different symbols and colors. The idea is to plot blank contamination data performed by different analysts and being able to see what analysts plot out where in the contamination field so I can adapt my training to analysts who repeatedly register a high blank. The data set is constantly changing, so I have an m-file that reads the data file and creates a Color Array and a Symbol Array based on the number of different analysts in a single data set. These arrays are of different sizes so that color and symbol pairs will not reproducible for quite some time.

I tested some code on the command line, and it worked. However, in the m-file it doesn't work. I get the error message:

ans = 
  'v'
Error using matlab.graphics.chart.primitive.Line/set
While setting the 'Marker' property of 'Line':
Invalid enum value. Use one of these values: '+' | 'o' | '*' | '.' | 'x' | 'square' | 'diamond' | 'v'
| '^' | '>' | '<' | 'pentagram' | 'hexagram' | 'none'.

Error in LiveBlankDeterm (line 168)
  set(ss,'Marker',symbols{k(1)});

The "answer: 'v'" line is a probe I put in the code to see exactly what the the m-file is trying to insert into the plot command line. With or without the single quotes, this error message is generated, but you can see that the string ('v' or v, in this case, is the first symbol in the symbol array) fails to register in the plot command. Furthermore, if I tweak the order and specify the color array first, before the symbol array, it generates the error message the color must be in numeric form (3-element vector, 0-1 for each element).

The m-file code that is generating this error looks like this:

hold on
for nn=1:max(abbcounter)
  k=find(namecode==nn);
  symbols{k(1)}
  ss=plot(D(min(k):max(k),1)/1000,D(min(k):max(k),2));
  set(ss,'Marker',symbols{k(1)});
end

From the "set" line, I can add or alternate the color array. The namecode is simply an integer in the data corresponding to the analysts' abbreviations used to generate the legend.

In command line, similarly written code (in this case not using the set command, but addressing the linespec properties directly) like -

plot(nn,b(min(k):max(k)),'Marker',symbols{nn})

works just fine. But not in the m-file.

Any ideas on how I can improve this code to make it work - from a modest tweak to a complete change in program flow?

Thanks, Brad

[dpb]

From what is shown I don't see a reason for the error, either.

Can you make a demonstration of the small subsection from the larger code that illustrates the issue when run alone and attach it with the data and command that creates the symptom? Perhaps in doing this you'll find the error that caused the problem or will be able to show there's an issue with a given release although I suspect there is a issue somewhere that just isn't being shown in the snippet posted..

I note that you have the code in a loop and are saving the line handle returned from plot in a variable ss. As you've written it, you're overwriting that variable every time through the loop so you've lost access to the preceding lines on all subsequent passes. This isn't the immediate problem but likely will be an issue when you want to make other changes to various specific lines. You need to save an array of line handles, not just the single one.

[dpb]

I thought I'd demo a function so started with yours and modified slightly --

function brad(D,namecode)
  symbols={'*','o','+','.','x','^','v'};
  abbcounter=1;            % just do one to demo
  hold on
  for nn=1:max(abbcounter)
    k=find(namecode==nn);
    ss=plot(D(min(k):max(k),1),D(min(k):max(k),2));
    set(ss,'Marker',symbols{nn});
  end
end

I couldn't quite decipher your use of namecode; it seems k is being used as both a location in the vector that is to be labelled and as in index into the symbol array. I had problem in your code that k is an addressing problem in the array so if I get your idea, that should be nn I think as above.

With the code from command line first, the above gives the figure shown--

>> D=[1:100;rand(1,100)].';   % fake data for a basic plot
>> plot(D(:,1),D(:,2))        % and make a plot to mung on...
>> namecode=zeros(1,length(D));  % make the locations to mark
>> namecode(20:30)=1;            % with first symbol 
>> brad(D,namecode)
>>

This illustrates there's nothing "magic" about using the array of symbol types inside a function vis a vis command line; there's something else going on as hypothesized above that's causing the problem but we don't have full-enough context to see it from the snippet posted.

The above illustrates the kind of test case I was suggesting; you can fix the data to work with whatever it is that your definition of namecode is if indeed your lookup above works as is intended but I have doubts on that particular point...maybe you modified or extracted some code to produce the snippet and left something out???

[Brad Rosenheim]

Hi dpb -

I used the k value to find the values in the data matrix (D) that have the same analyst. I did it this way to accommodate different numbers of entries from different analysts. That way the plot routine would only run for each group containing the same analyst (the data file is sorted by analyst number, or namecode, at this point). So k contains the indices of the points I want to plot with the different analysts, as well as the corresponding indices in the colors and symbols arrays. The loop runs nn times, where nn is the number different analysts.

I am trying to pull out a snippet of code that you suggested. I think this is a great idea, rather than trying individual lines on the command line. I'm just full of meetings today!

Brad

[dpb]

So is size(symbols)==length(D) then? That seems pretty wasteful storage given there are only a dozen or so possible values available. Or perhaps I still don't follow is always a real possibility... :)

[Brad Rosenheim]

You follow perfectly. Part of that clumsiness is the need to construct a vector of symbols and colors that will not repeat and can be dynamic - given a length of D, there may be one analyst (one combination of color and symbol) or a number equal to the length of D (number of colors and symbols pairs = size(D)). However, I have a counter of analysts (abbcounter <= D), and that may be a better way to index the color and symbol arrays.

I have discovered that, in the m-file and on the command line, the magic in LineSpec is that these properties do not load correctly if with the extra layer I have created. In other words, if the indices are stored in a variable k, then the command

set(handle,'Color',colors{k(nn)})

will not work (generates the same error I started this post with). However, if the line is simplified to

set(handle,'Color',colors{k})

the command will work. So there is some magic, and it appears I have to simplify the indexing (and, as you said, not waste the allocation space) to get this job done.

Hope for the near future, but meetings today prevented me from finishing this.

Thanks, Brad

[Walter Roberson]

Could I ask that you do a quick check of

class( symbols{k(1)} )

[dpb]

"set(handle,'Color',colors{k(nn)}) will not work [but] set(handle,'Color',colors{k}) will"

Then the problem is in what are k and nn. In the preceding code k is an array returned from find and so can be anything from empty to 1 to an array of length(D). If nn is the loop index as above, then it's the subscript into that array of elements and it would appear there's an error in those content at some point.

NB:

In your debug code above the element 'v' is displayed with the single quotes around the character. This implies the content is a cell string, not a character array. Since the code you show used curly braces to dereference the element, this means you've got a cellstring within a cell array element. I'd guess that's the root source of your problems and the reason different indexing syntaxes aren't functioning as you expect.

To see what you have with respect to the above regarding the color property would need to see the code section that builds the colors array is actually doing.

Here's a demo at the command line of the difference for the cell string stuff though --

>> symbols={'*','v','>','<','square'};   % list of symbols used
>> symbols(1)   % reference first element, parens
ans =           
    '*'
>> whos ans     % result is cell string (quotes show that)
  Name      Size            Bytes  Class    Attributes
  ans       1x1                62  cell               
>> symbols{1}   % dereference with the curlies {}
ans =
*
>> whos ans     % result is character array (no ' around content)
  Name      Size            Bytes  Class    Attributes
  ans       1x1                 2  char               
>> symbol{1}=symbols  % accidentally store into a cell variable
symbol = 
    {1x4 cell}
>> symbol{1}          % now first cell is the whole previous content
ans =                 % a cell array that may not work as intended
    '*'    'v'    '>'    '<'
>>

Also note the difference between the cell string content and the character array can "bite"...

>> symbols(5)    % look at last entry that's more than one character
ans = 
  'square'
>> symbols{5}
ans =
square
>>

As expected, curlies and parens act as previously to get cell string or full character array.

But, again, if assign to another variable somewhere in the building process of making up the array

>> s=symbols{5}      % assign the content to another variable
s =
square
>> s(1)                % address that character array w/ one subscript
ans =
s
>>

and note got only the first character of the string, not the full string. That's the difference between cell strings and character arrays.

I'm guessing your problems are in such addressing issues and how you're building the arrays of symbols and colors to make the unique combinations you've got some addressing "issues" to resolve.

You can do what you're after, likely there's an easier addressing solution if we see more of what you're actually doing...or the above may be enough for you to see what's gone wrong when you get to it.

As for meetings, I can relate -- I'm spending the bulk of my time these days that way with local non-profit I'm helping out with...

[Walter Roberson]

The display of characters and cells changed in more recent versions, especially R2017b, so the appearance of the quote marks can no longer be taken as proof that the value was a cell array.

[dpb]

Ewww...that's ugly. Is there any way other than 'whos', then?

[Walter Roberson]

class() ?

[dpb]

I suppose this is a result of the new string class? Being able to tell what you had at the command line without other machinations was always a real boon to debugging in particular.

[Walter Roberson]

The decorations were generally added to in R2017b, giving more information than before to emphasize class, but sometimes in a "too much information" way.

>> n_raw = {
0.023391
0.31236
0.0073958
0.6252
14.158
-14.159
0.046701
0.095463 } 
n_raw =
  8×1 cell array
    {[ 0.023391]}
    {[  0.31236]}
    {[0.0073958]}
    {[   0.6252]}
    {[   14.158]}
    {[  -14.159]}
    {[ 0.046701]}
    {[ 0.095463]}

>> n_raw{1,1} = {1}; n_raw{1,2} = 'hello'; n_raw{2,1} = [1 2] 
n_raw =
  8×2 cell array
    {1×1 cell   }    {'hello'   }
    {1×2 double }    {0×0 double}
    {[0.0073958]}    {0×0 double}
    {[   0.6252]}    {0×0 double}
    {[   14.158]}    {0×0 double}
    {[  -14.159]}    {0×0 double}
    {[ 0.046701]}    {0×0 double}
    {[ 0.095463]}    {0×0 double}

In other words there is no point in using the [] within the {} of each cell because it is not possible for anything more than a scalar (or character vector, or single string) to be displayed there. Adding the {} decoration at every point implies that there is the potential for multiple items to be displayed inside the {}, which is not the case.

... To which Mathworks replied that this new decoration does not apply if you specifically ask to disp() a value.