On Fri, Sep 7, 2012 at 2:12 PM, Daniel J Sebald <address@hidden
<mailto:address@hidden>> wrote:
On 09/06/2012 02:59 PM, Daniel J Sebald wrote:
I'll toss this one to Ed and Rik, since we were just talking about
precision issues for svds test failures...
I checked the current state of tests and found this failure:
processing
/usr/local/src/octave/octave/__octave/scripts/signal/fftfilt.__m
***** test
There is a bit more to this, and I've put a patch on Savannah:
https://savannah.gnu.org/bugs/__index.php?37297
<https://savannah.gnu.org/bugs/index.php?37297>
The routine will round the output if the inputs are integers and
will truncate the imaginary component if both inputs are real. That
seems fair, I suppose. (I do wonder though if there should be an
option to remove this behavior because some might not want such a
thing. Any thoughts maintainers or OctDev?) I've extended that
concept to account for the other cases of real*imaginary,
imaginary*real, and imaginary*imaginary. I don't see why only the
real*real case should be done...all or nothing, as I see it. These
conditions now have tests, and there are a couple more tests for
tolerance on the imaginary/imaginary scenario, as well as the
complex/complex scenario.
By making the integerization (rounding) test more stringent, I
uncovered a bug whereby only the first element of the output single
row vector was rounded.
Dan
I just ran into the fftfilt test failure again (bugs 37297 & 35959)
and I narrowed it down to differences between FFTPACK and fftw3.
octave with FFTPACK gets the test error:
!!!!! test failed
assert (fftfilt (b, r * x),r * r * [1, 1, 0, 0, 0, 0, 0, 0, 0, 0],eps)
expected
Columns 1 through 3:
...
maximum absolute error 2.22478e-16 exceeds tolerance 2.22045e-16
rebuilding with fftw3 makes the error go away. Then I looked
at the errors with fftpack and fftw3, ie the difference between
the fftfilt output (a 10-element complex vector) and the expected vector:
fftpack
fftw3
-------
-----
3.4694469519536142e-18 + 2.2204460492503131e-16i
0.0000000000000000e+00 - 0.0000000000000000e+00i
1.3877787807814457e-17 + 2.2204460492503131e-16i
0.0000000000000000e+00 - 2.2204460492503131e-16i
3.1892503067014210e-17 + 2.0395767215548695e-17i
0.0000000000000000e+00 - 0.0000000000000000e+00i
-1.5476803848138888e-17 - 1.1721501528016046e-17i
0.0000000000000000e+00 - 0.0000000000000000e+00i
-5.5511151231257827e-17 - 5.2041704279304213e-17i
0.0000000000000000e+00 + 2.7755575615628914e-17i
0.0000000000000000e+00 - 6.9388939039072284e-17i
0.0000000000000000e+00 + 2.7755575615628914e-17i
-3.1892503067014198e-17 - 3.5115384015709088e-17i
0.0000000000000000e+00 - 0.0000000000000000e+00i
1.0999025841583994e-18 + 1.0166004376210030e-17i
0.0000000000000000e+00 + 5.5511151231257827e-17i
-3.4694469519536142e-18 - 0.0000000000000000e+00i
0.0000000000000000e+00 - 0.0000000000000000e+00i
-1.3877787807814457e-17 - 0.0000000000000000e+00i
0.0000000000000000e+00 - 5.5511151231257827e-17i
some things to notice about these:
1) the largest error in both is in the imag part of the 2nd element
and is exactly eps, i.e. one ulp; no big surprise
2) the fftpack result has more "garbage" numbers but roughly the
same size as the garbage from fftw3 and all smaller than eps.
3) the reason the test fails with fftpack is that it was unlucky enough
to have put a bit of garbage in the real part of the second element
which made the abs of the element slightly larger than eps. Otherwise
the two results should be considered equivalent.
I put a modified version of Dan's patch for bug #37297 on the tracker.
In it I added norms to the test tolerances, so for example instead of
assert (y0, y, 55*eps);
I substituted
assert (y0, y, 4*eps*norm(y));
and it passes 10000 passes with both fftpack and fftw3.