pfft 0.1

jerro a at a.com
Fri Jul 20 17:02:18 PDT 2012


On Friday, 20 July 2012 at 23:36:37 UTC, bearophile wrote:
> jerro:
>
>> I'm announcing the release of pfft, a fast FFT written in D.
>
> Everything looks nice. Are you using "in", 
> pure/nothrow/immutable/const enough?

Not yet, but I plan to add those.

> 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.

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.


> Bye,
> bearophile




More information about the Digitalmars-d-announce mailing list