convolveND() does indeed use Fourier transformation for large arrays. I believe it has a superset of the functionality of convolve() and fftconvolve(). I have not looked closely enough at fftconvolve, conv1d, or conv2d to know if they should be deprecated like convolve(), but you ought to be able to use just convolveND to replace all of those routines.
Unfortunately, there are several cases like this that need to be cleaned up for the next release (either 2.5 or 3.0 depending on whether we overhaul PP like everyone is talking about): because we tend to be a community of implementors, we generally get several specialized routines implemented before the general case gets tackled. Cheers, Craig On Jan 26, 2009, at 8:09 AM, Andreas Michalowski wrote: > Chris M schrieb: >> Andreas Michalowski wrote: >>> Ok, I will report the bug to the sourceforge site as soon as I >>> recover my password. ;) >>> The question is how meaningful the bugfix for the depreciated >>> "convolve" and "fftconvolve" is. My suggestion is to realize the >>> idea >>> of sisyphus: The replacement of convolve and fftconvolve with >>> convolveND, namely inside the PDL sources if possible. What do you >>> think? >> >> I checked my PDL-2.4.3 install and the docs for convolve >> say deprecated, use convolveND. So moving to a convolveND >> implementation would seem reasonable. Please do submit >> your bug report to the PDL sf.net tracker so that this will >> get to the to-do list. >> >> We do not have a new version of fftconvolve so that >> would not be replaced---the FFT convolution algorithm >> has much better performance for the case of very large >> kernels. >> >> Regards, >> Chris > I thought convolveND has also FFT properties, because the > documentation > of convolveND says: > ----------- > > *method (default: 'auto')* > The method to use for the convolution. Acceptable alternatives are > 'direct', 'fft', or 'auto'. The direct method is an explicit > copy-and-multiply operation; the fft method takes the Fourier > transform of the input and output kernels. The two methods give the > same answer to within double-precision numerical roundoff. The fft > method is much faster for large kernels; the direct method is > faster > for tiny kernels. The tradeoff occurs when the array has about 400x > more pixels than the kernel. > > The default method is 'auto', which chooses direct or fft > convolution based on the size of the input arrays. > > ----------- > > Is this a wrong information? (I'am PDL novice) > > regards, > > Andreas > > -- > ------------------------------------ > Dipl. - Phys. Andreas Michalowski > Institut für Strahlwerkzeuge (IFSW) > Universität Stuttgart > > Pfaffenwaldring 43 > D-70569 Stuttgart, Germany > Phone ++49-(0)711-6856-9735 > Fax ++49-(0)711-6856-7244 > e-mail: [email protected] > http://www.ifsw.uni-stuttgart.de > ------------------------------------ > > > _______________________________________________ > 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
