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: Wed, 03 Apr 2013 15:24:33 -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 04/03/2013 03:03 PM, Jordi Gutiérrez Hermoso wrote:
On 3 April 2013 00:51, Ed Meyer<address@hidden>  wrote:



On Mon, Mar 18, 2013 at 8:35 AM, Jordi Gutiérrez Hermoso
<address@hidden>  wrote:

On 18 March 2013 01:05, Ed Meyer<address@hidden>  wrote:

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.

Sorry, something might have just gotten lost or forgotten in the
way. Which patches of yours have gone unapplied?

Besides the patch for 37297 there is one for 34461 and 34634. The
first two mainly deal with test tolerances. 34634 adds the ability
to read a mat file with undocumented data types for names which is
readable by ML.

Ok, I'll look into those now.

I'm looking at this right now too. I'm going to apply the patch for 37297 to the most recent tip, then create another patch. This won't have Ed's changes. After the new changeset is attached to the report, then applied, we'll close that and have Ed generate a new changeset in a new patch report with just his mods to the tests. That's better than trying to combine the two into one. Should take a couple hours...


The test tolerance issue has come up several times in the short time
I've been on the mail list; I believe that instead of simply
increasing the tolerances, tests should be written to reflect the
theoretical error bounds, which always involve some measure of the
data or solution. As I've said before, don't take my word for it,
see e.g. Golub&  VanLoan or most any numerical methods text like
Forsythe&  Moler :-)

Oh, I completely agree, but it's very difficult to know what the
actual theoretical tolerance should be. It would require some careful
analysis of each problem plus knowledge of the algorithms that are
being used to compute each test. Frequently these algorithms differ
since they're implemented in libraries external to Octave; indeed, it
is often when these external libraries change that we see differing
tolerances.

I did a rough guess for the fftfilt routine. I was off by a factor of eight or ten if I recall correctly. Not bad. It's an FFT so one can guess how many multiplies and adds there are because I would hope the algorithm is as efficient as possible.

I think Ed's mods covered that. There are a couple types of tests. One is to test degenerate cases and have a really tight tolerance. That's sort of a sanity check. Then there are the cases that fully exercise all aspects of the algorithm. These are the cases you refer to that are hard to judge what the tolerance should be. In that case using minuscule fractions of some norm for the tolerance should do.

Dan


reply via email to

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