Sun 12 Mar 2017 08:13:31 PM UTC, comment #9:
Executing the test code from comment #3 in Matlab R2016a yields "plot command resets axes" with a blue line.
Since this is also the same behaviour as described by the original reporter and in other comments, closing report as invalid.
The slightly modified code from comment #0 that produces the output with the colororder as expected by the OR:
|
Sun 12 Mar 2017 07:08:49 PM UTC, comment #8:
Octave is designed to run Matlab scripts without modification. The Mathworks has defined how the "ColorOrder" property is to be implemented. You might not like their specification, but it is their language to do with as they please. Unless Octave is incompatible, for example the test code from comment #3 produces a different result when run under Matlab, then I don't see a bug here.
|
Sun 12 Mar 2017 06:35:17 PM UTC, comment #7:
So, are you saying that it is alright that set(gca,"colororder",CO) never does anything unless the defaults are changed or the "NextPlot" property is set to "replacechildren", and only then?
So, you are ok with this
producing a plot with the default colororder (see attached picture). So, the get property gets the misleading gray() colororder, which doesn't reflect the actual graphic.
Note how set xtick worked as expected, but the colororder property did not. If this is the expected behaviour, then your expectation is incorrect. Some consistency should apply with these settings.
I will include an updated testcase and results.
(file #39979, file #39980)
|
Fri 10 Mar 2017 11:06:49 PM UTC, comment #6:
Check the documentation for colororder carefully. It is doing what is documented.
|
Fri 10 Mar 2017 08:33:09 PM UTC, comment #5:
Setting:
is a workaround.
But, it should also work without changing the defaults. So there is incorrect behaviour here. Either plot() then set() should do it or the other way around, neither does.
When you changed the status to "Works For Me" did you actually check the colour of the lines?
|
Fri 10 Mar 2017 08:21:22 PM UTC, comment #4:
Well, I tried to change the order (before I posted this bug).
Plotting first, then changing the colororder property has no effect on the plot. Issuing a command like ylim(), that could potentially cause the plot to update, doesn't help with the colors.
But, setting the colororder after plot() will make my little if statement go to printing the "colororder worked." line.
The plot does not change however.
Update: I also tried it with octave 4.2.0 on Gentoo Linux, same problem in both cases. So, it doesn't seem to be my specific build.
So, in summary:
plot() then set(gca,'colororder',CO); does not change the plot.
@rik5: doesn't your test-code show that my proposed order is correct?
I see
So, this property is supposed to be set before plotting.
And, besides, I think that it should work either way, ideally. But, I'd be content if one of the orders worked.
|
Fri 10 Mar 2017 07:55:31 PM UTC, comment #3:
Are you sure this isn't the correct behavior? See the equivalent ColorOrder property for Matlab at http://www.mathworks.com/help/matlab/ref/axes-properties.html.
The ColorOrder property belongs to the current axes. If you issue a new plot command the old axes gets reset. If you want a persistent colororder you can either use 'hold on' for an individual figure, or 'set (0, "DefaultAxesColorOrder", ...) to set a global default.
Test code for both Octave and Matlab:
|
Fri 10 Mar 2017 07:10:48 PM UTC, comment #2:
Oh wait. This may be proper behavior. I think "plot" resets almost everything and modifications have to come after the plot command. Isn't that the standard concept? Or maybe it doesn't apply for some features like color maps, don't know. Or, there might be some global settings via the special plot handle 0. Sometimes
set(0, ...)
does some magic stuff.
|
Fri 10 Mar 2017 07:06:38 PM UTC, comment #1:
If you are building from source, the easiest way to locate the pertinent code or script is to use "grep". First, keep your build directory separate from the source tree (see "configure" etc.). Then, go to root of the source tree and try:
until something useful seems to appear. Having done that here, it looks to me that none of the scripts (i.e., .m files) set colororder at a base level (there are plenty of demo scripts that call the "set('colororder')" command). So it must be C++ code:
Locating the source of the issue isn't a precise process.
|
Fri 10 Mar 2017 06:48:29 PM UTC, original submission:
ColorOrder
a set colororder property is reset when plot() is called.
It is a freshly compiled octave-4.2.1
Example
produces the output:
and of course a plot with default colours.
Further Information
There was this bug [bug #39291](https://savannah.gnu.org/bugs/?func=detailitem&item_id=39291) for an older version and different OS, so it's probably a different thing.
where could I possibly begin to investigate why that is?
This is also happening in Ubuntu's build of Octave 4.0.3, so it is probably unrelated to the change of the default colors.
|