| Re: [eigen] mpreal + MatrixFunctions |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
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.
Greetings,
Chen-Pang
於 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
> http://eigen.tuxfamily.org/dox-devel/unsupported/group__MatrixFunctions__Module.html#matrixbase_matrixfunction
>
> 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