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)
I believe you are correct. That's what I get for not running pdldoc before replying. --Chris _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
