Re: Problem with Ben's change to preserve axis propers when used with colorbars

[Ben Abbott]

On Thursday, October 16, 2008, at 03:50PM, "David Bateman" <address@hidden> 
wrote:
>John W. Eaton wrote:
>> On 16-Oct-2008, David Bateman wrote:
>> 
>> | John W. Eaton wrote:
>> | > It seems to work properly for me after the patch, though I find it
>> | > somewhat strange that
>> | >
>> | >   pcolor (peaks ()); colorbar ();
>> | >
>> | > produces the first attached plot.
>> | >
>> | > I would expect the colorbar to have the same height as the pcolor
>> | > plot.  It seems to work correctly for the contourf case as shown in
>> | > the second attached plot.
>> | >
>> | > Is this difference caused by splot vs. plot in gnuplot or is it
>> | > something that we could control without too much effort?
>> | >   
>> | Yes it is splot versus plot.. Basically the 3D plot from splot with the 
>> | view for pcolor is such that we can't control the size of the plot 
>> | correctly. I don't think there is much that we can do, if we keep the 
>> | pcolor as a surface plot with a particular view. Changing it to an image 
>> | would fix it, but wouldn't be compatible.
>> | 
>> | See as you say the patch is Ok, I just pushed it to Savannah.
>> 
>> OK, now I'm seeing the following error when I run the demo for
>> colorbar:
>> 
>>   colorbar example 13: failed
>>   binary operator `==' not implemented for `cell' by `matrix' operations
>> 
>> (this is just one of a number of demos that now fails).  Running the
>> example by hand, I see that the failure happens on the call to
>> subplot(2,1,2), at this point:
>> 
>>       objpos = get (child, "outerposition");
>>       if (objpos == pos)
>> 
>> The problem is that objpos at this point is the cell array
>> 
>>   {
>>     [1,1] =
>> 
>>        0   0   1   1
>> 
>>     [1,2] =
>> 
>>        0   0   1   1
>>   }
>> 
>> 
>> I don't know what the proper fix is.
>
>The issue is simple... The Children property of the axis changes from a 
>row vector to a column vector.. Look what happens when you do
>
>for i = [1,2]; disp("X:"); i, endfor
>
>ans compare to
>
>for i = [1;2]; disp("X:"); i, endfor
>
>I presume the children were made to be a column vector for 
>compatibility. So the question is, how does matlab treat the above two 
>cases. If it treats it the same as Octave, modifying the for loop in 
>subplot.m as
>
>for child = get (cf, "children")(:)'
>
>is the solution. Otherwise we need to modify the pt-loop.cc code to 
>handle column vectors correctly.
>
>Sorry I can't check the behavior of matlab.
>
>D.

I translated the Octave syntax to respect Matlab's. Running Matlab 2008a ..

>> for i = [1,2]; disp('X:'); i, end
X:

i =

     1

X:

i =

     2

>> for i = [1;2]; disp('X:'); i, end
X:

i =

     1
     2

Ben