[Octave-bug-tracker] [bug #39647] Failed test in fftfilt due to machine round off

[Dan Sebald]

URL:
  <http://savannah.gnu.org/bugs/?39647>

                 Summary: Failed test in fftfilt due to machine round off
                 Project: GNU Octave
            Submitted by: sebald
            Submitted on: Thu 01 Aug 2013 06:17:41 PM GMT
                Category: Octave Function
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: None
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: dev
        Operating System: Any

    _______________________________________________________

Details:

A developer on the maintainers list reported:


octave:3> test fftfilt
  ***** test
 b = [1 1];
 x = [1, zeros(1,9)];
 assert (fftfilt (b,  x  ), [1 1 0 0 0 0 0 0 0 0]  );
 assert (fftfilt (b,  x.'), [1 1 0 0 0 0 0 0 0 0].');
 assert (fftfilt (b.',x  ), [1 1 0 0 0 0 0 0 0 0]  );
 assert (fftfilt (b.',x.'), [1 1 0 0 0 0 0 0 0 0].');
 assert (fftfilt (b,  [x.' x.']), [1 1 0 0 0 0 0 0 0 0].'*[1 1]);
 assert (fftfilt (b,  [x.'+eps x.']) == [1 1 0 0 0 0 0 0 0 0].'*[1 1],
[false(10, 1) true(10, 1)]);
!!!!! test failed
assert (fftfilt (b, [x.' + eps, x.']) == [1, 1, 0, 0, 0, 0, 0, 0, 0, 0].' *
[1, 1],[false(10, 1), true(10, 1)]) expected
   0   1
   0   1
   0   1
   0   1
   0   1
   0   1
   0   1
   0   1
   0   1
   0   1
but got
   1   1
   0   1
   0   1
   0   1
   0   1
   0   1
   0   1
   0   1
   0   1
   0   1
values do not match
shared variables
  scalar structure containing the fields:

    b = [](0x0)
    x = [](0x0)
    r = [](0x0)

hg tip
changeset:   17035:08f0e372d006


When the inputs are integer (second column), the result is "cast" to integer
by dropping the floating portion.  In the first column the inputs are not all
integer so the epsilon should be left intact.  However, because of machine
precision the epsilon is being lost and it just so happens the output is
exactly 1.

I asked the user to try increasing the perturbation to 2*eps and that passed. 
We'll go with 2*eps and if there are further reports of failure, increase that
incrementally.





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?39647>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/