setting axis limits weirdness

[Ben Abbott]

Bug report for Octave 3.1.51+ configured for i386-apple-darwin

Description:
-----------

* Running the default branch on Mac OSX 10.5.5 with GNUTERM="aqua",
I've discovered
a strange problem. In some special cases I'm unable to set the axis
using either
the 'axis' command, 'xlim'/'ylim' commands, or 'set (gca, ...)'.
However, if I attempt
to set the axis limits a second time, using any of these options, it
works. In the
event I choose to use the x11 terminal, then everything works as it
should.

The common denominator appears to be set(gca,'xlim',xlimits) and/or
set(gca,'ylim',ylimits).

Repeat-By:
---------

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')
xlimits =

-0.20000 1.00000

ylimits = get (gca, 'ylim')
ylimits =

-0.80000 0.80000

Fix:
---

* Thus far, I've not found the root of the problem ... I'm a c++
lacky ;-)

Configuration (please do not edit this section):
-----------------------------------------------

uname output: Darwin bens-macbook.local 9.5.0 Darwin Kernel
Version 9.5.0: Wed Sep 3 11:29:43 PDT 2008; root:xnu-1228.7.58~1/
RELEASE_I386 i386
configure opts: '--prefix=/sw' 'FLIBS=/sw/lib/gcc4.3/lib/
libgfortran.dylib' 'F77=/sw/bin/gfortran' '--host=i386-apple-darwin'
'--infodir=/sw/share/info' '--mandir=/sw/share/man' '--libexecdir=/sw/
lib' '-enable-shared' '-enable-dl' '--disable-static' '--without-mpi'
'--with-hdf5' '--with-fftw' '--with-lapack=-Wl,-framework,Accelerate,-
dylib_file,/System/Library/Frameworks/Accelerate.framework/Versions/A/
Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib:/System/Library/
Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/
Versions/A/libLAPACK.dylib' '--with-blas=-Wl,-framework,Accelerate,-
dylib_file,/System/Library/Frameworks/Accelerate.framework/Versions/A/
Frameworks/vecLib.framework/Versions/A/libBLAS.dylib:/System/Library/
Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/
Versions/A/libBLAS.dylib' 'host_alias=i386-apple-darwin' 'CFLAGS=-O3'
'LDFLAGS=-L/sw/lib' 'CPPFLAGS=-I/sw/include' 'CXXFLAGS=-O3' 'FFLAGS=-O3'
Fortran compiler: /sw/bin/gfortran
FFLAGS: -O3 -mieee-fp
F2C: @F2C@
F2CFLAGS: @F2CFLAGS@
FLIBS: /sw/lib/gcc4.3/lib/libgfortran.dylib
CPPFLAGS: -I/sw/include -I/sw/include
INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler: gcc, version 4.0.1 (Apple Inc. build 5465)
CFLAGS: -O3
CPICFLAG: -fPIC
C++ compiler: g++, version 4.0.1
CXXFLAGS: -O3
CXXPICFLAG: -fPIC
LD_CXX: g++
LDFLAGS: -L/sw/lib
LIBFLAGS: -L.
RLD_FLAG:
BLAS_LIBS:
FFTW_LIBS: -lfftw3 -lfftw3f
LIBS: -lreadline -lncurses -Wl,-framework,Accelerate,-
dylib_file,/System/Library/Frameworks/Accelerate.framework/Versions/A/
Frameworks/vecLib.framework/Versions/A/libBLAS.dylib:/System/Library/
Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/
Versions/A/libBLAS.dylib -lhdf5 -lz -lm
LEXLIB:
LIBGLOB:
SED: /sw/bin/sed
DEFS:

-DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION=""
-DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -
DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -
D__EXTENSIONS__=1
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1
-D_TANDEM_SOURCE=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1
-D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -D__EXTENSIONS__=1
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1
-D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -
D__NO_MATH_INLINES=1
-DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1
-DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1
-DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1
-DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_H=1
-DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_OPENGL_GL_H=1
-DHAVE_OPENGL_GLU_H=1 -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1
-DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _
-DHAVE_SUITESPARSE_AMD_H=1 -DHAVE_AMD=1 -
DHAVE_SUITESPARSE_UMFPACK_H=1
-DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -
DHAVE_SUITESPARSE_COLAMD_H=1
-DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1
-DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -
DHAVE_SUITESPARSE_CS_H=1
-DHAVE_CXSPARSE=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -
DHAVE_DEV_T=1
-DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -
DHAVE_LONG_LONG_INT=1
-DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -
DHAVE_SIG_ATOMIC_T=1
-DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8
-DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1
-DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1
-DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1
-DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1
-DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -
DHAVE_LOCALE_H=1
-DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -
DHAVE_PTHREAD_H=1
-DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1
-DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1
-DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1
-DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1
-DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CHMOD=1
-DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1
-DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1
-DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1
-DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -
DHAVE_GETPGRP=1
-DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1
-DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1
-DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1
-DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1
-DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_PIPE=1
-DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1
-DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1
-DHAVE_ROUND=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1
-DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -
DHAVE_SIGLONGJMP=1
-DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1
-DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1
-DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1
-DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMA=1
-DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1
-DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1
-DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -
DHAVE_STRFTIME=1
-DHAVE_DYLD_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1
-DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1
-DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1
-DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1
-DHAVE_ERFF=1 -DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2=1 -
DHAVE_EXP2F=1
-DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1
-DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1
-DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -
DHAVE_TM_ZONE=1
-DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void
-DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -
DRETSIGTYPE_IS_VOID=1
-DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1

User-preferences (please do not edit this section):
--------------------------------------------------

EDITOR = mate
EXEC_PATH = /sw/lib/octave/3.1.51+/site/exec/i386-apple-darwin:/sw/
lib/octave/api-v33+/site/exec/i386-apple-darwin:/sw/lib/octave/site/
exec/i386-apple-darwin:/sw/lib/octave/3.1.51+/exec/i386-apple-darwin:/
sw/bin:/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/
usr/X11/bin:/usr/X11R6/bin
IMAGE_PATH = .:/sw/share/octave/3.1.51+/imagelib
PAGER = less
PS1 = \s:\#>
PS2 = >
PS4 = +
beep_on_error = 0
completion_append_char =
crash_dumps_octave_core = 1
echo_executing_commands = 0
fixed_point_format = 0
gnuplot_binary = gnuplot
# gnuplot_command_end = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
history_file = /Users/bpabbott/.octave_hist
history_size = 1024
ignore_function_time_stamp = system
info_file = /sw/share/info/octave.info
info_program = info
makeinfo_program = makeinfo
max_recursion_depth = 256
output_max_field_width = 5
output_precision = 5
page_output_immediately = 0
page_screen_output = 1
# print_answer_id_name = <no value or error in displaying it>
print_empty_dimensions = 1
save_precision = 16
saving_history = 1
sighup_dumps_octave_core = 1
sigterm_dumps_octave_core = 1
silent_functions = 0
split_long_rows = 1
string_fill_char =
struct_levels_to_print = 2
suppress_verbose_help_message = 0

[John W. Eaton]

On 22-Sep-2008, Ben Abbott wrote:

| Bug report for Octave 3.1.51+ configured for i386-apple-darwin
|
| Description:
| -----------
|
| * Running the default branch on Mac OSX 10.5.5 with GNUTERM="aqua",
| I've discovered
| a strange problem. In some special cases I'm unable to set the axis
| using either
| the 'axis' command, 'xlim'/'ylim' commands, or 'set (gca, ...)'.
| However, if I attempt
| to set the axis limits a second time, using any of these options, it
| works. In the
| event I choose to use the x11 terminal, then everything works as it
| should.
|
| The common denominator appears to be set(gca,'xlim',xlimits) and/or
| set(gca,'ylim',ylimits).
|
| Repeat-By:
| ---------
|
| 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')
| xlimits =
|
| -0.20000 1.00000
|
| ylimits = get (gca, 'ylim')
| ylimits =
|
| -0.80000 0.80000
|
| Fix:
| ---
|
| * Thus far, I've not found the root of the problem ... I'm a c++
| lacky ;-)

