Hi Craig: How about a nice, shiny new FFT implementation with a new name and a deprecation warning for the old stuff? I've got some code depending upon the old stuff and would like to be eased off it. That said, it was difficult to get my code working with the old implementation and would like to see some clean-up done.
Thanks much!!! --Doug [email protected] Software Engineer IV UCAR - COSMIC, Tel. (303) 497-2611 On Fri, 27 Mar 2009, Craig DeForest wrote: > I've been meaning to overhaul the internal FFT code for a long time, > but just hit my threshold to do so. The current built-in code has > some sort of size limit near 2k x 2k, above which the transformed > variables always end up full of NaN. This makes it impossible to use > the FFT method in "convolveND" for large images. > > There are other complaints about the internal FFT code: it always acts > in-place (destroying its original variable) and it doesn't support a > real-only transform. > > What's the consensus on how to overhaul FFT'ing? I am hesitant to > ditch the internal FFT code entirely, because it's nice to have an > internal fallback from the rather nice FFTW library (and hence avoid > yet another dependency for basic operations like convolution). > > So long as I'm diving into the code, I would like to make the basic > "fftnd / ifftnd" inplace aware in the modern sense, so that in the > default case they return their result in the usual way (rather than > always operating in place). That might break a number of older scripts. > > Cheers, > Craig > > > _______________________________________________ > PDL-porters mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
