Hi Andrew:
Happy (Canadian) Thanksgiving!
Here are some recent test results I have obtained on my 32-bit
MinGW/MSYS/Wine platform using the build_projects approach.
c++
Missing examples :
Differing postscript output :
Missing stdout :
Differing stdout :
f95
Missing examples :
Differing postscript output :
Missing stdout :
Differing stdout :
python
Missing examples :
Differing postscript output : 00 03 04 05 06 08 09 11 12 14 14a 15 16 17 18
19 20 21 22 23 25 26 27 29 33
Missing stdout :
Differing stdout : 23
ada
Missing examples :
Differing postscript output :
Missing stdout :
Differing stdout :
adathick
Missing examples :
Differing postscript output :
Missing stdout :
Differing stdout :
lua
Missing examples :
Differing postscript output :
Missing stdout :
Differing stdout :
I am pretty proud of these results because this is the most extensive
language coverage that I have obtained so far with Wine. C (the
comparison language), and C++, Fortran 95, and Ada are all provided by
the default MinGW-4.7.2 install that you get with the automated
MinGW/MSYS installer. But MinGW also provides Lua which can be
installed using the command (after the automatic install)
mingw-get --recursive install mingw32-lua-dev mingw32-lua-bin
It's possible that Lua result is the first PLplot Lua result
obtained on the MSYS platform since it isn't obvious until you
look pretty hard that Lua is available from MinGW.
Python (the remaining language represented above) and the associated
numpy must be downloaded from SourceForge and installed. (More about
those Python results below.)
The missing languages are Tcl, OCaml, Java, Octave, and D. I have
plans to build Tcl with the build_projects approach. I presume the
other languages can be downloaded in binary form for the Windows case,
but I have not done so because even legitimate sources of Windows
binaries can be compromised which implies the larger the set of
different Windows binary vendors you use, the more chance of a
security threat being introduced on your platform. Which is why I am
trying to stick to just CMake (Kitware), MinGW/MSYS (SourceForge), and
Python (SourceForge) for downloads with the idea of building the
rest of what PLplot needs from source using the
build_projects approach. (I guess ultimately I could drop both CMake
and Python from that list and build them instead as well as OCaml,
Java, Octave, and D, but that is a long way down the road.)
Now I want to focus on the crummy Python results above.
If I recall correctly, Arjen got similar bad Python
results for a test he did on a 32-bit Microsoft Windows platform, and
we blew these results off at the time with what I am now sure is a
spurious argument that floating-point Python values are 32-bits on a
32-bit platform. Do you have access to a 32-bit Linux machine where
you can do a similar test to confirm it is not some internal
Python issue that occurs just for the 32-bit Windows case?
To show this is a spurious argument, for 32-bit Python on a 32-bit
Wine platform, I get the following results:
>>> x = ones(10)
>>> dx = 1.e-13*x
>>> dxprime = (x + dx) - x
>>> dxprime
array([ 9.99200722e-14, 9.99200722e-14, 9.99200722e-14,
9.99200722e-14, 9.99200722e-14, 9.99200722e-14,
9.99200722e-14, 9.99200722e-14, 9.99200722e-14,
9.99200722e-14])
and similar for the x=1. case which demonstrates there are ~16 decimal
digits (or 64-bits minus the exponent bits) of numerical precision in
numpy floating point arrays by default, and similarly with ordinary
Python floating-point variables even though it is a 32-bit platform.
The Python documentation claims that virtually all Python platforms
use 64 bit floating point (IEEE 754 floating-point to be exact) which
those numerical tests help confirm. And the C examples should be
similar on 32-bit platforms with all floating point numerical
constants being represented as doubles (64-bit floating point).
Therefore, from this argument I conclude that in general on 32-bit
platforms the calculation of all floating-point numbers in the python
and C examples should be proceeding with 64-bit floating-point
precision. In the python case, the resulting 64-bit floating-point
arguments of the python functions are transformed into the equivalent
arguments of the C routines of the PLplot core library which implies
the arguments used for all core library routines are identical to
roughly 64 bits of precision between the C examples call and the
corresponding Python examples call.
So from such an argument I would expect 32-bit Python results rounded
down to 4 figures as in the PostScript cases summarized above should
be the same as the results of the rest of the languages on this 32-bit
platform, but that expected result is obviously not confirmed by
the above test results.
I have looked in some detail at all such differences using
(for number in $(seq 0 33); do
echo $number
ndiff x$(printf '%.2d\n' $number)[cp].psc
done) |less
Some examples (17, 19, 20, 22, 25, and 29) have heavy
differences but the rest have small or no differences
other than date.
I explored the x00 case even further because it is a very
simple case, and there is only one rounded PostScript difference.
wine@raven> ndiff x00[cp].psc
6c6
< %%CreationDate: Sun Oct 13 23:25:17 2013
--- field 5
> %%CreationDate: Sun Oct 13 23:54:39 2013
310c310
< 1350 220 M
--- field 1 relative error 7.41e-04
> 1349 220 M
(N.B. ndiff can automatically be built by build_projects and is quite
useful for such PostScript file difference analysis.)
The "M" means a move is being made, and looking at the surrounding
context to that one non-date difference between these two postscript
files, that move occurs just before the start of writing the
Y axis annotation "y=100 x#u2#d", i.e., the difference is
a slight change in the position of that annotation.
The relevant Python code from the
example is
xmin = 0.
xmax = 1.
ymin = 0.
ymax = 100.
# Prepare data to be plotted.
x = arange(NSIZE) / float( NSIZE - 1 )
y = ymax*x**2
# Create a labelled box to hold the plot.
plenv( xmin, xmax, ymin, ymax, 0, 0 )
pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" )
Note, the x and y arrays have no influence on the position of the Y
annotation (but I left the definition of those in the above listing
for completeness.) In fact, the only floating-point data that should
control the initial position of that Y axis label should be xmin,
xmax, ymin, ymax, and how those numbers propagate to the C core
library version of plenv. But my 32-bit Python experiments clearly
indicate xmin, xmax, ymin, and ymax are identical precision to the
corresponding C (and other language) results, and that was confirmed
in detail when I ran gdb to
check the arguments of the c_plenv C routine from our core library.
They turned out to be identical between the Python and C cases
as can be shown by the following gdb results
(gdb) x/xg &xmin
0x60f728: 0x0000000000000000
(gdb) x/xg &xmax
0x60f720: 0x3ff0000000000000
(gdb) x/xg &ymin
0x60f718: 0x0000000000000000
(gdb) x/xg &ymax
0x60f710: 0x4059000000000000
for both cases. Furthermore,
http://babbage.cs.qc.cuny.edu/IEEE-754.old/64bit.html translates those
hex values as the IEEE 754 exact representations of the decimal
floating numbers 0., 1., 0., and 100 (as expected, see the Python code
above). If the c_plenv arguments are C core routine receives are
identical to 64-bits as in the above C and Python example 00 cases,
then it follows that the PLplot results should be absolutely
identical. But obviously that is not the case so so I am completely
floored by these results. One of my assumptions must be wrong so I
would appreciate you taking a look as well with gdb assuming you have access
to a 32-bit Linux machine.
In sum, there is an issue with our Python results on 32-bit Windows
that needs to be confirmed also on 32-bit Linux. All theoretical
analysis and practical gdb results I can come up with says this issue
cannot occur. So I must be missing something and need help to figure
this out.
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
__________________________
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
