On Fri, Apr 6, 2012 at 9:57 PM, Gael Guennebaud
> 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.
> On Fri, Apr 6, 2012 at 6:24 AM, Pavel Holoborodko <pavel@xxxxxxxxxxxxxxx
>> Eigen is well designed to be invariant of scalar types.
>> However I think there is one point for improvement - mathematical
>> 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
>> 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>();)