Re: [Plplot-devel] [PATCH] Support arbitrary storage of 2D user data

[Alan W. I. <ir...@be...>]

Hi Dave (with question for Andrew at the end):

On 2010-03-12 16:24-0800 David MacMahon wrote:

> This is a roll-up of all previous PLplot patches related to supporting
> arbitrary storage of 2D user data.  This patch is based on (and should
> apply cleanly to) svn/trunk r10859.

I did some tests of your patch.

The patched and unpatched PostScript results from the test_diff_psc target
were identical (using cmp -i 170 to compare the 467 (!) files produced by
that target) between the two build directories other than p21.psc where both
plots looked okay, but there were obvious visual differences (axes shifted
slightly around, etc.)

Note, p21 is a "p" example that runs a high-level octave interface that is
known to be problematic (see my previous post where I showed the "p"
examples and associated high-level octave interface need lots of TLC).
Therefore, I am not surprised p21 gives substantially different results for
rounding errors that are presumably only slightly different.  We had such
propagation of rounding errors in our standard examples for years, and it
took quite a bit of effort and some changing of the examples that depended
on floating point as opposed to integer comparisons to get rid of most
of those issues.

Here are the timing results for the patched and unpatched cases.

PATCHED
software@raven> time make -j4 test_diff_psc >& make_test.out

real    3m23.120s
user    3m43.878s
sys     0m34.386s

UNPATCHED

software@raven> time make -j4 test_diff_psc >& make_test.out

real    3m27.809s
user    3m44.350s
sys     0m33.274s

These times were done for an initially empty build tree so they include both
complete build times and run times.  Also, certain examples (which may have
nothing to do with your patch) dominate the run times.  So as discussed
previously these results should be taken with a large grain of salt, but
there is nothing obviously a lot slower with the patched result and in fact
it is slightly (but probably not significantly) faster in total elasped
time.

Because with this test I could detect no gross efficiency concerns and
because the PostScript results were identical (except for p21) 
I have committed this patch (revision 10864).

Thanks, Dave, for all your work on this arbitrary storage of 2D data
API.

Hi Andrew:

Would you please evaluate this revision with the best tests you can think of
with regard to your efficiency concerns?  If and when you are satisfied on
this score (but not before) we should be thinking about propagating these
API additions to all languages.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________