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