Mon 26 Apr 2010 02:10:39 PM UTC, comment #9:
It would be relatively easy to make bar use the colororder property rather than the colormap. Just set the cdata properties to the value given by the next_line_color function. If cdata is a triplet this value is respected.
However, colororder by default has 7 colors defined and so consider
plotyy(1:10,1:10,1:10, rand(10,8), @plot, @bar)
The first and eigth bar will have the same color and the seventh the same color as the line. This is probably the main reason mathworks made the choice of using the colormap for bar plots as the colormap by default has 64 colors.
So I'd still consider this a bad idea
D.
|
Mon 26 Apr 2010 01:48:23 PM UTC, comment #8:
Okay, so the only solution then would be to rewrite the bar function itself to "respect the colororder property and just uses the default color for patches", right?
|
Mon 26 Apr 2010 12:45:33 PM UTC, comment #7:
The problem with special casing @bar in a plotyy command is, why should it behave differently in that case and that risks to be just as confusing. The bar function is the only 2D plot function that by default uses the colormap and so its the only function that has this issue
D.
|
Mon 26 Apr 2010 12:22:49 PM UTC, comment #6:
You are fully right about users not being grateful for the developers' efforts. And so I would like to thank all of you developing a free alternative to Matlab.
However, I think the current solution will confuse other users that run into the same problem as I did (which was what I meant with "not user friendly")
A proposal: Wouldn't it be possible to add a special case to plotyy method that checks if @bar is used and treats it accordingly? So there was no need to change bar function itself.
Please do not get frustated about bug reports! The only thing you can do with a bug report is to complain about things that do not work as expected.
As I am not actively involved in the development of Octave detailed bug reporting is my way to contribute and help improve this software.
Whatsoever you intend to do now, thank you for past and future efforts!
|
Mon 26 Apr 2010 11:21:41 AM UTC, comment #5:
What is "user friendly"? To which users should I be friendly.. You are one user there are many others who'd protest if
bar(rand(10,3))
colormap(summer())
no longer worked, which is what you are asking.. The bar plots use the figures colormap and that is compatible with matlab, I see no reason to take this further
About the only thing I suggest do in addition is to add an explanation to the help text like the attached.
BTW very very few users are developer friendly which is frankly much more important in my opinion as users of open source software are using the "gift" of those developers for free.
D.
(file #20334)
|
Mon 26 Apr 2010 09:55:37 AM UTC, comment #4:
I am sorry, but this is confusing me.
You closed this bug, confirmed the observed behavior, and provided a workaround, BUT it will not be implemented as default desired behavior??
So is this intended to confuse any user who tries such a plot for the first time and has to look for a workaround?
Does not sound very user friendly to me.
(Personally I would vote for reopening this bug.)
|
Sun 25 Apr 2010 06:39:55 PM UTC, comment #3:
Ok, I checked and by default the bar function uses the colormap and so doesn't use the colororder property and so the observed behavior is correct. You can force the color of the bar plot as suggested in my previous comment
D.
|
Fri 09 Apr 2010 11:47:11 PM UTC, comment #2:
plotyy does the following
colors = get (ax(1), "colororder");
set (ax(2), "colororder", [colors(2:end,:); colors(1,:)]);
such the the color order of the second axis is rotated by one... Pity that the bar function doesn't respect the colororder property and just uses the default color for patches... What does matlab do in this case. Perhaps the bar function also needs to use the colororder axis property for the color of the bars, though I seem to remember checking that matlab did it this way a few years back.
|
Tue 06 Apr 2010 04:49:16 AM UTC, comment #1:
This is confirmed on a Linux system runnig hg tip and gnuplot 4.2.5.
As a workaround, use the long form of plotyy and get the graphics handles for each of the two graphs. With these you can set the color to anything you desire.
For your example:
[ ax, h1, h2 ] = plotyy (x, y1, x - 1, y2, @plot, @bar);
set(h2,'facecolor', [1 0 0])
will set the second graph to be red (RGB = 100). For the bar graph you may also want to change the 'edgecolor' property.
|
Sat 03 Apr 2010 03:57:00 PM UTC, original submission:
The help entry for plotyy lists the following example which works as expected:
-----------
x = 0:0.1:2*pi;
y1 = sin (x);
y2 = exp (x - 1);
ax = plotyy (x, y1, x - 1, y2, @plot, @semilogy);
xlabel ("X");
ylabel (ax(1), "Axis 1");
ylabel (ax(2), "Axis 2");
-----------
When I change the plotyy line to use @bar as the second plot, like
ax = plotyy (x, y1, x - 1, y2, @plot, @bar);
the curves are correctly plotted, but the color of the second plot is blue instead of green!
|