Re: [eigen] mpreal + MatrixFunctions

[ Thread Index | Date Index | More Archives ]

With the help of Philippe Marti I've fixed many issues related to x64 support on GCC. 

I would appreciate any feedback and tests for the latest MPFR C++ version from repository:

2011/8/24 Pavel Holoborodko <pavel@xxxxxxxxxxxxxxx>
Make sure to use the latest version of mpreal from here:

It includes many bug fixes, new math functions (even exotic one, like asech), x64 support and lots of other improvements.
Also it has updated MPRealSupport for integration to Eigen.

I plan to extend C++ multiprecision numeric types in future (with mpcomplex and mpint).
So I gave library more general name (Nika) instead of very specific MPFR C++ or mpreal.

Everyone welcome to contribute.


2011/8/23 何震邦 <jdh8@xxxxxxxxxxxxxx>
Yes, you are right! Using std::exp is faster and more accurate than
using both cosh() and sinh(). Sorry for not aware of this. Besides, I'm
going to make a close look into mpreal compatibility. Please reject pull
request #4 and I'll make a better one soon.


於 2011/8/23 下午 08:15, Jitse Niesen 提到:
> On Sun, 21 Aug 2011, 何震邦 wrote:
>> Thanks for your suggestions! I've written a computeUV() to take care of
>> all non-specialized types (inclusive of mpfr::mpreal), while
>> computeUV(float), computeUV(double), computeUV(long double) are still
>> there for built-in real scalars. It runs smoothly so far. :)
> Can you explain to me how to use this with mpfr:mpreal? When I tried
> it, I get a compiler error that computeUV(....) in
> MatrixExponential.h:203 is ambiguous. There also seems to be a typo on
> lines 305 and 306 (m_M instead of A).
> Additionally, I'm not sure overloading computeUV() is the correct
> approach. Your patch computes A.sinh() and A.cosh(): two calls to
> A.matrixFunction(). Instead, we can compute the exponential with only
> one call to A.matrixFunction(); see the example at
> This is probably faster and more accurate.
>> 於 2011/8/21 上午 06:14, Gael Guennebaud 提到:
>> > Actually I think that this computeUV() method should be implemented in
>> > a different way: first, I don't see why it has an argument. Second,
>> > since its implementation really depends on the scalar type, it should
>> > rather call a free function (or a static method of an helper class)
>> > that one can specialize for his own scalar type.
> You're probably right. It was the first time that I really used Eigen
> and templates. The function has an argument to select the correct
> overload; a templated function is a cleaner solution. I don't quite
> remember why I did not implement it as a free function, but I probably
> wanted to have everything in one class. I now see that this causes
> problems when one want to support a custom scalar type, so I will
> change it in the future. Thanks for the suggestion.
> Jitse

Mail converted by MHonArc 2.6.19+