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:
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?
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.
I hope this removes the randomness, and we can get down to "real" testing!
Regards, Sumant
On Thu, Sep 2, 2010 at 6:27 PM, Sumant Oemrawsingh soemraws@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.
- 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.
- 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@xs4all.nl
On Sat, Sep 4, 2010 at 1:03 PM, Liam Healy lhealy@common-lisp.net wrote:
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.
Sumant,
I've created a function gsll::off-stride in tests/fast-fourier-transform.lisp that copies the array for all elements except the on-stride elements. For example:
(off-stride #4m(#C(0.26385453 0.0) #C(1002.0 1003.0) #C(0.106692255 0.0) #C(1006.0 1007.0) #C(0.8149124 0.0) #C(1010.0 1011.0) #C(0.19136061 0.0) #C(1014.0 1015.0)) 2)
#4m(#C(1002.0 1003.0) #C(1006.0 1007.0) #C(1010.0 1011.0) #C(1014.0 1015.0))
Together with the function grid:stride, which copies just the on-stride elements:
(grid:stride #4m(#C(0.26385453 0.0) #C(1002.0 1003.0) #C(0.106692255 0.0) #C(1006.0 1007.0) #C(0.8149124 0.0) #C(1010.0 1011.0) #C(0.19136061 0.0) #C(1014.0 1015.0)) 2)
#4m(#C(0.26385453 0.0) #C(0.106692255 0.0) #C(0.8149124 0.0) #C(0.19136061 0.0))
I think you have should everything you need to do the tests.
Liam
-
Liam Healy -
Sumant Oemrawsingh