octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Test failure for fftfilt.m


From: Daniel J Sebald
Subject: Re: Test failure for fftfilt.m
Date: Mon, 18 Mar 2013 00:35:35 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On 03/18/2013 12:05 AM, Ed Meyer wrote:


On Sat, Mar 16, 2013 at 4:28 PM, Daniel J Sebald <address@hidden
<mailto:address@hidden>> wrote:

    On 03/16/2013 05:18 PM, Ed Meyer wrote:

        I fixed the tests last fall according to what I consider the
        right way to
        do tests like this. As I have said several times before tests
        should not
        in general use absolute tolerances, rather they should take into
        account
        the size of the data. So for example instead of

        assert (fftfilt (b, r * x),r * r * [1, 1, 0, 0, 0, 0, 0, 0, 0,
        0],eps)

        I used

        %! y = r*r*[1 1 0 0 0 0 0 0 0 0];
        %! tol = 2*norm(y)*eps;
        %! assert (fftfilt (b, r*x), y, tol);

        There are a number of tests like this (eig.cc for example) with
        absolute
        tolerances which should be using norms. But don't take my word
        for it,
        see, e.g. Golub & Van Loan, "Matrix Computations".


    Yes, I'm a bit sketchy, but I remember looking at the work you had
    done.  I thought you checked it in.  But this file log would suggest
    it wasn't:

    
http://hg.savannah.gnu.org/__hgweb/octave/log/7d0848353eaf/__scripts/signal/fftfilt.m
    
<http://hg.savannah.gnu.org/hgweb/octave/log/7d0848353eaf/scripts/signal/fftfilt.m>

    Dan


As I recall you made some changes that wiped out what I sent you and we
never got them back in before you checked it in. I could put a patch up but
for some reason other patches I've put up don't get applied so there is
something
I don't understand about the process.

OK, it's coming back to me a bit.  This was part of

http://savannah.gnu.org/bugs/?37297

and in addition to the bad tests were some bugs with rounding to the nearest integer if it is known the inputs are integers, under various conditions. The patch you placed there is probably still fine. When I find the time this week I will:

1) Update the bug-fix portion of the code and create an individual patch for that. Well have someone apply that patch.

2) We'll close out the 37297 bug report and create another where you can place the patch for the tolerance additions. That 37297 report is already too confusing.

That way we'll have two patches with appropriate contributors. That multiple changeset idea didn't apply so well.

Dan


reply via email to

[Prev in Thread] Current Thread [Next in Thread]