|Re: [eigen] 3.0.1 released!|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] 3.0.1 released!
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Tue, 31 May 2011 19:18:44 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=ZGIb3sbxQbIixHRnS5LkVpmiLK85V+Qh+sMREtQ99rk=; b=RKdEhT5Ppg9c+vhNPax0nMji5q76LbviLr6BlHra/S38BcTRY1MZ7dvmu1AMilPYKd VDaCO4UTq3Qi8hCYhDdS/UW/qaRakP1SbytXK7HApk3Azfx069I9jPE6hjB4dZF5nMcE 7kHBfHUKW8lrPUl8YcgRhnXwc6Mha4G6s4+Bo=
- 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=tUq8kgdX0/E4Qg/VzAXeF1kBc30mnB2RluoBvq2wGjGul1Vi1dyxBxSwbl1eWqqBuY LNlJ5a62STnQ5gAJ3ca095khj/C8Kr9/xC4raNPwxhVFVsFWlwhi0qbbBQlvnnTVEEws s0OeNXJet/PRFM8BbiYKWhddRcWIaxrkwbwsI=
Very good point. Actually, we already had explicit scalar conversions
everywhere in Eigen, and David's change was only about a few remaining
Actually keep plain constant is not satisfactory either and leads to
The best would be to deffer this to NumTraits, and I see two options:
- introduce a new type in NumTraits for real constants like typedef
double RealConstant ;)
- add a static function XXX makeConstant(const YYY& val);
The advantage of the former is that one has a type in hand to can
declare a constant variable.
The advantage of the second option is that one can have overloads of
makeConstant to somehow allows for multiple "RealConstant", but is
there any use case for that ?
On Tue, May 31, 2011 at 10:17 AM, Pavel Holoborodko
> I would like to express some critic regarding changes introduced by David H.
> Bailey in commit 4091 and others (These particular examples are taken from
> RealScalar d = ...
> rot1.s() = d > 0 ? 1 : -1; // was
> rot1.s() = d > static_cast<RealScalar>(0) ? static_cast<RealScalar>(1) :
> static_cast<RealScalar>(-1) ; // became
> rot1.c() = RealScalar(1) / sqrt(1 + abs2(u)); //was
> rot1.c() = RealScalar(1) / sqrt(static_cast<RealScalar>(1) + abs2(u));
> rot1.c() = 0; //was
> rot1.c() = static_cast<RealScalar>(0); //became
> Well designed custom scalar types include routines specifically optimized
> for the cases when one of the operands is of standard type.
> In these cases math. operations can be done much faster. This is also true
> for conditional operations (<, >, etc.) and copy constructors.
> For example, when we want to add integer to arbitrary precision number:
> mpreal a;
> // compiler assumes 1 is of int type and calls optimized +=(int) operator,
> // it is very easy to add simple int to arbitrary precision number.
> // no additional memory allocations, constructor call, etc.
> a += 1;
> // unnecessary call of constructor/memory allocations,
> // but the worst - now we have to use heavy artillery to add numbers,
> // since they both of arbitrary precision now - optimization is disabled
> a += mpreal(1);
> Actually huge part of arbitrary precision libraries are devoted to such
> optimized cases (just look to MPFR low level API) - otherwise we get
> significant drop in speed.
> There is only one case when we need such conversion, when operand is
> floating point literal, e.g.
> a += 3.01; // incorrect, since 3.01 is converted to double first.
> a += mpreal("3.01"); // correct. string are being translated directly in
> multi-precision number.
> In upcoming C++0x string wrapping won't be necessary anymore - we will be
> able to create literals of custom type.