Sounds ok.
David Simcha wrote:
I guess my response to this is that, IMHO, the ridiculously simple API
I have now is an absolute must-have at least as a "simple things
simple" subset of a richer API anyhow, so I don't see this as a
problem. For example, if we were to get fancier and start having plan
objects, support N-D transforms, etc., I would still insist that you
could get reasonable results in a single line by simply doing
fft(myRange); without explicitly creating a plan, specifying a
dimensionality, or anything else a more complex API might allow.
Furthermore, I'm thinking about how N-D FFTs would be supported, and I
figure the best way would probably be to just introspect the object at
compile time anyhow. Right now, anything but a range of numeric types
or a range of Complex doesn't compile. This would be expanded to
allow matrices and do what the user means, or allow ranges of ranges
and do what the user means, or allow ranges of ranges of ranges of
ranges (4-D transform) or whatever.
On 8/2/2010 10:20 PM, Walter Bright wrote:
Can we use what the best FFT's provide as a guide to what the API
should cover? I think it's fine if it's something we can grow into, I
just don't want to keep doing what we've done too often already -
chuck the old one and break everyone's code.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
