Re: [eigen] mpreal + MatrixFunctions

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

some warnings:

In file included from ../../unsupported/Eigen/MPRealSupport:33:0,
                 from mpreal_support.cpp:2:
../mpreal/mpreal.h:282:35: warning: type qualifiers ignored on function
return type
In file included from ../../unsupported/Eigen/MPRealSupport:33:0,
                 from mpreal_support.cpp:2:
../mpreal/mpreal.h:2182:42: warning: type qualifiers ignored on
function return type
../mpreal/mpreal.h:2574:21: warning: unused parameter ‘rnd_mode’
../mpreal/mpreal.h:2579:21: warning: unused parameter ‘rnd_mode’
../mpreal/mpreal.h:2584:21: warning: unused parameter ‘rnd_mode’
../mpreal/mpreal.h:2589:21: warning: unused parameter ‘rnd_mode’
../mpreal/mpreal.h:2594:21: warning: unused parameter ‘rnd_mode’
../mpreal/mpreal.h:2599:21: warning: unused parameter ‘rnd_mode’
In file included from mpreal_support.cpp:45:0:
mpreal/dlmalloc.c:1270:2: warning: extra ‘;’
In file included from mpreal/mpreal.cpp:61:0,
                 from mpreal_support.cpp:47:
mpreal/dlmalloc.h:559:2: warning: extra ‘;’
In file included from mpreal_support.cpp:47:0:
mpreal/mpreal.cpp:362:13: warning: unused parameter ‘b’
mpreal/mpreal.cpp:362:13: warning: unused parameter ‘mode’
mpreal/mpreal.cpp:540:8: warning: unused parameter ‘old_size’
mpreal/mpreal.cpp:545:6: warning: unused parameter ‘size’

gael.

2011/8/26 Pavel Holoborodko <pavel@xxxxxxxxxxxxxxx>:
> 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:
> https://bitbucket.org/advanpix/nika
>
>
> 2011/8/24 Pavel Holoborodko <pavel@xxxxxxxxxxxxxxx>
>>
>> Make sure to use the latest version of mpreal from here:
>> https://bitbucket.org/advanpix/nika
>> 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.
>> Thanks.
>> 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.
>>>
>>> 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
>>>
>>>
>>>
>>
>
>