Re: [boost] FFT

From: John Suters (johnds_at_[hidden])
Date: 2001-10-31 15:29:50

> I don't think that this is the right signature. It's not in keeping
> with the STL. First of all, I think that the transform should be an
> algorithm, not a class. Second, it should take iterators, not
> containers. Thus, in keeping with the STL, it should probably be:
>
> template<class ForwardIterator, class OutputIterator>
> void fast_fourier_transform(ForwardIterator start, InputIterator end,
>                             OutputIterator out)
>
> This avoids the whole need for default template arguments, and allows
> one to non-destructively transform if desired, or convert only a
> portion of a sequence. And I doubt it would be hard to convert your
> existing implementation to this signature...

I agree in principle. The reason I thought of it this way is so that I could
use std::complex to make it clear that I wasn't going to start mucking
around converting doubles into complex, or ints into complex and so on. I
guess if the iterator doesn't point to a complex then it won't compile...

I'm not sure what you mean by non-destructively transform.

>
> One caveat: be sure that your implementation internally is going to
> work for generalized numeric classes. You may well need a way to say
> math_constants::pi<type> (where type might be std::complex<boost::ration
> al<int> > for example) or the equivalent -- I think this is a great
> example in practice that could help clarify all the recent discussion
> of how to specify the interface to constants...

Good idea. It's currently a hard coded number.

>
> > The bool parameter on the transform specifies whether we're taking
> > the inverse or not, and defaults to false.
>
> I'm not sure that this is the best from a user's POV. I think I'd be
> continually looking up which value is the one I want. I'd prefer to see
> two functions (fft, inverse_fft) which are implemented in terms of the
> same function with a +- toggle. As an alternative (or as an additional
> user-visible interface for use when you really want to toggle at
> runtime) you could provide a named enum instead of a bool.

Yes. At one stage I had a transform and an inverse_transform function in the
class. Can't remember why I removed the inverse.

>
> You should consider also whether you want to make allowances for the
> more general fourier transform case when the size of the output range
> of interest does not equal the size of the input range.

Hmmm. Perhaps I'm out of my depth here. My function always extends the
vector to the minimum power of two to contain the input. Is this what you
mean by this?

>
> George Heintzelman
> georgeh_at_[hidden]
>
>
>
> Info: http://www.boost.org  Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>