[Gsll-devel] GSLL fast-fourier-transform test woes

[Liam Healy]

On Thu, Sep 2, 2010 at 6:27 PM, Sumant Oemrawsingh <soemraws at xs4all.nl> wrote:
> Hi Liam,
>
> After the fix that, supposedly, would let the test assertions fail
> reproducibly (but didn't), I just now pushed a new version of example.lisp
> that should fix the remaining problem. At least, it does so on my computer. I
> consistently get a number of failed assertions that matches the expected
> amount that should fail, based on the number of stride > 1 cases.
>
> If you find that this works, I would very much like you to check the following:

Yes works.

>
> 1. The only real change I made was in the function test-fft-noise, in the
> section that returns the backward vector. Originally, for gsl > 1.12, you did
> an elt/ on a (copy backward). I replaced this with a vector/length. I don't
> understand why you did a copy of backward, so I removed that. Is that correct?

I think the copy of backward was a new addition, because I misunderstood
the stride > 1 problem.  I get the same answer you do now, so I presume it is
correct.

>
> 2. Since I have NO idea what happens for gsl <= 1.12 and no fsbv, I just did
> something which seemed right and removed the map. Is this correct?
> However, while I don't know what does and doesn't work in this case, I suspect
> that vector/length should work fine also for gsl <= 1.12 and no fsbv, since it
> loops over the individual elements.

No; I've fixed it, it actually makes it much simpler.  As long as
we're not using
elt/, we don't need to qualify on 1.12 and FSBV, so there's no longer a check.
Now I get the same stride > 1 failures I get on 1.11 and 1.14.

>
> I hope this removes the randomness, and we can get down to "real" testing!

Yup randomness is removed.  I'll write the on-stride and off-stride tests, but
I now I need to understand where to apply them.

Liam

>
> Regards,
> Sumant
>
> --
> Sumant Oemrawsingh
> soemraws at xs4all.nl