Is gnuplot getting the correct commands? It would seem yes, if it is
working with the X11 terminal. I don't think Octave is sending
different commands for the aqua terminal vs. the X11 terminal, so I
suspect that the problem is in gnuplot.

jwe

[Ben Abbott]

Post by John W. Eaton
| Bug report for Octave 3.1.51+ configured for i386-apple-darwin
|
| -----------
|
| * Running the default branch on Mac OSX 10.5.5 with
GNUTERM="aqua",
| I've discovered
| a strange problem. In some special cases I'm unable to set the axis
| using either
| the 'axis' command, 'xlim'/'ylim' commands, or 'set (gca, ...)'.
| However, if I attempt
| to set the axis limits a second time, using any of these options, it
| works. In the
| event I choose to use the x11 terminal, then everything works as it
| should.
|
| The common denominator appears to be set(gca,'xlim',xlimits) and/or
| set(gca,'ylim',ylimits).
|
| ---------
|
| 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')
| xlimits =
|
| -0.20000 1.00000
|
| ylimits = get (gca, 'ylim')
| ylimits =
|
| -0.80000 0.80000
|
| ---
|
| * Thus far, I've not found the root of the problem ... I'm a c++
| lacky ;-)
Is gnuplot getting the correct commands? It would seem yes, if it is
working with the X11 terminal. I don't think Octave is sending
different commands for the aqua terminal vs. the X11 terminal, so I
suspect that the problem is in gnuplot.
jwe

After fgreping all the sources for mention of "aqua" I must agree.

It is either gnuplot or aqua term.

Is it possible to capture the commands going to gnuplot so that I may
verify them, and conveniently submit a bug to gnuplot?

Ben

[John W. Eaton]

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

[Ben Abbott]

Post by John W. Eaton
| 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?

Ben

[John W. Eaton]

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

[Ben Abbott]

Post by John W. Eaton
|
|
| >
| > | 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
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

[Michael Goffioul]

Post by Ben Abbott
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.

The problem is that xlimmode is switched to manual
after calling the updater (update_xlim). This updater is
responsible for computing the tick marks, but when it
is called, xlimmode is still auto. I think the fix would be
to switch xxxmode properties before anything else in
genprops.awk. This might have other unwanted side effects,
but the only way to know is to try it.

Ben or John, could you take care of the change (it's only
moving 2 lines of code in genprops.awk, around line 341)?

Michael.

[Ben Abbott]

On Tue, Sep 23, 2008 at 5:37 PM, Ben Abbott

Post by Ben Abbott
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.

The problem is that xlimmode is switched to manual
after calling the updater (update_xlim). This updater is
responsible for computing the tick marks, but when it
is called, xlimmode is still auto. I think the fix would be
to switch xxxmode properties before anything else in
genprops.awk. This might have other unwanted side effects,
but the only way to know is to try it.
Ben or John, could you take care of the change (it's only
moving 2 lines of code in genprops.awk, around line 341)?
Michael.

Michael,

Can you be more specific. Is it as simple as placing "limits[i]" ahead
of "updater[i]"?

