Re: [eigen] FFT update |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] FFT update*From*: Rohit Garg <rpg.314@xxxxxxxxx>*Date*: Sun, 24 Jan 2010 14:58:38 +0530*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 :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=bvSf9U62pN4lT2b/9vhtRiSesHp7LIv5ooSc7zUZkY4=; b=CeBZLAeZTbIGpauaHdPmvHEKqrmnjZ7NgKnNKpa6pEGvUxwPupNofrjhTKfRLbKmUw gy410a3PswdbNtw969Rh9a6ARwAWR0JUemfpuhCaMCRyKBbtS6kI64j4o4RztV52VmTY ZzoRGAgb9gI1BJ5K9MlGOZXwmS/LrJlNz4Oq8=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=C9a3xEfb7YfvDYD0UoPxic3oaTuM1BF5qbR+r9PpCk/eI7pOh1Vxj4EsH+Qhe/2Eue vu2LJdDgbxySTe/zM0ueMvfjg1LhGyYkdyOUxVJavsSkBbQlr93ZaIGwRhwytrAEiGif 7D9MK36IY7NyTpkKxU0Pz47VDOsGEceV4IFlY=

On Sun, Jan 24, 2010 at 12:33 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote: > 2010/1/24 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>: >> 2010/1/23 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>: >>> By the way, this "ReturnByValue::coeff() crashes by infinite >>> recursion" thing is really ugly, I wonder how to fix it!! >>> >>> C++0x at last brings the ability to remove a base class function from >>> a derived class... I wonder how to implement that idea in C++98. Is >>> that enable_if? >> >> Forget enable_if, forget C++0x, forget boost, i'm your new idol. Alrighty, :) >> >> If we want to make sure that using ReturnByValue::coeff() generates an >> error at compile time without generating an error until it's actually >> used, we can define a class: >> >> class Unusable >> { >> // implement copy ctor/operator as private to disable them >> Unusable(const Unusable&) {} >> void operator=(const Unusable&) {} >> }; >> >> We then let ReturnByValue::coeff() return that: >> >> class ReturnByValue >> { >> ... >> Unusable coeff(int, int) { return Unusable(); } >> ... >> }; >> >> The result is that when the user does e.g. >> x = retval.coeff(i); >> or >> x = retval.coeff(i) + 123; >> he gets compilation errors. >> >> Just doing >> retval.coeff(i); >> doesn't give an error, but that should be optimizable as just a NOP anyway. >> >> With this, i go to bed full^Wproud of myself. > > Ah, this needed a little adjustment. Doing > Unusable coeff(int, int) { return Unusable(); } > was already copying a Unusable object, the return value of that > method. While the trick still worked with GCC, it was probably > fragile, and the error wasn't very explicit. > > Here is a much better variant: > const Unusable& coeff(int) const { return *reinterpret_cast<const > Unusable*>(this); } > > Now this method is really not using any Unusable constructor/operator. > > The error message when I do: > float x = rotate(v).coeff(0); > is now just: > returnbyvalue.cpp: In function ‘int main()’: > returnbyvalue.cpp:122: error: cannot convert ‘const > Eigen::Unusable’ to ‘float’ in initialization > > ok to commit? I'd suggest that since you are *forcing* a compiler error here, it would be better to add a long descriptive error to go with it. Some thing like this http://eigen.tuxfamily.org/index.php?title=FAQ#I_need_help_with_compiler_errors.21 > > Benoit > >> >> Benoit >> >>> >>> Benoit >>> >>> 2010/1/23 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>: >>>> Hi, >>>> >>>> Here's an example: see attached file. >>>> Enjoy!! >>>> Benoit >>>> >>>> 2010/1/22 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>: >>>>> ok let me write an example... >>>>> >>>>> 2010/1/22 Jitse Niesen <jitse@xxxxxxxxxxxxxxxxx>: >>>>>> On Fri, 22 Jan 2010, Benoit Jacob wrote: >>>>>> >>>>>>> Our "policy" is now: >>>>>>> - try to return by value, optimizing with the ReturnByValue class, >>>>>>> wherever possible; >>>>>>> - otherwise you can just use references. >>>>>> >>>>>> Can somebody please explain how to use the ReturnByValue class? >>>>>> Or should I just extrapolate from the source code? >>>>>> I could not find any documentation. >>>>>> >>>>>> Jitse >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > > > -- Rohit Garg http://rpg-314.blogspot.com/ Senior Undergraduate Department of Physics Indian Institute of Technology Bombay

**Follow-Ups**:**Re: [eigen] FFT update***From:*Benoit Jacob

**References**:**[eigen] FFT update***From:*Hauke Heibel

**Re: [eigen] FFT update***From:*Mark Borgerding

**Re: [eigen] FFT update***From:*Hauke Heibel

**Re: [eigen] FFT update***From:*Benoit Jacob

**Re: [eigen] FFT update***From:*Jitse Niesen

**Re: [eigen] FFT update***From:*Benoit Jacob

**Re: [eigen] FFT update***From:*Benoit Jacob

**Re: [eigen] FFT update***From:*Benoit Jacob

**Re: [eigen] FFT update***From:*Benoit Jacob

**Re: [eigen] FFT update***From:*Benoit Jacob

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] FFT update** - Next by Date:
**Re: [eigen] matrix::linspace** - Previous by thread:
**Re: [eigen] FFT update** - Next by thread:
**Re: [eigen] FFT update**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |