How Does SeriesIndex Work with LineStyleOrder?

My interpretation of SeriesIndex is that it controls the color and style of a line based on the ColorOrder and the LineStyleOrder properties of the axes.

figure;
ax = gca;
ax.LineStyleOrder = {'--x','--o','--*'};
get(gca,'LineStyleOrder')

ans = 3x1 cell array
    {'--x'}
    {'--o'}
    {'--*'}

plot(1:3,1:3,SeriesIndex=2),axis padded

I did not expect the line to be solid without a marker.

The LineStyleOrder has changed back to the default?

get(gca,'LineStyleOrder')

ans = '-'

It turns out that "hold" must be called after setting the LineStyleOrder and before the plot

figure;
ax = gca;
ax.LineStyleOrder = {'--x','--o','--*'};
hold on
plot(1:3,1:3,SeriesIndex=2),axis padded

ax.LineStyleOrder

ans = 3x1 cell array
    {'--x'}
    {'--o'}
    {'--*'}

Note: the line is '--x' because the default for LineCyclingMethod is 'aftercolor' (I think)

However, according to LineStyleOrder the need to call 'hold' prior to plot() should only apply for releases prior to 2019b.

Is the doc in error or am I misreading it?

[dpb]

I dunno for certain, but the note says "when you continue to plot in the axes" which to me implies that hold on must already be in place or the content of the axes will be reset.

If we try

hAx=axes;
hAx.NextPlot

ans = 'replace'

hAx.LineStyleOrder = {'--x','--o','--*'};

hAx.NextPlot

ans = 'replace'

we find that setting the LineStyleOrder does not change the state of .NextPlot I'm not sure the note applies or how else it would work without messing up what hold means royally and break a zillion working pieces of code.

I dunno what would happen (well, actually, I think I do have a pretty good guess <g>) if we tried

figure;
hAx=axes;
hAx.LineStyleOrder = {'--x','--o','--*'};
hAx.LineStyleOrderIndex=2;
plot(1:3,1:3)

Well, the color index was incremented but the line style still reverted to default...I'd say things there are still not working quite as may be intended.

I'll admit I've never tried to mess with the cycling order stuff other than specifically setting individual line properties via the lookup kind of thing of the other thread regarding markers...it's just too messy to fool with imo.

[Paul]

For context, the full note from the doc is:

"You can change the line style order before or after plotting into the axes.

When you set the LineStyleOrder property to a new value, MATLAB updates the styles of any lines that are in the axes. If you continue plotting into the axes, your plotting commands continue using the line styles from the updated list."

I don't intrepret "continue" in that last line as implying that "hold on" is already in effect. If I execute

plot(rand(3))
plot(rand(4))

the second plot() command continues plotting into the same axes created from the first plot command, regardless of the axes NexPlot plot property.

My interpretation of what that note is supposed to mean is that if make a plot, then change the LineStyleOrder, which is a property of the axes, then the lines already existing in the axes will be updated based on the new LineStyleOrder and any subsequent plots into the axes will use that LineStyleOrder (regardless of the NextPlot property).

[dpb]

But note in particular the "... MATLAB updates the styles of any lines that are in the axes. If you continue plotting into the axes, your plotting commands continue ..."

If 'NextPlot' is still 'replace', then there aren't going to be any lines to continue from, however. This is basically what your experiments have shown.

figure
plot(rand(3))
plot(rand(4))

plots iInto the same axes, yes, but with a big difference in behavior depending upon the state of 'NextPlot'.

My reading (and what is borne out by experiment) is that setting the order manually doesn't "stick" unless are already adding to the same axes, not replacing its content.

Now, as my comments went on to say, I can believe the observed behavior may not be exactly what MATHWORKS has intended, but it's such a messy, murky area, I doubt there is a truly clean solution with existing HG2 structure; too much is too intertwined.

I think unless one spends an inordinate amount of time digging into it, the only way to guarantee what you're going to get will be to take the old way out -- set the linestyle triad and order explicitly on the already existing lines or create them with the desired triad in the first place.

[Paul]

Yes, you are correct. If NextPlot is set to 'replace', then adding a new plot to the axes will

"Delete existing plots and reset axes properties, except Position and Units, to their default values before displaying the new plot."

So I guess everything is working as documented, even if the doc could be much more clear about this in the LineStyleOrder section.

[dpb]

