bugGNU Octave - Bugs: bug #65659, single bar plots wider than...

 
 

bug #65659: single bar plots wider than multi-bar plots unlike matlab

Submitter:  Hartmut <hardy>
Submitted:  Mon 29 Apr 2024 01:54:40 PM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * 9.1.0 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 29 Apr 2024 09:17:57 PM UTC, comment #7: 

created bug #65661 wishlist item to address a feature add to enable controlling individual bar colors like matlab can currently do.

Nicholas Jankowski <nrjank>
Group Member
Mon 29 Apr 2024 06:45:32 PM UTC, comment #6: 

confirming that (at first glance) our bar objects don't support the same color options as matlab's. (as with many other graphics objects, matlab has implemented separate object types for these things, in this case a 'bar object' is return that appears to be a subclass of a patch object with a few new bar features.)

Each set of bars uses a single color value, and our hggroup doesn't inherit the properties from patch objects to create multiple colors. It only gets 'facecolor' and 'edgecolor'.  With patches, those can either take colorspecs or other values that tell it to look for color data in other properties (cdata, facevertexcdata, etc.).

While the long range plan would be to support compatible 'bar objects', a nearer term wish list item could be to upgrade bargroup objects to also inherit the cdata and/or facevertexcdata properties to enable more compatible color control. (if no one else gets there first, i may create a wish list bug report for that)

Nicholas Jankowski <nrjank>
Group Member
Mon 29 Apr 2024 06:05:47 PM UTC, comment #5: 

if you try to do the same overlapping plot trick, but don't use default 1:N x values for bar centers, matlab also does not automatically match bar widths. 

data = [10 2 10 10 10];
bar (2:2:10, data);
hold on;
bar (4, data(2))

produces a plot where the first set has a width chosen to fill 'nicely', resulting in wider bars. the overlaying second bar plot uses matlab's default normal width for 1:N spacing, making the second bar narrower than the others.

So, compatibility doesn't dictate that the plot needs to somehow know what the previous plot's bar settings were when hold is on. It just appeared that way based on the first test case.

so:

1) i'm going to retitle and recategorize this.  it seems this just happened to tease out the fact that our single bar plots use wider bars than multi-bar plots, unlike matlab which uses the same width as for 1:N centered plots (reproducible in our code with a 'cutoff' value of 0.5 not 1)

2) As this also appeared in a matlab discussion where the 'overlapping plots' idea was proposed but described as nonideal, it's worth noting that most of the other solutions were based on setting the cdata value for the plot. possible that could work here, but our object properties might not work exactly the same.  may be worth taking that discussion over to discourse.


Nicholas Jankowski <nrjank>
Group Member
Mon 29 Apr 2024 05:44:13 PM UTC, comment #4: 

so arbitrarily forcing cutoff there to 0.5 instead of 1 makes the figures overlap like matlab.  this does change the single bar width  even when plotted by itself.  I was concerned that would create an incompatibility, when I checked and saw that matlab also uses the same size bar width for single bar plots as multiple plots.  Forcing the 'cutoff' parameter to 0.5 also makes those plots matlab compatible in bar width, whereas now they're too wide.  I had assumed the comment/explanation above that section meant it was chosen for compatibility, but maybe not (unless that has changed with versions). 

the only problem in setting a single bar plot to a 0.5 'cutoff' is that the resulting narrower bar (from x=1.6 to 2.4 in this case) somehow results in the plot not being centered. it chooses x=1.6 as the left xlim.

Nicholas Jankowski <nrjank>
Group Member
Mon 29 Apr 2024 05:19:28 PM UTC, comment #3: 

correction - nbars is the number of separate data sets, and both should have the same cwidth, gwidth.  the problem is later when those values are used to set bar dimensions based, specifically the 'cutoff' value which is illdefined.

Nicholas Jankowski <nrjank>
Group Member
Mon 29 Apr 2024 03:33:34 PM UTC, comment #2: 

it looks like some of the things we do for compatibility with single bar plot dimensions collide with this use case. in `__bar__.m` the default bar size is set to 0.8, but down below:

  elseif (nbars == 1)
    cwidth = 1;
    gwidth = width;
  else
    cwidth = gwidth = width;
  endif

so for 1 bar cwidth gets widened to 1. for multi-bar graphs it stays at 0.8.  if you try to superimpose two bar plots it's fine:

data = [10 2 10 10 10];

bar(data)
hold on
bar([1,2], data([1,2]))

need to look at what cases that wider width needs to be preserved, and how octave might be able to tell (maybe from ishold?) that it needs to stay at 0.8.

Nicholas Jankowski <nrjank>
Group Member
Mon 29 Apr 2024 03:14:18 PM UTC, comment #1: 

i can confirm on 9.1 and the dev branch. need to look into how bar calculates the bar width in the second case and why it doesn't match the widths of the first case.

Nicholas Jankowski <nrjank>
Group Member
Mon 29 Apr 2024 01:54:40 PM UTC, original submission:  

I have observed the following akward behavior of the bar plot command in Octave. I run the following demo code:


clear, close all

data = [10 2 10 10 10];

bar(data)
hold on
bar(2, data(2))


And I get a figure with a bar plot, where the second bar has a much bigger width compared to the other four bars in the plot. This second bar even covers some of its two neighboring bars.

I consider this imperfect plotting behavior of Octave, especially because in Matlab the same code gives me a plot with five nice bars of the very same width.

Hartmut <hardy>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by hardy (Submitted the item)
  •  

    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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-04-29 nrjank Item GroupInaccurate Result Matlab Compatibility
        Summaryadditional bar in bar plot has wrong width (using hold on) single bar plots wider than multi-bar plots unlike matlab
    2024-04-29 nrjank CategoryOctave Function Plotting
        StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code