bugGNU Octave - Bugs: bug #58216, bar: stacked bar chart improperly...

 
 

bug #58216: bar: stacked bar chart improperly handles negative values

Submitter:  Nicholas Jankowski <nrjank>
Submitted:  Mon 20 Apr 2020 04:16:48 PM UTC
   
 
Category:  Plotting Severity:  1 - Wish
Priority:  3 - Low Item Group:  Feature Request
Status:  Fixed Assigned to:  None
Originator Name:  Nicholas Jankowski Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 19 Nov 2020 06:21:54 PM UTC, comment #15: 

@Nicholas: I think that is an excellent idea.  Most of the graphics functions have %!demo blocks for testing which requires a human to do visual inspection to see if they look right.  This is tedious.

This is such a big project though that I think you should add it to the projects list (https://wiki.octave.org/Projects).  See the Test subsection.  Also, maybe mention something about it on Discourse in case there is some more useful input from other developers.

Rik <rik5>
Group administrator
Thu 19 Nov 2020 05:02:47 PM UTC, comment #14: 

One of those cases where the lack of actual output tests on some graphics objects can let things slip through. When I added the error checks I was wondering about ways to have actual BISTS for something like bar.  since bar just returns handles, could tests be made to probe some handle properties that would confirm proper bar values (size/shape/coordinates)? then something like the ypos/neg issue should trigger a failed test if it results in a malformed bar set.  I admit to not thinking too hard about it or whether tests of that type could introduce more problems than it solves, depending on how fragile relying on those properties was. But if that approach isn't bad, I assume it could apply to quite a number of functions. I could take a peek at such things if that would be worthwhile.

Nicholas Jankowski <nrjank>
Group Member
Thu 19 Nov 2020 04:33:06 PM UTC, comment #13: 

Thanks for catching that.  I did some editing on the original changeset and I re-defined ypos, yneg variables but also left in the original definition.  I fixed that here http://hg.savannah.gnu.org/hgweb/octave/rev/a0be96cd13c5.


Rik <rik5>
Group administrator
Thu 19 Nov 2020 03:27:01 PM UTC, comment #12: 

is this correct: http://hg.savannah.gnu.org/hgweb/octave/rev/d2f7fb06bce3

Because now y1p has the sum of squares of y>0 values, whereas in the else branch y1 has the sum of the y values.


    if (stacked && any (y(:) < 0))
      ypos = (y >= 0);
      yneg = (y <  0);
      ypos = y .* ypos;
      yneg = y .* yneg;

      y1p =  cumsum (y .* ypos, 2);
      y1n =  cumsum (y .* yneg, 2);


The original patch has the sum as well for y1p https://savannah.gnu.org/bugs/download.php?file_id=50291


+    if (stacked & (any (any (y < 0))))
+      ypos = y .* (y >= 0);
+      yneg = y .* (y < 0);
+
+      y1p =  cumsum (ypos, 2);
+      y1n =  cumsum (yneg, 2);
+      y1 = y1p .* (y >= 0) + y1n .* (y < 0);


A.R. Burgers <arb>
Thu 19 Nov 2020 04:25:34 AM UTC, comment #11: 

I made a few changes for efficiency such as using the short-circuit version '&&' rather than '&' and using 'any (y(:) < 0))' rather than 'any (any (y < 0)))'.  I checked in your patch here: http://hg.savannah.gnu.org/hgweb/octave/rev/d2f7fb06bce3.

Marking as fixed and closing report.

Rik <rik5>
Group administrator
Tue 17 Nov 2020 09:02:41 PM UTC, comment #10: 

Ok, I think this patch will correct the negative stacking issue. it separates the determination of patch y-values when 'stacked' and negative values are present, then recombines them so the rest of the processing can proceed unchanged.  this is done within _bar_.m so it fixes both bar and barh. 

There weren't any BISTS to verify that I didn't break anything else, but the demos still run and the test case below performs as it now should. I added input error-checking BISTS to both bar and barh and they both pass, and I added a demo to each that includes the negative values so the behavior is visibly obvious. Also made a note in the Matlab compatibility section of NEWS.

diff patch attached along with a zip containing modified bar.m, barh.m and /private/__bar__.m



(file #50291, file #50292)

Nicholas Jankowski <nrjank>
Group Member
Tue 21 Apr 2020 04:56:27 PM UTC, comment #9: 

the Preview thing is fairly new in savannah, and they have cleared a few other related bugs, so I did put in a support request about Preview clearing the Attached File fields (https://savannah.nongnu.org/support/?110225) . Not holding by breath, as there's another request about adding Preview to the initial submission page (https://savannah.nongnu.org/support/?109413), and that seems to be low priority wish-listed unless others jump on the Savannah support side. And apparently they even admit that setting up savannah PHP environment for debugging is a real chore.

Nicholas Jankowski <nrjank>
Group Member
Tue 21 Apr 2020 04:38:44 PM UTC, comment #8: 

Yes, that's right.  I have to attach the file, enter a comment using the syntax, and then hit "Submit Changes" button which uploads the file and records the message in the Discussion log.

Overall, Savannah is kind of clumsy compared to more modern programmer tools like Jira.

Rik <rik5>
Group administrator
Tue 21 Apr 2020 03:40:51 PM UTC, comment #7: 

(apparently it actually requires the file to be uploaded, and Preview clears the upload. moving on.)

Nicholas Jankowski <nrjank>
Group Member
Tue 21 Apr 2020 03:38:32 PM UTC, comment #6: 

THANK YOU.  is that in any of the savannah help? I spent 20 minutes looking around for that. maybe savannah should do GSOD.

file thank-you.jpg

okay. back on topic

Nicholas Jankowski <nrjank>
Group Member
Tue 21 Apr 2020 03:26:24 PM UTC, comment #5: 

Regarding your question about embedding an image in a Savannah bug report before the file ### is known, you can also use the file name and Savannah should place the image in to the comment.

Syntax: file file_name.png

Since you are the one uploading the file, you know the name even if you don't know what number will be assigned to it.


Rik <rik5>
Group administrator
Mon 20 Apr 2020 06:48:21 PM UTC, comment #4: 

Confirmed.  I agree that this is probably a "nice to have" feature which should get fixed at some point, but isn't absolutely critical as there is an easy workaround.

Rik <rik5>
Group administrator
Mon 20 Apr 2020 06:04:30 PM UTC, comment #3: 

correction - it is in the release notes with an example. I just missed it:

Bar Charts: Create bar charts with improvements for stacking and locating the tips of bars
   The bar and barh functions have these improvements:

   Stacked groups of bars display negative bars below zero, rather than overlapping the bars.


so apparently it applies to barh as well.
https://www.mathworks.com/help/releases/R2019b/matlab/ref/barh.html

Nicholas Jankowski <nrjank>
Group Member
Mon 20 Apr 2020 05:12:08 PM UTC, comment #2: 

from the mailing list:
"Apparently this was a change introduced in MATLAB 2019b, quoting from the release notes:

'Stacked groups of bars display negative bars below zero, rather than overlapping the bars.'"

(note that this does not seem to be in the currently published release notes on their website, despite numerous stackoverflow and mathworks discussions pointing to it. in any case, it's specifically mentioned in the current version help, so it seems to be a valid, intentional change.)

Nicholas Jankowski <nrjank>
Group Member
Mon 20 Apr 2020 04:23:20 PM UTC, comment #1: 

checking the matlab help [1] to see if this was expected or undocumented behavior, they to specifically state this as the expected behavior of the 'stacked' option with negative values.

[1] https://www.mathworks.com/help/matlab/ref/bar.html

Nicholas Jankowski <nrjank>
Group Member
Mon 20 Apr 2020 04:16:48 PM UTC, original submission:  

as reported on the mailing list [1], attempting to plot a stacked bar with negative values in the data array produces a plot where the negative element overlaps the rest of the data.  this behavior differs from Matlab which displays the 'expected' stacked bar with one value extending to the negative range.

E.g., the following all positive value input produces expected outputs identical in both programs except for a different colormap:


z = [1 2 3; 4 5 6];
h = bar (z, 'stacked');


see Stacked_allPos.PNG

however, the following does not:

z = [1 -2 3; 4 5 6];
h = bar (z, 'stacked');


see Stacked_oneNeg.PNG

Based on the color scheme, it appears that the Octave output creates the +1, then a negative two from the top of that (extending to -1) then a +3, with the final and only visible block going from -1 to 2. 

In Matlab 2020a, it produces a block from 0 to 1, a second block from 0 to -2, and a third block from 1 to 4.  It appears any negative values are treated as independent 'negative bars' starting from zero.  can confirm this with a


z=[1 -2 3 -4; 1 4 5 6];
h = bar (z, 'stacked');


see Stacked_twoNeg.PNG

where matlab has the 1 and 3 bars stacked on the positive side and the -2 and -4 bars stacked on the negative side, both extending from zero.

for the time being, a workaround was proposed that produces identical plots by holding the fig and issuing two bar commands:


z=[1 -2 3;  4 3 1]
zt = z;
zt(zt<0) = 0
h = bar (zt, 'stacked');
hold on
zt = z;
zt(zt>0) = 0
h = bar (zt, 'stacked');
hold off


see Stacked_workaround.PNG

See attached figures. (does anyone know how to embed an image in an initial report before a file # has been generated?)

[1] https://octave.1599824.n4.nabble.com/Stacked-bar-plot-with-positive-and-negative-values-tp4696772.html

Nicholas Jankowski <nrjank>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #50291:  fix_negative_stacked_bar.diff added by nrjank (4KiB - application/octet-stream - patched bar, barh, _bar_ to make negative stacking matlab compatible)
file #50292:  fixstackedbar.zip added by nrjank (8KiB - application/x-zip-compressed - patched bar, barh, _bar_ to make negative stacking matlab compatible)
file #48882:  Stacked_allPos.PNG added by nrjank (50KiB - image/png - images demonstrating stacked bar chart negative value incompatibilites)
file #48883:  Stacked_twoNeg.PNG added by nrjank (49KiB - image/png - images demonstrating stacked bar chart negative value incompatibilites)
file #48884:  Stacked_oneNeg.PNG added by nrjank (54KiB - image/png - images demonstrating stacked bar chart negative value incompatibilites)
file #48885:  Stacked_workaround.PNG added by nrjank (39KiB - image/png - images demonstrating stacked bar chart negative value incompatibilites)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by arb (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by nrjank (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 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-11-19 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2020-11-17 nrjank Attached File- Added fix_negative_stacked_bar.diff, #50291
        Attached File- Added fixstackedbar.zip, #50292
    2020-04-20 rik5 StatusNone Confirmed
        Release5.2.0 dev
    2020-04-20 jwe Severity3 - Normal 1 - Wish
        Priority5 - Normal 3 - Low
        Item GroupMatlab Compatibility Feature Request
    2020-04-20 nrjank Attached File- Added Stacked_allPos.PNG, #48882
        Attached File- Added Stacked_twoNeg.PNG, #48883
        Attached File- Added Stacked_oneNeg.PNG, #48884
        Attached File- Added Stacked_workaround.PNG, #48885

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code