I don't disagree about the doc with that new(ish at least) section regarding the order; it reads as if the writer of the documentation (who undoubtedly was not the developer) did expect the revised line order to begin with the value set, not connecting the behavior of HG2 with respect to what the 'NextPlot' property does.

Only that I knew already that unless 'NextPlot' is not 'replace' the axes properties are reset such that could check that setting the 'LineStyleOrder' did not also change its state was I able to infer that "continue" in that context had to imply that hold on had to have been executed in order to effect the described behavior with respect to continuation of the numbering sequence/style and that even if you were to change existing lines by the order vector index, unless hold on were set a new line would still reset the axes, wiping out the existing lines. From that I inferred the "continue" had to be in conjunction or the described behavior would not occur.

I wonder if, indeed, the intention with whatever was, specifically, changed in R2019b isn't actually implemented as what was intended or the explanation is just murky/garbled in not actually describing what the intended behavior is supposed to be.

It is probably worth a bug/support request asking for both clarification in intent/documentation if behavior is as intended or as a bug if it is really supposed to reset the order and not revert back to default when user does set an order vector -- or that it is, indeed, implied/required for the user to call hold on if wants the changed order to "stick".

Answer 1

[Sandeep Mishra]

Hi Paul,

I ran the provided code snippet and observed the similar results.

I found a way to set the ‘LineStyleOrder’ property of the axes without using the ‘hold’ function to get the desired result. You can set the property using the following code snippet:

% Setting LineStyleOrder property for 'ax' axis
ax.LineStyleOrder = linestyleorder({'--x','--o','--*'}); 

This method should allow you to set the ‘LineStyleOrder’ of the axes and achieve the expected result.

Please refer to the below documentation for more information on ‘linestyleorder’ property: https://www.mathworks.com/help/releases/R2024a/matlab/ref/linestyleorder.html

I hope this helps!

[dpb]

hAx=axes;
hAx.LineStyleOrder = linestyleorder({'--x','--o','--*'}); 
hAx.NextPlot

ans = 'replace'

plot(rand(4,1))

Indeed. Never lead to that in the general documentation that a new method/function was introduced; the description elsewhere should be revised to mention that is a requirement to make it work.

Mathworks can make magic happen by having access to the internals to change things behind the scenes; but it would still appear the changes are as described this way only beginning with R2024a when the function was introduced.

[Paul]

@Sandeep Mishra

Thanks for finding this new function linestyleorder that was added in 2024a.

Just want to point out that linestyleorder can be used just like xlim (for example) in that there is no need to explictly assign its output to the axis property. It automagically sets the LineStyleOrder of all of the axes in the current figure (or one can specify a specific target as a first argument).

figure
hAx=axes;
linestyleorder({'--x','--o','--*'}); 
plot(rand(4,1))

hAx.LineStyleOrder

ans = 3x1 cell array
    {'--x'}
    {'--o'}
    {'--*'}

At first I was confused by the statement on the doc page "linestyleorder(linestyles) sets the line style order for the current figure." insofar as LineStyleOrder is a property of an axis. Then I realized it probably meant to refer to the children of the current figure, and it should also say "sets the default line style order for the current figure." (see discussion below).

figure
hax1 = subplot(211);
hax2 = subplot(212);
linestyleorder({'--x','--o','--*'});
plot(hax1,rand(4,1))
plot(hax2,rand(4,1))

linestyleorder is an ordinary m-file (and not very long) so I took a look to see why it works differently and makes the LineStyleOrder "stick" when NextPlot == 'replace'. It looks like (and I could be wrong) that if the target input is not specified (or presumably specified as a figure), then linestyleorder sets the DefaultLineStyleOrder at the figure level (in addition to setting the LineStyleOrder of any applicable children that currently exist in the figure). I think it's the Default property at the figure level that makes the behavior "sticky" and operate across all subplot axee as shown above.

However, we don't get "stickiness" if we explicitly specify an axis as the target.

figure
hAx=axes;
linestyleorder(hAx,{'--x','--o','--*'}); 
plot(rand(4,1))

hAx.LineStyleOrder

ans = '-'

So I guess this case is equivalent to where this all started, i.e.,

%hAx.LineStyleOrder = {'--x','--o','--*'};

[dpb]

@Paul, thanks for the additional input/testing/spelunking. For various reasons, I'm still using R2021b here and haven't taken the time to install a later version (given the slow bandwidth of connections in rural America, it takes in the hours time frame any more with the explosion in size and with no automagic restart, it's a far thing from certain it will complete the first time).