----- Original Message -----
From: "David Brodbeck" <[EMAIL PROTECTED]>
.
.
>>
>> I could give it a try tomorrow, and see what I can come up with. Could
>> it be as simple as a precision mismatch between an "expected" value and
>> a "got" value ? (ie a bug in the test script itself.)
>
> I don't think so, because these values are at most three decimal places.
> I suppose it could be a round-off error difference caused by the extra
> precision, but I'm not clear on what the expected results for the
> t/limits.round.t tests are.
>
It's probably the more general problem of doing comparisons (==, < and >)
between doubles.
There's no problem if, in limits.pm, we replace:
-----------------------------------------------
if ( 'up' eq $what )
{
$i = 3;
$i = 2 if $frac < $nice[2];
$i = 1 if $frac < $nice[1];
$i = 0 if $frac < $nice[0];
}
elsif ( 'down' eq $what )
{
$i = 0;
$i = 1 if $frac > $nice[1];
$i = 2 if $frac > $nice[2];
$i = 3 if $frac > $nice[3];
}
-----------------------------------------------
with:
-----------------------------------------------
if ( 'up' eq $what )
{
$i = 3;
$i = 2 if $frac - $nice[2] < -1e-15;
$i = 1 if $frac - $nice[1] < -1e-15;
$i = 0 if $frac - $nice[0] < -1e-15;
}
elsif ( 'down' eq $what )
{
$i = 0;
$i = 1 if $frac - $nice[1] > 1e-15;
$i = 2 if $frac - $nice[2] > 1e-15;
$i = 3 if $frac - $nice[3] > 1e-15;;
}
-----------------------------------------------
There's also a need (in t/limits_round.t) to rewrite:
-----------------------------------------------
ok( $test->[1] == $down && $test->[2] == $up
-----------------------------------------------
as:
-----------------------------------------------
ok( abs($test->[1] - $down) < 1e-15 && abs($test->[2] - $up) < 1e-15
-----------------------------------------------
However, if round_pow() is then used with very small values, even those
fixes might not be good enough.
The round_pow sub is pure perl, and the reason that 32-bit builds are not
afflicted with exactly the same problem is not apparent to me. (The more I
think about this particular aspect, the more puzzling it becomes ... I'd
better stop thinking about it :-)
I'm also getting failures with limits_trans_err.t on 64-bit builds for (I
suspect) essentially the same reason - though I think the problem there lies
solely with the test script itself. (I haven't yet checked). I expect that
the "ok( eq_array(...." tests need to be replaced with "ok(
very_nearly_eq_array(...." tests.
But I don't think Test::More has a "very_nearly_eq_array" (or similar)
function. I'll have to check.
Thanks for bringing this to our attention, btw :-)
Afaik, there haven't been any fail reports from the cpan-testers in relation
to this - but that could only be because those testers that are using 'ld'
builds of perl don't have ExtUtils::F77 installed. Hence Slatec is not being
built, and the PDL::Graphics::Limits test scripts are therefore being
skipped.
Cheers,
Rob
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
