I think that we have definitively determined that fftconvolve is broken. Would you be so kind as to submit a bug report to Sourceforge?
Meanwhile, it is suggested that you use convolveND instead - it normally chooses direct or FFT processing depending on a speed heuristic, but has an option to force FFT processing. The two methods give the same answer to within numerical roundoff. The convolveND method has further advantages: it honors the inplace flag (see ?inplace in perldl, or man PDL::Core), rather than scrozzling its inputs, and it has selectable boundary conditions. On Feb 20, 2009, at 2:27 PM, hernan gonzalez wrote: > fftconvolve seems indeed broken. > > my $p1 = pdl(1,0,0,0); > my $p2 = pdl(1,0,0,0); > fftconvolve($p1,$p2); > print $p1 . "\n"; > > results in > > [1.75 -0.25 -0.25 -0.25] > > > It seems that the result is missing the DC component (as if the fft > had supressed the 0-freq value) and a factor 2 is missing somewhere. > > Hernán > > >> Andreas Michalowski michalowski at ifsw.uni-stuttgart.de > > A simple example is like this: I convolve two 1D piddles, the first is > zero except for one value which is 1. The second one has a gaussian > shape. I expect as the result a piddle which contains a gaussian shape > converging to zero far away from the center. > > The resulting piddle shows the expected gaussian shape but is not > converging to zero, instead of that to a negative constant value. It > seems that the result has a negative offset. > If I do the convolution with "convolve" instead of "fftconvolve" the > result is exactly what I expect. > > Does someone has an idea why fftconvolve has this (for me) unexpected > and (for me) incorrect behavior? > > Many thanks! > > Andreas > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
