On 2011-09-13 15:35-0600 Orion Poplawski wrote:
> On 09/02/2011 04:59 PM, Doug Hunt wrote:
>> Hi Orion, all: I've just uploaded a new version of PDL-Graphics-PLplot to CPAN
>> (v 0.57) which incorporates some fixes recently merged in from the the PDL
>> source tree and also includes an improved plplot_library_tests.t.
>>
>> This test now compiles and runs the C sources
>> from the plplot examples directory and compares them to the perl equivalent
>> output instead of using canned C output for comparison.
>
> Okay, I'm running into a interesting failure on i686 only:
>
> # Failed test 'Output file x28p.svg.1 matches C output'
> # at t/plplot_library_tests.t line 65.
> # Failed test 'Output file x28p.svg.2 matches C output'
> # at t/plplot_library_tests.t line 65.
> # Failed test 'Output file x28p.svg.4 matches C output'
> # at t/plplot_library_tests.t line 65.
> # Looks like you failed 3 tests of 242.
> t/plplot_library_tests.t ..
>
> The difference in all three are like the following:
>
> $ diff x28[cp].svg.1
> 991c991
> < transform="matrix(0.728866 0.165055 -0.000000 -1.000000 222.106388
> 332.170782)"
> ---
> > transform="matrix(0.728866 0.165055 0.000000 -1.000000 222.106388
> 332.170782)"
>
>
> a difference in the sign of 0. The -0 result appears to be more "correct" in
> that that is what is present in both the C and perl x86_64 tests. This is
> pretty baffling to me. Thoughts?
The IEEE floating-point representation allows a signed zero value
which the printf family of routines would print out like above.
Alternatively, the above result could be the result of rounding of
something near zero with the "%10.6f" formatting directive for the
printf family. Anyhow, regardless of whether it is a zero or
near-zero signed value, you appear to be getting different answers for
that sign for different languages which is not too surprising.
I am pretty sure I recall from years ago we were having similar "zero"
trouble with the PostScript plots we were comparing for different
languages. And the solution in that case was to force near-zero
answers to zero. So I think this particular svg device just needs to
be made more robust against tiny differences like above by doing the
same thing for it.
Assuming the problem occurs for -dev svg, I would be happy to
encourage a fix for that device to make it suitable for such
comparisons. I would also encourage exploiting that work by
implementing the alternative of using -dev svg comparisons for
PLplot's own tests. Those tests (in the plplot_test/test_diff.sh(.in)
bash script) are strictly limited to -dev psc results at the moment
because all such "zero" issues (and possibly others) have long since
been worked out for that device.
Of course, another alternative would be for Doug to also use -dev psc
for his comparisons, but I hope he doesn't retreat like that and
instead continues with -dev svg. After all, (unlike -dev psc) -dev svg
is a modern device that does produce good-looking results for all our
examples. Therefore, it would be great to start using -dev svg
results for all PLplot comparison purposes.
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
__________________________
|