|Re: [eigen] Eigen::FFT and Eigen::Complex in repo|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Eigen::FFT and Eigen::Complex in repo
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Thu, 22 Oct 2009 12:17:27 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=/cipVwpqvu62nUsmOTPnTsWq8pRiecDL3kzciJyBjd0=; b=fQZSNVr2rGjiEpHJhhtg2sa9Di+ZK8ZZGJ27+Ki18wzAFzBaiys/C1aixXJVBEctCF HtdkDBx9LmkWEvB0SHAPHXWkPAsm2BhZV8MczysxA+A5ki/WXcMMxR0keriOwn6JuCtX tr8vP9CarQdb2m6i1s/kxqLHBmIQXjWwvsspE=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Kh+hKVKOJJNG4bXJGctztjoTSCUS3VO7ww/Dk6vdSDbqN+pYinnKP3HOjFFcI978L0 KOJBHoFWignyU31vrLJydkXZc9lyRL5/WwoOE/w73mQZZjpHxasNinuHgBPkxeqpISJH FE1VGFf7rnB3cPX10bsLKiFUZu6ICwG5wxV0E=
On Wed, Oct 21, 2009 at 4:15 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
2009/10/21 Mark Borgerding <mark@xxxxxxxxxxxxxx>:
> Benoit Jacob wrote:ah, good point, so nevermind this idea.
>> FFT line 48:
>> template <typename _Scalar,
>> typename _Traits=DEFAULT_FFT_IMPL<_Scalar>
>> First, why call it Traits when Impl seems to be what it really is?
>> Also, here you're passing _Scalar twice, and are using a macro.. You
>> can improve on both fronts in 2 ways:
>> * either you let _Scalar be deduced from _Impl
> My thinking behind the dual argument was to allow quick and easy declaration
> from the user standpoint.
> where the implementation that gets used is the best available at compile
> time. Rather than
> FFT< ei_kissfft_impl<float> >
> which seems verbose and inflexible
> (also notice the error prone "> >" )
Yes it now seems like the way to go!
> I agree that the use of preprocessor macros to define the default is less
> than ideal. Perhaps it should not default to the best available, but rather
> to whichever library is requested via preprocessor definitions.
>> * or you can keep the _Scalar parameter and let _Impl be a template
>> template parameter:
>> template <typename _Scalar, template<typename t> class _Impl>
>> class FFT
> I have not done this before. I will give it a try.
I'm not sure about that, because with that solution you wont be able to declare backends with more that one template parameter. Think, e.g., about a fixed size backend or any other backend which could take advantage of compile time options...