pfft 0.1

[Andrei Alexandrescu]

On 7/20/12 8:02 PM, jerro wrote:
> On Friday, 20 July 2012 at 23:36:37 UTC, bearophile wrote:
>> Is it worth changing the Phobos API to something similar to this API?
>
> Pfft already includes an API that is compatible with the
> Phobos one (pfft.stdapi). But I don't think it makes any sense
> to change the Phobos API to something like pfft.pfft. The main
> difference between the two is that std.numeric.Fft uses
> interleaved format for sequences of complex numbers and
> pfft.pfft uses a split format. Interleaved format is more
> convenient in most cases and I think it's more intuitive too.
> The FFT in Phobos also works on ranges, while pfft.pfft only
> works on aligned arrays.
>
> The only reason the pfft.pfft works the way it does is that it
> is supposed to be an interface to the underlying implementation
> with no loss of performance and that is how the implementation
> works. Even if the implementation in Phobos did use split
> format, I think it would still be better to use interleaved
> format for the API. It's just about 30% slower and I think that
> a nice API is more important for the standard library than a 30%
> difference in speed.

This all is very interesting. Even considering all potential issues and 
incompatibilities, it might be great to look into integrating Fft into 
Phobos. Do you think it would work to add it as a "high-speed 
alternative with different format and alignment requirements"? Offhand 
I'd think someone using the FFT is generally interested in speed, and a 
30% margin is sensible since the algorithm might be most of some 
applications' run time.

> There is one more important difference in the API between
> std.numeric.Fft and pfft.pfft. With Phobos you can use one
> instance of Fft for all sizes and types. With pfft.pfft, the Fft
> class is parametrized with a floating point type and you need a
> different instance for each size. I think what Phobos does in
> this case is wrong. The fact that one class works on all
> floating point types results in very poor precision when
> the data consists of doubles or reals. I guess that precomputed
> tables are stored as floats. You could only fix that by saving
> them as reals, but that would probably hurt performance quite
> a lot. The fact that one instance can be used for multiple sizes
> would be a problem if we wanted to change an implementation since
> not all FFT implementation can use one precomputed table for
> different data sizes.

Do you think Phobos can be fixed in a backwards-compatible way (e.g. 
provide a template and alias it to the old name)?


Andrei