Re: [eigen] a couple of RFCs |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] a couple of RFCs*From*: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>*Date*: Thu, 13 Aug 2009 10:30:18 -0400*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 :content-transfer-encoding; bh=HmCzTEbEQvpIXTfpPt3PlxisTAtvVnjyXDiRQiqhbd0=; b=eBceX+CFSo+zybmO9e0QO20VPah049XmUJV9sJMwHnSVA3J5ywfm9sdMGHhm/PwsMA MXD3dyJRG/cpsSW4xdShgXdCs4tYObjr5UKj5PTn6eKpSdm6XujOtNKDt7xHH3tWx0fW deJvBBaraR42joSqXZb7FUypEJ3xFIjiuakVE=*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:content-transfer-encoding; b=nA2M9h3YyCMmY0ObflKf2TNCcHkZVJ9WwCxMinly6EwkBwaTioKRAeLMj3tlvJPo3Q 2w3xltLR92QqltWeeWpZM5YiiWOWomS7BpSB7x99PHf7rr4Z3hEX+dKCGs66Eix92/jo L5MUrG9Yg8KsECR+cHwKmiBgPTf0MTObu8cIA=

ok, it occured to me that the dummy values returned are probably a default that needs to be overridden by adding a specialization of numeric_traits for std::complex. it seems that at least gcc doesn't provide such a specialization. so the other solution is to add our own partial specialization for std::complex<T>. do you prefer this approach? Benoit 2009/8/13 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>: > ok, i have done the changes in IO.h, but for machine_epsilon I have a > big problem. > > the problem is that at least with gcc-4.4, std::numeric_traits is > broken for std::complex. Specifically: > > std::numeric_limits<std::complex<float> >::epsilon() > > returns the zero complex number (0,0) > > There's a twofold problem, first it should be 1e-7 instead of 0, > second in order to be usable directly this should be a real number. > > The only solution i can see is to go for the other solution, keep > machine_epsilon and make it a wrapper around numeric_limits whenever > possible. > > ideas? > Benoit > > 2009/8/12 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>: >> On Wed, Aug 12, 2009 at 11:34 PM, Benoit Jacob<jacob.benoit.1@xxxxxxxxx> wrote: >>> Hi, >>> >>> 1) we currently have a template machine_epsilon<Scalar>() that is >>> redundant with std::numeric_limits at least for standard numeric >>> types. >>> Should we: >>> a) keep our own machine_epsilon<Scalar>(), and make its >>> specializations for standard types be wrappers around >>> std::numeric_limits? >>> or >>> b) remove machine_epsilon<Scalar>() and instead use >>> std::numeric_limits directly? This would require the user to add >>> custom specializations of >>> std::numeric_limits if he wants to support custom numeric types. That >>> seems OK, right? Also note that in StableNorm.h we're already using >>> std::numeric_limits. >> >> I'd remove our custom machine_epsilon<Scalar>(), and instead use >> std::numeric_limits. >> >>> 2) in IO.h, by default we output matrices with a "default format" that >>> uses 4 digits precision. This has repeatedly annoyed people, as they >>> would expect >>> cout.precision(n); >>> cout << matrix; >>> to work. I suggest that the default value for "precision" be -1, and >>> that this special value means "use the current precision of the >>> stream". >>> Worse: we apply the precision to the stream and don't modify it back >>> to the original value, so outputting a matrix to a stream has the very >>> unexpected effect of altering its precision. OK to change that so we >>> save and restore the stream precision? >> >> ok to have a default precision to -1 and ok to save and restore when >> precision!=-1 >> >>> Benoit >>> >>> >>> >> >> >> >> -- >> Gaël Guennebaud >> Iparla - INRIA Bordeaux >> (+33)5 40 00 37 95 >> >> >> >

**Follow-Ups**:**Re: [eigen] a couple of RFCs***From:*Gael Guennebaud

**References**:**[eigen] a couple of RFCs***From:*Benoit Jacob

**Re: [eigen] a couple of RFCs***From:*Gael Guennebaud

**Re: [eigen] a couple of RFCs***From:*Benoit Jacob

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] a couple of RFCs** - Next by Date:
**Re: [eigen] a couple of RFCs** - Previous by thread:
**Re: [eigen] a couple of RFCs** - Next by thread:
**Re: [eigen] a couple of RFCs**

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