Re: [eigen] 3.0.1 released!

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


Very good point. Actually, we already had explicit scalar conversions
everywhere in Eigen, and David's change was only about a few remaining
spots.

Actually keep plain constant is not satisfactory either and leads to
several issues.

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 ?

gael

On Tue, May 31, 2011 at 10:17 AM, Pavel Holoborodko
<pavel@xxxxxxxxxxxxxxx> wrote:
> II.
> 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
> JacobiSVD.h):
> (a)
> 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
> (b)
> rot1.c() = RealScalar(1) / sqrt(1 + abs2(u)); //was
> rot1.c() = RealScalar(1) / sqrt(static_cast<RealScalar>(1) + abs2(u));
> //became
> (c)
> 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.



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