bugGNU Octave - Bugs: bug #43468, Bug in bar plot data update in...

 
 

bug #43468: Bug in bar plot data update in Octave 3.8.1

Submitter:  None
Submitted:  Fri 24 Oct 2014 10:26:55 AM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Ian Flintoft Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.8.1
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 28 Oct 2014 03:13:19 PM UTC, comment #7: 

Thanks for testing.  I applied the patch to the stable branch of octave here (http://hg.savannah.gnu.org/hgweb/octave/rev/f96495e88a70).  This will be a part of the next bug fix release of Octave 3.8.3 or more likely we will skip directly to Octave 4.0.

Rik <rik5>
Group administrator
Tue 28 Oct 2014 10:15:42 AM UTC, comment #6: 


Many thanks. This indeed fixes the problem for the simple examples in the bug report and for the actual GA code which first detected the issue.

Ian Flintoft <idflintoft>
Mon 27 Oct 2014 04:34:29 PM UTC, comment #5: 

Thanks.  Marking this bug as confirmed.  The fix will need to be in the m-file scripts/plot/draw/private/__bar__.m.  This is the private function which actually implements bar() or barh().

At the start of the function any vectors present as inputs are made column vectors.  See the code from line 59 below which applies to the examples used in this bug report.


y = varargin{1};
if (isvector (y))
  y = y(:);
endif


Unfortunately, this is going to be awkward to solve (i.e, it's going to require a bunch of special purpose code and if/thens).  The issue is that normally a second column, as in matrix input, indicates a second bar to plot rather than just a second point for a single bar color.  If you try


bar (ones (2,4))


you will see that this plots 4 colored bars at two locations.  So it is very natural to turn a row vector input into a column vector and then pass that to the routine which plots matrices.

I've made a small change which allows ydata to be set as a row vector, although internally it still transforms it to a column vector.  I think this may be a good enough fix rather than trying to code support for row vectors.

I've attached the patch and you can try it out on an existing installation since it only affects an m-file, not any compiled code.


(file #32325)

Rik <rik5>
Group administrator
Mon 27 Oct 2014 03:41:04 PM UTC, comment #4: 


No problem:

>> data = ones (1,4);

hl = bar (data);
y = get (hl, 'YData')
size (y)

y =

     1     1     1     1


ans =

     1     4

Ian Flintoft <idflintoft>
Mon 27 Oct 2014 03:28:31 PM UTC, comment #3: 

Bother.  They probably do have an exception.  Can you try one last test under Matlab?  I want to see whether Octave should handle the exception in the m-file or in the C++ rendering code.


data = ones (1,4);
hl = bar (data);
y = get (hl, 'YData')
size (y)


Rik <rik5>
Group administrator
Mon 27 Oct 2014 09:10:56 AM UTC, comment #2: 


    In MATLAB R2013b the help says

"For vector inputs, bar(X,Y) or bar(Y) draws LENGTH(Y) bars."

For the previous example (but not using random data so I can be sure it's working) in MATLAB R2013b:

>> genotype=ones(4,1)


genotype =

     1
     1
     1
     1

>> hl = bar(genotype)


hl =

  174.0016

>> genotype=2.*ones(4,1)


genotype =

     2
     2
     2
     2

>>  set (hl, 'YData', genotype);


Updates as expected.

>> genotype=ones(1,4)


genotype =

     1     1     1     1

>> hl = bar(genotype)


hl =

  174.0022

>> genotype=2.*ones(1,4)


genotype =

     2     2     2     2

>> set (hl, 'YData', genotype);


Also updates as expected.

Looks like vectors are special-cased to work the same reqardless
of whether they are row or column vvectors.

Ian Flintoft <idflintoft>
Sat 25 Oct 2014 05:24:46 PM UTC, comment #1: 

Do you have access to Matlab, and could you check the corresponding code there?

I think this change was made in Octave for Matlab compatibility.  According to their documentation


The bar function treats all vectors as column vectors.


So, Octave is taking the row vector and making it a column vector before proceeding with the plot.

Rik <rik5>
Group administrator
Fri 24 Oct 2014 10:26:55 AM UTC, original submission:  


Hi,

I am using Octave 3.8.1, Ubuntu 14.04.1 LTS, fully patched, 64-bit, distribution package.

Should the shape of 1D data (i.e row or column vector) passed to bar make a difference to updates using set?


This works OK:

  octave:1> genotype=rand(4,1)
  genotype =

     0.71002
     0.35112
     0.11692
     0.86428

  octave:2> hl = bar(genotype)
  hl = -17.264
  octave:3> genotype=rand(4,1)
  genotype =

     0.45987
     0.25877
     0.63505
     0.96748

octave:4>  set (hl, 'YData', genotype);


This fails:

  octave:5> genotype=rand(1,4)          
  genotype =

     0.47919   0.40458   0.93713   0.17101

  octave:6> hl = bar(genotype)          
  hl = -15.355
  octave:7> genotype=rand(1,4)          
  genotype =

     0.868794   0.187961   0.571303   0.023557

  octave:8>  set (hl, 'YData', genotype);
  error: update_data: A(I): index out of bounds; value 2 out of bound 1
  error: called from:
  error:   /usr/share/octave/3.8.1/m/plot/draw/private/__bar__.m at line 445, column 12


In both cases the shape of the data is the same for the initial call to bar and the update. I'm using this down at a low level in a genetic algorithm code which used to work fine but doesn't like Octave 3.8.1. Not sure at what point this changed because
I haven't used the code for some time - certainly it was OK in 3.6.x series Octave when I developed the code.

The line which fails is * below

      for i = 1:columns (y)

  •        hp = get (hlist(i), "children");

        if (vertical)
          set (hp, "xdata", xb(:,:,i), "ydata", yb(:,:,i));
        else
          set (hp, "xdata", yb(:,:,i), "ydata", xb(:,:,i));
        endif
      endfor
     
So presumably i is going beyond the end of hlist.

FYI, the "other code implementation" works in both cases.

It tried copying _bar_.m from 3.8.2 into my 3.8.1 distribution
but I still get the same error.

Best Regards,

Ian

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #32325:  bar_ydata.cset added by rik5 (808B - 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 idflintoft (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by None (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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-10-28 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2014-10-27 rik5 StatusConfirmed Ready For Test
    2014-10-27 rik5 Attached File- Added bar_ydata.cset, #32325
        StatusNeed Info Confirmed
    2014-10-25 rik5 StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code