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

 
 

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

Submitter:  Michael Duelli <duelli>
Submitted:  Sat 03 Apr 2010 03:57:00 PM UTC
   
 
Category:  Interpreter Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Other
Status:  Invalid / Not an Octave Bug Assigned to:  dbateman
Originator Name:  Open/Closed:  * Closed
Release:  * 3.2.4 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group Member
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>
Group Member
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>
Group Member
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>
Group Member
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>
Group Member
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>
Group 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 Files:
   
   
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
  • -email is unavailable- added by dbateman (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by duelli (Submitted the item)
  • -email is unavailable- added by duelli
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-04-26 dbateman Attached File- Added changeset.bar, #20334
    2010-04-25 dbateman StatusNeed Info Invalid / Not an Octave Bug
        Open/ClosedOpen Closed
    2010-04-09 dbateman StatusConfirmed Need Info
        Assigned toNone dbateman
    2010-04-06 rik5 Severity3 - Normal 2 - Minor
        Item GroupSegfault, Bus Error, etc. Other
        StatusNone Confirmed
    2010-04-03 duelli Carbon-Copy- Added duelli

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code