bugGNU Octave - Bugs: bug #29431, Wrong colors with plotyy when...

 
 

bug #29431: Wrong colors with plotyy when using @bar as second plot

Submitted by:  Michael Duelli <duelli>
Submitted on:  Sat 03 Apr 2010 03:57:00 PM UTC  
 
Category: InterpreterSeverity: 2 - Minor
Priority: 5 - NormalItem Group: Other
Status: InvalidAssigned to: David Bateman <dbateman>
Originator Name: Open/Closed: Closed
Release: 3.2.4Operating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

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.

David Bateman <dbateman>
Project MemberIn charge of this item.
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?

Michael Duelli <duelli>
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.

David Bateman <dbateman>
Project MemberIn charge of this item.
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!

Michael Duelli <duelli>
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)

David Bateman <dbateman>
Project MemberIn charge of this item.
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.)

Michael Duelli <duelli>
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.

David Bateman <dbateman>
Project MemberIn charge of this item.
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.

David Bateman <dbateman>
Project MemberIn charge of this item.
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.

Rik <rik5>
Project Administrator
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!

Michael Duelli <duelli>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #20334:  changeset.bar added by dbateman (200B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by dbateman (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by duelli (Submitted the item)
  • -unavailable- added by duelli
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 26 Apr 2010 11:21:41 AM UTCdbatemanAttached File-=>Added changeset.bar, #20334
    Sun 25 Apr 2010 06:39:55 PM UTCdbatemanStatusNeed Info=>Invalid
      Open/ClosedOpen=>Closed
    Fri 09 Apr 2010 11:47:11 PM UTCdbatemanStatusConfirmed=>Need Info
      Assigned toNone=>dbateman
    Tue 06 Apr 2010 04:49:16 AM UTCrik5Severity3 - Normal=>2 - Minor
      Item GroupSegfault, Bus Error, etc.=>Other
      StatusNone=>Confirmed
    Sat 03 Apr 2010 03:57:00 PM UTCduelliCarbon-Copy-=>Added duelli

    Back to the top


    Powered by Savane 3.1-cleanup1