324 if (emit_set[i])
325 {
326 printf (" void set_%s (const octave_value& val)", name[i],
type[i]);
327
328 if (emit_set[i] == "definition")
329 {
330 if (updaters[i] || limits[i] || mode[i])
331 has_builtin_listeners = 1;
332 else
333 has_builtin_listeners = 0;
334
335 printf ("\n {\n if (! error_state)\n {\n
if (%s.set (val, %s))\n {\n",
336 name[i], (has_builtin_listeners ? "false" : "true"));
337 if (updater[i])
338 printf (" update_%s ();\n", name[i]);
339 if (limits[i])
340 printf (" update_axis_limits (\"%s\");\n",
name[i]);
341 if (mode[i])
342 printf (" set_%smode (\"manual\");\n",
name[i]);
343 if (has_builtin_listeners)
344 printf (" %s.run_listeners (POSTSET);\n",
name[i]);
345 printf (" mark_modified ();\n");
346 printf (" }\n");
347 if (mode[i])
348 printf (" else\n set_%smode (\"manual\");
\n", name[i]);
349 printf (" }\n }\n\n");
350 }
351 else
352 printf (";\n\n");
353 }

Ben

[Michael Goffioul]

No, it's placing mode[i] ahead of updater[i].

Michael.

Post by Ben Abbott
Michael,
Can you be more specific. Is it as simple as placing "limits[i]" ahead of
"updater[i]"?
324 if (emit_set[i])
325 {
326 printf (" void set_%s (const octave_value& val)", name[i],
type[i]);
327
328 if (emit_set[i] == "definition")
329 {
330 if (updaters[i] || limits[i] || mode[i])
331 has_builtin_listeners = 1;
332 else
333 has_builtin_listeners = 0;
334
335 printf ("\n {\n if (! error_state)\n {\n if
(%s.set (val, %s))\n {\n",
336 name[i], (has_builtin_listeners ? "false" : "true"));
337 if (updater[i])
338 printf (" update_%s ();\n", name[i]);
339 if (limits[i])
340 printf (" update_axis_limits (\"%s\");\n",
name[i]);
341 if (mode[i])
342 printf (" set_%smode (\"manual\");\n", name[i]);
343 if (has_builtin_listeners)
344 printf (" %s.run_listeners (POSTSET);\n", name[i]);
345 printf (" mark_modified ();\n");
346 printf (" }\n");
347 if (mode[i])
348 printf (" else\n set_%smode (\"manual\");\n",
name[i]);
349 printf (" }\n }\n\n");
350 }
351 else
352 printf (";\n\n");
353 }
Ben

[Ben Abbott]

On Tue, Sep 23, 2008 at 5:37 PM, Ben Abbott

Post by Ben Abbott
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.

The problem is that xlimmode is switched to manual
after calling the updater (update_xlim). This updater is
responsible for computing the tick marks, but when it
is called, xlimmode is still auto. I think the fix would be
to switch xxxmode properties before anything else in
genprops.awk. This might have other unwanted side effects,
but the only way to know is to try it.
Ben or John, could you take care of the change (it's only
moving 2 lines of code in genprops.awk, around line 341)?
Michael.

Ok, I've built and verified the axis scaling works correctly.

Any thoughts on what the side effects might be?

Do you recommend we just proceed with a patch, and cross our
fingers? ;-)

Ben

[John W. Eaton]

On 24-Sep-2008, Ben Abbott wrote:

|
| On Sep 24, 2008, at 3:07 AM, Michael Goffioul wrote:
|
| > On Tue, Sep 23, 2008 at 5:37 PM, Ben Abbott
| > <***@tqs.com> wrote:
| >> 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.
| >
| > The problem is that xlimmode is switched to manual
| > after calling the updater (update_xlim). This updater is
| > responsible for computing the tick marks, but when it
| > is called, xlimmode is still auto. I think the fix would be
| > to switch xxxmode properties before anything else in
| > genprops.awk. This might have other unwanted side effects,
| > but the only way to know is to try it.
| >
| > Ben or John, could you take care of the change (it's only
| > moving 2 lines of code in genprops.awk, around line 341)?
| >
| > Michael.
|
| Ok, I've built and verified the axis scaling works correctly.
|
| Any thoughts on what the side effects might be?
|
| Do you recommend we just proceed with a patch, and cross our
| fingers? ;-)

I checked in the following chagne. We'll see if it causes trouble.

jwe