setting axis limits weirdness

Ben Abbott benjamin.abbott at tqs.com
Tue Sep 23 10:37:54 CDT 2008


On Sep 22, 2008, at 10:56 PM, John W. Eaton wrote:

> On 22-Sep-2008, Ben Abbott wrote:
>
> |
> | On Sep 22, 2008, at 8:55 PM, John W. Eaton wrote:
> |
> | > On 22-Sep-2008, Ben Abbott wrote:
> | >
> | > | Is it possible to capture the commands going to gnuplot so  
> that I
> | > may
> | > | verify them, and conveniently submit a bug to gnuplot?
> | >
> | > Something like
> | >
> | >  somebrero (); drawnow ("aqua", "/dev/null", false, "debug.gp");
> | >
> | > should dump the commands for the sombrero plot to the file  
> "debug.gp".
> | >
> | > jwe
> |
> | oh-oh ... I ran the commands below from a file
> |
> | 	clf
> | 	clear all
> | 	x = [-0.1, 1.0];
> | 	y = [-0.7, 0.7];
> | 	h = plot (x, y);
> | 	set (gca, 'xlim', x);
> | 	set (gca, 'ylim', y);
> | 	xlimits = get (gca, 'xlim')
> | 	ylimits = get (gca, 'ylim')
> | 	drawnow ("aqua", "/dev/null", false, "debug.gp")
> |
> | and found the lines below in debug.gp
> |
> | 	set xrange [-2.000000000000000e-01:1.000000000000000e+00]  
> noreverse;
> | 	set yrange [-8.000000000000000e-01:8.000000000000000e-01]  
> noreverse;
> |
> | The entire debug.gp is attached.
> |
> | As a quick check I tried
> |
> | 	export GNUTERM=x11
> | 	gnuplot -persist debug.gp
> |
> | I got the x11 window with the same result as the aqua variant  
> produced
> | from octave.
> |
> | Further (I'm a bit slow) I tried 3.01 and 3.02, each produce the
> | proper result with both aqua and x11. I verified they are each  
> seeing
> | the same gnuplot binary.
> |
> | In any event, I must be in need of some sleep ... I just tested the
> | x11 terminal again and am now getting the same result as with  
> aqua ...
> | perhaps when I tried that before, I'd not run that from 3.1.51 but
> | from 3.0.1 or 3.0.2?
>
> You can demonstrate the problem with
>
>  x = [-0.1, 1.0];
>  y = [-0.7, 0.7];
>  figure (1, 'visible', 'off');
>  h = plot (x, y);
>  set (gca, 'xlim', x);
>  set (gca, 'ylim', y);
>  xlimits = get (gca, 'xlim')
>
> so the problem is independent of the terminal type used.
>
> The problem seems to be this code in
> axes::properties::calc_ticks_and_lims in graphics.cc:
>
>  if (limmode_is_auto)
>    {
>      // adjust limits to include min and max tics
>      Matrix tmp_lims (1,2);
>      tmp_lims(0) = tick_sep * i1;
>      tmp_lims(1) = tick_sep * i2;
>
>      if (is_logscale)
> 	{
> 	  tmp_lims(0) = std::pow (10.,tmp_lims(0));
> 	  tmp_lims(1) = std::pow (10.,tmp_lims(1));
> 	}
>      lims = tmp_lims;
>    }
>  else
>    {
>      // adjust min and max tics if they are out of limits
>      i1 = static_cast<int> (std::ceil (lo / tick_sep));
>      i2 = static_cast<int> (std::floor (hi / tick_sep));
>    }
>
> This function is called when xlim is set, and at this point,
> limmode_is_auto is false.  The value of tick_sep is calculated to be
> 0.2, so the effect of this is to adjust the lower limit to -0.2.  I
> don't understand why this function is doing anything when limmode is
> manual.  Perhaps Michael can comment.
>
> jwe

hmmm ...

I notice that a subsequent attempt to set the limits does work.

  x = [-0.1, 1.0];
  y = [-0.7, 0.7];
  figure (1, 'visible', 'off');
  h = plot (x, y);
  set (gca, 'xlim', x);
  set (gca, 'ylim', y);
  set (gca, 'xlim', x);
  set (gca, 'ylim', y);
  xlimits = get (gca, 'xlim')

Looks like the limmode is switching to manual a bit late.

Did you intend to copy Michael on the prior email?

Ben






More information about the Bug-octave mailing list