[SciPy-Dev] fftpack test failures for 0.8.0b1
Thu Jun 24 09:31:52 CDT 2010
On Sat, Jun 19, 2010 at 2:55 AM, Ralf Gommers
> On Thu, Jun 17, 2010 at 11:48 PM, Charles R Harris <
> email@example.com> wrote:
>> On Thu, Jun 17, 2010 at 8:50 AM, Ralf Gommers <
>> firstname.lastname@example.org> wrote:
>>> Below are two test failures in fftpack. The test data is random, so they
>>> happen only occasionally. I decreased the precision to decimal=5 and
>>> maxulp=1e4, but still got one failure of each test in 200 test runs. The
>>> TestSingleIFFT failure always occurs with an array of size 111. This is on
>>> OS X 10.6, the same first error was also reported on 10.5.
>>> What should be done with these failures?
>> I guess the first thing is to figure out what is going on, and that needs
>> something repeatable. Maybe the test could be repeated with a set of seeds
>> until the problem appears. Also, since 111 = 3*37, I wonder what happens
>> with other odd primes besides 37. It might be worth testing with 97 and
>> other such.
>> Attached is a small script to test with larger primes. You can supply a
> fixed seed but it's not even necessary. Typical result:
> arraysize, max error
> 1 0.0
> 17 4.76837e-07
> 37 2.98023e-06
> 97 0.000104427
> 313 0.000443935
> 701 0.00112867
> 1447 0.00620008
> 2011 0.0138307
> 3469 0.16958
> So even decimal=4 would fail for 97 already. For larger primes the FFT
> should be slower but not less accurate, right?
Any opinion on this? Is it easily fixable? This is the last thing holding up
0.8.0 I think, can we mark it knownfail for that or does anyone think it's
important enough to delay the release for?
> If I use the numpy.fft.fft/ifft the result is:
> 1 0.0
> 17 7.54951656745e-15
> 37 2.99760216649e-15
> 97 4.99600361081e-15
> 313 1.65423230669e-14
> 701 5.66213742559e-15
> 1447 3.0253577421e-14
> 2011 1.87072579649e-14
> 3469 1.09912079438e-14
> Looks a lot better.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SciPy-Dev