Re: [eigen] Proposal: Include Constants to NumTraits

[Pavel Holoborodko <pavel@xxxxxxxxxxxxxxx>]

 @ "if feature is already well covered by boost then I don't see a huge need for us to do a clone." 

Boost (and even std) also cover machine epsilon and other numerical scalar's aspects.

Nonetheless, in order to be self-consistent Eigen handles them independently - which is a right thing to do.

Same time taking care of math. constants is unavoidable question if we want to write really scalar-agnostic math. code. 

We don't have to cover many of them :), just the major ones. This precedent and guideline will allow developers to add other when needed.  

As for literals - I think we don't have to handle them specially. 

Just to require that custom scalar types should support arithmetic operations with built-in integer and double types. 

This will automatically cover of all the most frequent cases when we use integer constants, like 1/x or else. 

This also will allow to avoid code cluttering with Scalar(1)/x as we do now. 

Besides making code clean, expressions easily copy-able and type-agnostic this requirement will give us opportunity for optimization. 

For example, arithmetic operations with multiple precision arguments are generally very slow. But if it is known that one of the arguments is integer - operation can be done much faster. With Scalar(1)/x we kill this possibility and actually encourage badly designed custom scalar types.

Still "true" floating point literals, like 1/3 should be re-written as Scalar(1)/3, but we do this already anyway.

On Sat, Apr 7, 2012 at 5:00 AM, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

On a similar topic, NumTraits could provide a "Constant" type to be
used to cast constant numbers like 0, 1, 2, 0.5, etc. instead of using
Scalar which can be significantly more expensive for some scalar
types.

gael.

On Fri, Apr 6, 2012 at 9:57 PM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
> Hi,
>
> I guess the list of such constants can be very large to cover all
> application domains, so I'm not sure that's the scope of Eigen.. The
> idea is to have the constants that are needed for Eigen's algorithm
> only, and if that feature is already well covered by boost then I
> don't see a huge need for us to do a clone.
>
> cheers,
> gael
>
> On Fri, Apr 6, 2012 at 6:24 AM, Pavel Holoborodko <pavel@xxxxxxxxxxxxxxx> wrote:
>> Eigen is well designed to be invariant of scalar types.
>>
>> However I think there is one point for improvement - mathematical
>> constants.
>> They tied to scalar type (to its precision,  e.g. double vs. multiple
>> precision) and frequently needed in computations.
>>
>> Now, in true generic code in order to use matching-to-scalar constant we
>> have to do something like: pi = acos(Scalar(-1)) (FFT module).
>> Obviously this can (and should) be improved.
>>
>> We already handle machine epsilon by NumTraits. Why don't we include other
>> constants to NumTraits?
>> So that we can use them as follows
>>
>> typedef typename MatrixType::Scalar Scalar;
>> typedef typename NumTraits<Scalar>::Real RealScalar;
>>
>> const  RealScalar Pi      =  NumTraits<RealScalar>::Pi();
>> const  RealScalar Euler   =  NumTraits<RealScalar>::Euler();
>> const  RealScalar Log2    =  NumTraits<RealScalar>::Log2();
>> const  RealScalar Catalan =  NumTraits<RealScalar>::Catalan();
>> ...
>>
>> // Use constants in the code below
>> // ...
>>
>> This would make writing generic code much easier (and code will be cleaner).
>>
>> This is especially important for multiple precision types - where computing
>> of const. takes a lot of resources.
>> Additional layer of abstraction will allow us to cache const. without
>> recomputing them every time.
>>
>> For built-in scalar types these functions will be one-liners without any
>> overhead.
>>
>> Also it has sense to include Inf(), Nan() as special values (similar
>> to std::numeric_limits<Scalar> ).
>>
>> Would appreciate any comments.
>>
>> (Boost has similar library - e.g. boost::math::constants::pi<Scalar>();)