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.
David Simcha wrote:
Well then we would need to define an API for matrices or something to
define how multidimensional transforms are going to work. In dstats,
I've just been using ranges of ranges or tuples of ranges because it's
available and works reasonably well, but I haven't really thought in
detail about whether this is the optimal solution.
Also, an N-D transform is apparently trivially implementable in terms
of a 1-D transform, so I don't know whether an API for this would be a
must-have.
On 8/2/2010 9:18 PM, Walter Bright wrote:
Walter Bright wrote:
The most important thing for a Phobos implementation of FFT (or any
other module) is getting the API right. Having that right means we
can always swap it out for a better implementation without breaking
user code.
For FFT this would mean looking at the best FFT implementations out
there to see what their API is. Phobos' should support a full feature
set, even if for now the implementation will throw exceptions for
things it doesn't support yet.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
