Package: grace Version: 1:5.1.18-1 Severity: normal
Hi!
Setting the tick label format to something different from "general" may,
in some cases, cause the zero tick label to be very close, but not
exactly equal to zero.
As a result, what should really be, say, 0.0e+00 (assuming, for
instance, that format is set to "exponential" and precision is set to 1),
is something like -2.7e-20, instead.
This is annoying because one would like to see equally spaced tick
labels with no "weird" values.
An example is attached.
If you issue the following command:
$ xmgrace -p my.par
you will see a graph where the Y axis shows five tick labels,
namely -4.0e-04 -2.0e-04 -2.7e-20 2.0e-04 4.0e-04 .
This is obviously bad looking...
What I set for the Y axis is
Start: -0.0005
Stop: 0.0005
Scale: Linear
Major spacing: 0.0002
Minor ticks: 1
Format: Exponential
Precision: 1
Tick marks at rounded positions: yes
I know that these numbers cannot be represented exactly in binary
floating point: the weird behavior is caused by unavoidable FPU
finite precision and by binary floating point representation errors.
Actually, if I set
Start: -0.00048828125
Stop: 0.00048828125
Major spacing: 0.000183105
which have exact binary floating point representations, the zero
tick label becomes 0.0e+00, as it should be.
I investigated this issue by digging into the source and found the
following code snippet in src/drawticks.c :
[...]
wtmaj = swc_start + itmaj*stmajor;
if (t->tl_format == FORMAT_GENERAL && fabs(wtmaj) < 1.0e-6*stmajor) {
wtmaj = 0.0;
}
[...]
As it can be seen, there's a hack that zeroes the tick label value,
when this value is considered too close to zero to be "true".
This hack is enabled for the "general" format only, though.
Moreover this hack seem to do more harm than good in some corner cases.
An example is attached.
If you issue the following command:
$ xmgrace -p your.par
you will see a graph where the Y axis shows eleven tick labels, namely
-0.50000001 -0.40000001 -0.30000001 -0.20000001 -0.10000001 0
0.09999999 0.19999999 0.29999999 0.39999999 0.49999999 .
This is wrong, as the zero tick label should not really be zero, but
a legitimate -1e-08, instead...
What I set for the Y axis is
Start: -0.50000001
Stop: 0.5
Scale: Linear
Major spacing: 0.1
Minor ticks: 1
Format: General
Precision: 9
Tick marks at rounded positions: no
I think I found a way to fix this issue.
A patch is attached.
I also checked src/drawticks.c in the latest upstream version of grace
(currently 5.1.20): it seems to be basically unchanged w.r.t. version
5.1.18; hence this patch should apply cleanly even to the latest version.
Before I forget, I don't think that this patch constitutes a contribute
creative enough to be copyrighted, but anyway, should it turn out to
actually be copyrighted, I hereby release it under the same terms of
src/drawticks.c, that is to say, under the terms of the GNU General
Public License as published by the Free Software Foundation; either
version 2 of the License, or any later version.
An explanation of the patch follows:
When tick marks must be placed at rounded positions, if zero is between
tick label bounds, then start computing tick label values from zero,
rather than from the lower bound. This way we are sure that the zero tick
label is actually zero.
When tick marks must not be placed at rounded positions, compute tick
label values as usual (without the zero forcing hack, though).
Rationale:
If the user requires tick marks at rounded positions, he/she apparently
wants an actual zero (as long as the tick label range actually include
zero!), hence we must be sure we actually generate a zero tick label.
If the user doesn't require tick marks at rounded positions, he/she
apparently wants tick labels to start from the lower bound, hence
we shouldn't alter this computation. Since there will probably be
no tick label at zero, no weird value will be shown. The only
case where a (not exactly) zero tick label would result is when
the user sets the Start to a value that is, by chance, rounded, but in
that case, the user can safely switch to "tick marks at rounded positions",
if he/she is annoyed by the weird value close (but not exactly equal)
to zero.
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.32
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages grace depends on:
ii defoma 0.11.8-0.1 Debian Font Manager -- automatic f
ii fftw2 [fftw2-doubl 2.1.3-16 Library for computing Fast Fourier
ii gsfonts 8.14+v8.11+urw-0.2 Fonts for the Ghostscript interpre
ii lesstif2 1:0.93.94-11.4 OSF/Motif 2.1 implementation relea
ii libc6 2.3.2.ds1-22sarge3 GNU C Library: Shared libraries an
ii libice6 4.3.0.dfsg.1-14sarge1 Inter-Client Exchange library
ii libjpeg62 6b-10 The Independent JPEG Group's JPEG
ii libpng12-0 1.2.8rel-1 PNG library - runtime
ii libsm6 4.3.0.dfsg.1-14sarge1 X Window System Session Management
ii libt1-5 5.0.2-3 Type 1 font rasterizer library - r
ii libx11-6 4.3.0.dfsg.1-14sarge1 X Window System protocol client li
ii libxext6 4.3.0.dfsg.1-14sarge1 X Window System miscellaneous exte
ii libxmu6 4.3.0.dfsg.1-14sarge1 X Window System miscellaneous util
ii libxp6 4.3.0.dfsg.1-14sarge1 X Window System printing extension
ii libxpm4 4.3.0.dfsg.1-14sarge1 X pixmap library
ii libxt6 4.3.0.dfsg.1-14sarge1 X Toolkit Intrinsics
ii netcdfg3 3.5.0-7.1 An interface for scientific data a
ii xlibs 4.3.0.dfsg.1-14sarge1 X Keyboard Extension (XKB) configu
ii xmhtml1 1.1.7-14 A Motif widget for display HTML 3.
ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime
-- no debconf information
my.par.gz
Description: Binary data
your.par.gz
Description: Binary data
actualzero.diff.gz
Description: Binary data
