On Fri, 27 Mar 2009, 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.
> >
> > 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.
>
> 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?
My imagined interface would be something which accepted k (by l (by
m (...))) PDLs, of real or complex [1] and returned PDLs
of k (by l (by m (...))) of complex.
[1] might just be too irritating to program, maintain, etc., and if
one has to call something to make the real PDLs into complex in
the first place, then that would be relatively easy to debug. One
might accept combining 2 same-sized real PDLs into one complex one.
So they'd be PDLs of complex. One could then do all the built in
iteration to extract the reals, or imaginary parts, or magnitudes to
PDLs to one's heart's content, without trying to figure out which
dimensions change in the process..
Does that sound sensible? I've not been doing much with Perldl of
late so have forgotten a lot of the conventions, so I can't give you
pseudocode at the moment, to describe the interface.
If the code can save us "all that tedious mucking about in
hyperspace" to get the reals and imaginaries in the right places,
people could concentrate on what they are actually using this for.
I feel that this is in the spirit of Perl as well, allowing one to
glue all those disparate things together into a cohesive whole where
the communication with the details is simplified. Not having to
juggle awk, sed, and /bin/sh to get things done, whilst keeping some
of the Unix flavour was a pleasant experience. But one can't get
more subjective than that sort of opinion, so there are probably
strong arguments for other styles.
>
> Cheers,
> Craig
Thank you,
Hugh
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
