Re: [eigen] mpreal + MatrixFunctions

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


Thank you.

Maybe we just need to include <cstdlib> and use rand/srand from std:: namespace as before.

BTW, that branch of code is just for compatibility with old MPFR - where "true" multiprecision RNG wasn't implemented yet. If you use random numbers in your code it might have sense to upgrade MPFR to the latest version.

On 26.08.2011, at 19:58, Cannelle Bertrand <bertrand.cannelle@xxxxxx> wrote:

Hi

I have a pb with file mpreal.h

./mpreal.h:3073: error: ‘srand’ is not a member of ‘std’
./mpreal.h:3074: error: ‘rand’ is not a member of ‘std’

**************************************************************
#else
    if(seed != 0)   std::srand(seed);
    return mpfr::mpreal(std::rand()/(double)RAND_MAX);
#endif
**************************************************************

but if I had this line at the beginning of mpreal.h
********************************************************
 #include <stdlib.h>
********************************************************

and I patch with
**************************************************************
#else
    if(seed != 0)   srand(seed);
    return mpfr::mpreal(rand()/(double)RAND_MAX);
#endif
**************************************************************

And it works



Le 26/08/2011 12:00, Pavel Holoborodko a écrit :
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.

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





<bertrand_cannelle.vcf>


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/