[phobos] FFT

[David Simcha]

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.
>
> 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
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>>
>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
>>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>