I have been trying to debug some minor differences that occur between
the results from the (as yet uncommitted) revised Python example 8 and
the corresponding C result. Here is the diff that is occurring for
the -dev psc generated page in example 8 that uses plsurf3dl to show an
elliptical
index range of results for the sombrero function that is plotted.
software@raven> diff -au test3[12].psc
--- test31.psc 2014-10-23 11:53:44.108436313 -0700
+++ test32.psc 2014-10-23 12:03:46.653786760 -0700
@@ -3,7 +3,7 @@
%%%%%%%%%%%%%%%%%%%%%%
%%Title: PLplot Graph
%%Creator: PLplot Version 5.10.0
-%%CreationDate: Thu Oct 23 11:53:44 2014
+%%CreationDate: Thu Oct 23 12:03:41 2014
%%Pages: (atend)
%%EndComments
@@ -15483,7 +15483,9 @@
1543 1701 M 1543 1710 D S
1.0000 1.0000 0.0000 C 1543 1710 M
Z
-1545 1736 M 1543 1710 D S
+1545 1736 M 1543 1710 D 1543 1710 M
+ 1543 1710 M
+ S
eop
%%Trailer
The test31.psc version is generated by C while the test32.psc version
is generated by Python. To help interpret the above PostScript
commands you should be aware that our PostScript "M" "D", "S", "C",
and "Z" commands are defined as follows in the PostScript header:
/M {moveto} def
/D {lineto} def
/S {stroke} def
/C {setrgbcolor} def
/Z {stroke newpath} def
I assume the motivation for this was to make the ps device driver
results more compact than they would have been without those def's.
So the above diff simply means the Python version has a few extra
M = moveto commands at the end which implies identical visual results, but
the issue still needs to be tracked down and fixed to get rid of the
claim in the test_diff_psc report that the Python example 8 results
are different from the corresponding C results.
As a first step in debugging this issue, I used gdb to dump all
arguments in detail for the plsurf3dl command. The C and Python
results were identical for all arguments other than z. There, the
undefined parts (outside the elliptical index limits) were different
for obvious reasons. I checked in the two cases that valgrind found
no relevant uninitialized variables. I have also done other checks of
the plsurf3dl code using z defined to be 1.e300 in the "undefined"
regions. That made no difference to the results. Thus, I am
confident there are no undefined variable issues with the plsurf3dl
code in our plplot C library.
I put together a gdb script to dump just the defined regions of z in a
nice format, and those turned out to be identical to 14 figures, but
there were some isolated differences beyond that (as expected since
the Python calculation of z using numpy uses very different C code
than our own examples/c/x08c.c coding. So since floating-point
operations are done in different order in the two cases you are always
going to see such minor differences.
So from the above diff results and my gdb results, what appears to be
going on is that minute rounding issues between Python/numpy and C are
propagating to the ps device driver and causing it to make some
additional M instructions in the Python case. Furthermore, this
issue is unique to the ps device driver (and probably the psttf device
driver as well since that copies much of the same logic) since if I
use any of pscairo, epscairo, epsqt, svg, or pdf device drivers, they
all produce _identical_ Python and C results with this exact
test case.
Further debugging showed the issue was associated with the surface
contour lines used for that page which boil down to calls
to
plcol0( color );
...
plline3( 2, xx, yy, zz );
for all contour levels that occur for a given quad
before the example ends.
I still haven't figured out what is causing the extra M instructions
in the Python case (with just the psc device) because the ps device
driver is quite obfuscated in how it handles colors. For example,
some times the pattern is
r g b C Z
and sometimes it is
r g b C x y M
Z
where x y are the coordinates of the last D command.
The actual plline3 command above boils down to a
call to plD_line_ps, and the only way that appears
to write out an "M" command is via
snprintf( outbuf, OUTBUF_LEN, "%d %d M %d %d D", x1, y1, x2, y2 )
So that accounts for the
x1 y1 M x2 y2 D
command pattern showing in the above diff, but does not account for
the additional "M" commands without any corresponding D command that
show up for the slightly differently rounded Python results.
So I am still digging into the ps device driver code to attempt
to figure out what code could possibly generate isolated M commands, and
once I find that code, attempt to figure out why its execution depends
so sensitively on rounding issues.
By the way, I was momentarily tempted to simply drop the
implementation of the test_diff_psc target and instead replace that
target with a test_diff_svg target that used the svg device driver
instead. However, the good news is svg results are much more readable
than PostScript results, but the bad news is that readability is
because they are extremely "wordy" so svg test results take 5 times
the disk storage of the corresponding psc results. Therefore I have
ignored this temptation because comprehensive tests are already
consuming huge amounts of disk space, and I don't want to increase
that amount by a factor that might approach 5!
So back to figuring out this ps device driver issue that apparently
emits isolated "M" commands that come or go due to sensitive rounding
issues that only occur in the 14th or later decimal digit of
the floating-point quantity.
More later.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
