Craig DeForest wrote: > On Mar 27, 2009, at 12:11 PM, Hugh Sasse wrote: > > >> Well, since I primarily interested in N dimensional FFTs I'm capable >> of getting myself in enough knots dimensionally without having to >> track which slices are not actually slices, but what would be, in >> an Object Oriented perspective, properties of a complex number. >> Part of the point of OO interfaces was to shield us from this >> indexing stuff which is so easy to get wrong. >> >>
I would like to see PDL become complex aware---even if there are alternative representations allowed. >> Maybe another interface could meet the needs of people with my kind >> of expectation. Simplicity is difficult to design, and when you >> have backwards compatibility and performance to think of, it is even >> harder. So I don't know what is achievable with the time * energy >> available. But if you bear future simplicity in mind you might be >> able to shape things so that it make the job easier for the next >> phase. >> > The modest FFTW3 proposal from my previous response handles this transparently. > Hmmm... > > Well, adding inplace awareness will break old scripts anyway, and I've > not heard any objection to that yet. So long as we're breaking old scripts, > now > is a good time to overhaul for simplicity based on common usage patterns. In > Hugh's > Republic, how would fftnd work? > > I always had problems with the always inplace code of FFT. Routinely, I would forget to make a working copy and would end up trashing the input data... Throw in the lack of complex as an intrinsic PDL type and I got burned often. --Chris _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
