On Thu, Sep 2, 2010 at 6:27 PM, Sumant Oemrawsingh <soemr...@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 > soemr...@xs4all.nl _______________________________________________ Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel