# WHY ARE THE COLORS OF MY LEGEND ALL MESSED UP?

3 views (last 30 days)
Ori Iger on 12 Nov 2020
Commented: David Goodmanson on 17 Nov 2020
for mu=0:0.2:1
.
.
.
c = ['k','r','g','b','y','c'];
c(1+5*mu)
plot(P,P_dot(P,Q),'color',c(1+5*mu));
hold on
plot(Q,Q_dot(P,Q),'LineStyle','--','color',c(1+5*mu));
hold on
yline(0);
end
h=get(gca,'Children');
legendstr={'P, \mu=0','Q, \mu=0','P, \mu=0.2','Q, \mu=0.2','P, \mu=0.4','Q, \mu=0.4','P, \mu=0.6','Q, \mu=0.6','P, \mu=0.8','Q, \mu=0.8','P, \mu=1','Q, \mu=1'};
legend(h([1 2 3 5 7 9 11]),legendstr{[1 2 3 5 7 9 11]}) %([1 3])
% this doest help either - "hPlots = flip(findall(gcf,'Type','Line'));"

#### 1 Comment

Sylvain on 12 Nov 2020

David Goodmanson on 12 Nov 2020
Hi OI,
One reason that Sylvain posted his comment is that you do not provide working code. And of course your odds of getting an answer improve if you have code that people can run (or, if there is an error, code that can at least run up to the relevant error message.) So it was necssary to make up some data.
There are two reasons for the color problem. One is the yline(0) command which totally messes up
h=get(gca,'Children');
You must either get rid of yline or figure some way around it. Might not be worth it. After getting rid of yline, you get a good result for h, twelve lines. Except that the order is reversed from what you think. Try
legend(h(13 -[1 2 3 5 7 9 11]),legendstr{[1 2 3 5 7 9 11]}) %([1 3]
By the way it is not a good idea to create indices with floating point numbers, as in
for mu=0:0.2:1
..
c(1+5*mu))
..
It works in this case, but it's not a technique with a bright future.

Show 1 older comment
Ori Iger on 15 Nov 2020
BTW you were very right about that yline(), did not know he was taken to account and he did mess everything up. would love to find a way to just draw that line, it is merely the reference of the graph I made (phase-space).
Thanks again
Rik on 15 Nov 2020
Most graphics functions will return a handle. You can store those in an array and use that in your call to legend to make sure you only have the object in your legend that you want.
Regarding that 4th point: indexing with a calculated value has a potential for causing issues, because you need to guarantee that it will only return positive integers. It also prevents you from making changes like halving the step size if you want to make your calculation more granular.
You should not rely on the order that findall gives you the result. Store the handles when you create the objects, that way you have full control over the order.
David Goodmanson on 17 Nov 2020
Hi OI,
2. Don't know. I thought it might work to put yline(0) below the for loop, after all all the plotting was done, but that doesn't work either. The colors still work all right but something unexpected gets added to the legend. yline has a mind of its own.
3. I don't know why the order of line objects in h is the way it is, but Mathworks must have their reasons. See Rik.s comment on how to be sure of the order.
4. It's bad practice in general to use floating point numbers (such as .2) to construct integers, that's just basic computing 101. The code you have is
intsave = [];
for mu=0:.2:1
intger = 1+5*mu;
intsave = [intsave intger];
end
intsave
intsave = 1 2 3 4 5 6
So far so good. But you don't have to look very far at all for things to go awry. Try the same thing with an upper limit of 2:
intsave = [];
for mu=0:.2:2
intger = 1+5*mu;
intsave = [intsave intger];
end
intsave = Columns 1 through 6
1.0000 2.0000 3.0000 4.0000 5.0000 6.0000
Columns 7 through 11
7.0000 8.0000 9.0000 10.0000 11.0000
Right away you can see that something has gone wrong, and
intsave(7) -7
ans = 8.8818e-16
so of course using the would-be 7 as an integer index will not work.