MPFR C++

Hello Mr. Holoborodko,
my g++ compiler (3.4.4 with cygwin) does not like your mreal.h. Your style to use a static class member as default value for a function argument as in
mpreal(const mpq_t u, mp_prec_t prec = default_prec, mp_rnd_t mode = default_rnd);
This causes the message
error: `default_rnd’ was not declared in this scope.
It is tempting and logical to use static data members for default initialization of function arguments but I found it always not to work with some compilers. So I eliminated it from the list of my personal idioms. Would be nice to have a gnu-compatible version of your mpreal – files.
Best wishes
Ulrich

Dear Mr. Holoborodko,
your wrapper seems to work like a charm together with eigen.

(See: http://eigen.tuxfamily.org/dox/CustomizingEigen.html#CustomScalarType)

Thanks,
Simon

Hi Pavel.
I must say your wrapper is fantastic. I really don’t imagine myself changing all my code to those criptic MPFR functions.

However, I must ask you something too:
When I use some mpfr function, using your wrapper, the result always has the same precision as the argument supplied to the function, if the argument is a mpreal. I know this is a MPFR behavior, and in MPFR you can change this. In your wrapper, there is a way to select the precision of the result, without regard the precision of the argument? I haven’t find one yet. By the way, I tried to use mpreal::set_default_prec(), but the behavior remains.

I’d really appreciate your answer.
See you later!

Hi Pavel!

Thank you for your wrapper, I find it extremely useful and intuitive.

Nevertheless, I have a problem. By running my code using the mpreal class and setting the precision to 64 bits via mpfr::mpreal::set_default_prec ( 64 ), I obtain different results from when I run it with standard C++ double precision (still 64 bits).

Is there an obvious reason for this behaviour, other than a possible mistake of mine?

Thank you for your attention,

Guido

P.S. The mpreal objects I use are created after calling mpfr::mpreal::set_default_prec ( 64 ).

Hi Pavel,

thank you very much for your prompt answer! I now understand why the results were different.

I would be grateful if you could answer another question: do you know if there is any arbitrary precision C++ wrapper/library that computes Sine and Cosine integrals – Si(x) & Ci(x) – efficiently, as defined in here http://en.wikipedia.org/wiki/Trigonometric_integral? I was thinking to just take GNU GSL source code for such functions and replace “double” with “mpreal”, but I guess it is not the best way to proceed. Another way could be to start from the Exponential Integral Ei(x) – which is included in MPFR – to obtain Si(x) and Ci(x) but the are complex numbers involved and I do not want to mess with them.

Thank you again,

Guido

Thank you for your answer.

Alas the MPFR port of GSL does not include the functions I am looking for. In the end I solved my problem in another way. I had to compute the difference between the cosine integral and sinc for very large arguments, and I needed high precision since Ci(x) ~ Sinc(x) when x is large.

However I found out that I could use series expansion. In fact it turned out that

CosIntegral[x] – Sinc[x] ~ (6/x^4 – 1/x^2) Cos[x] + (24/x^5 – 2/x^3 ) Sin[x].

Thank you anyway for the support!

Cheers,

Guido

Dear Pavel,

thank you for writing this great wrapper and putting up the link to already compiled GMP and MPFR.

I would like to ask you one thing. I tried the exaple code, that comes with your wrapper and as soon as I move any variable out of the main(), I get an assertion error in ini2.c (about precision I guess).

So this code …

mpreal x = "420.968746359948568";
	
int main(int argc, char* argv[]){
	mpreal::set_default_prec(128);
	...

generates the error, while this

int main(int argc, char* argv[]){
	mpreal x = "420.968746359948568";
	mpreal::set_default_prec(128);
	...

does not generate the error, even though in the second case the precision is set only after the init of X, which I though was be the problem in the first example. So, to sum it up, is there any way I can use global variables of mpreal type in my applications?

Thank you for a response in advance!
Daniel.

Hello, thanks for your nice software!

I’d like to use it for MPACK (MBLAS/MLAPACK).
http://mplapack.sourceforge.net/
How about wrapping MPC as well?

I prepared general (not very well one) for GMP.
http://mplapack.cvs.sourceforge.net/viewvc/*checkout*/mplapack/mpack/include/mpc_class.h?revision=1.5

any comment is really appreciated.

Thanks!

Hi Pavel, thanks for your comment!

I have already been using GMP via gmpxx.h. Above mentioned complex C++ wrapper is
based on GMP. Problem here is not so many functions, as you suggest.
Thanks for MPIR. I didn’t know about it. MPACK infrastructure is designed to be easy to
port to a multiple precision library. What I need are four types; “REAL”, “COMPLEX”, “INTEGER” and “LOGICAL”. If someone make a wrapper to MPFR, I can port to MPFR immediately.
I’d like to use MPFR for better calculation evaluation.

Anyway please take your time. Hope I can do some contribution to you.

Best regards,
Nakata Maho

Hi Pavel,
Really nice piece of work.

I have a couple of questions upon usage howerver. I am trying to assign a double value to an mp real and I get an exception.

mpreal::set_default_prec(128);
mpreal::set_double_bits(32); // I am assuming this is decimal places — please advice

mpreal d = 2.11 ;

terminate called after throwing an instance of ‘mpfr::conversion_overflow’

Is this correct? I would assume that I could assign a double to an mpreal.

Hello

I’m trying to use mfprc++ to build a high precision code do a massive computation. I settled everything had the mpfrc++ test work successfully. When try to compile my code I bumbed into this error:
error: conversion from mpfr::mpreal to int is ambiguous

this happen because I’m trying to promote an integer to mpreal. Is there any function does this promotion? I’ll be very thankful for any help

Thank you!
Bassam

Hello
I have tried to use MPFR C++ with Aigen but I have an error that I
cannot understand. I don’t know whether the problem comes from Eigen or from
MPFR C++.

My code runs correctly when the numerical type of the matrix is double but does
not work when the type is mpreal in Sparse Module.
Can you give me some hint about this error ?

Thank you for your answer.

Bertrand

To reproduce my bug, you can use this code

……

Hello Pavel,

thank you very much for a convenient C++ wrapper. The most appreciated part of your work for me is the integration between the Eigen matrix library and the MPFR arithmetic (currently I’m working on an algorithm dealing with matrices which are numerically very close to singular).

So, my question is about mpreal_eigen.h. As far as I can see, it explicitly instantiate a number of functions (for example, template mpfr::mpreal machine_epsilon()). Every translation unit of my program, which includes the file, receives a copy of that code. And a linker is not happy at all to see the duplicated symbols, when it tries to link the object files together (I use gcc 4.4.4 on Linux).
Could you suggest a solution/workaround for the problem?

Thanks.

But it gives another error:
||Warning: .drectve `/DEFAULTLIB:”LIBCMT” /DEFAULTLIB:”OLDNAMES” ‘ unrecognized|
and
mpfrc++\mpfr.lib(.\Win32\Release\round_prec.obj)|| undefined reference to `_alloca_probe_16’|

As I said the compiler that I am using is GNU GCC Compiler.
I dont know what Im doing wrong.
I have tried with the other option ‘win32_gmp_mpfr.zip’ and it gives the same errors.

Hi Pavel,

Ok, it works.
The problem I had was that I linked the libraries in CodeBlocks in a not properly order (it seems that is necesary include first ‘libmpfr.a’, second ‘libgmpxx.a’ and finally ‘libgmp.a’).
(Ok, I didnt want use the ‘make’ file).

A lot of recent discussion on this “board” concerns build issues with different compilers and platforms. Admittedly the makefile included in the mpfrc++ source tree is only the most basic, the only targets, for instance, being static libraries. To address these issues, I have uploaded a “Gnu-ized” version of mpfrc++ to sourceforge.

With this one can build and install the library with the familiar sequence:

./configure && make && sudo make install

Configuration options (see ./configure --help) provide a systematic way of passing compiler/linker flags and fine-tuning build specifications. In particular, it provides a painless way for building mpreal as a dynamic library on practically any platform.

The source code is taken from this website and released under the identical license.

Everything is in the /trunk branch of the repository. The SVN check-out command

svn co https://mpfrcpp.svn.sourceforge.net/svnroot/mpfrcpp/trunk [your-path]

will install the entire source tree in your-path.

By the way, this is not restricted to Intel’s compiler, Microsoft’s C/C++ Compiler Version 15.00.30729.01 for x64 also fails with the error below:

mpreal_eigen.h(51) : error C2143: syntax error : missing ‘;’ before ”template<''
mpreal_eigen.h(56) : error C2143: syntax error : missing ';' before ''template<''
mpreal_eigen.h(61) : error C2143: syntax error : missing ';' before ''template<''
mpreal_eigen.h(80) : error C2143: syntax error : missing ';' before ''template<''

More problems with Eigen & MPFR C++

When I try to assign the result of a coefficient-wise operation like pow:

typedef Eigen::Matrix<mpfr::mpreal, Eigen::Dynamic, Eigen::Dynamic> EigenMatrixMPReal;
...
EigenMatrixMPReal row_dest, row_i;
...
row_dest = row_i.cwise().pow(mpfr::mpreal(10.0));


The compilation dies with the error below. However, if I don’t do the assignment, the code compiles fine:

row_i.cwise().pow(mpfr::mpreal(10.0)); // this doesn't cause compilation errors

Changing from mpfr::mpreal(10.0) to 10.0 doesn’t make any difference

I’m using eigen 2.0.15 (latest stable)

Why is this happening?

— John

1>C:\Eigen\Eigen/src/Array/Functors.h(141): error: more than one instance of overloaded function "Eigen::ei_pow" matches the argument list:

1> function "Eigen::ei_pow(int, int)"

1> function "Eigen::ei_pow(float, float)"

1> function "Eigen::ei_pow(double, double)"

1> function "Eigen::ei_pow(long double, long double)"

1> argument types are: (const mpfr::mpreal, const mpfr::mpreal)

1> inline Scalar operator() (const Scalar& a) const { return ei_pow(a, m_exponent); }

1> ^

1> detected during:

1> instantiation of "Scalar Eigen::ei_scalar_pow_op<Scalar>::operator()(const Scalar &) const [with Scalar=mpfr::mpreal]" at line 75 of "C:\Eigen\Eigen/src/Core/CwiseUnaryOp.h"
.......

Hi Pavel,
I just tried using your wrapper with special functions from boost libraries and it looks like either your wrapper or boost bindings are flawed. Boost generally uses lexical cast in approximations of math functions (for example boost::lexical_cast<mpfr::mpreal>("12.2315")) and it looks like lexical cast fails to correctly create interpreter object through which it would stream data with << and >>.

If you are interested in maintaining compatibility with boost libraries, you can try to reproduce this condition and see what is causing it. The exception is “bad lexical cast: source type value could not be interpreted as target”. Versions of libraries used: mpfr – 3.0.1; mpir – 2.3.1; boost – 1.46.1. mpfr built form Visual Studio 2010 using Brian Gladman’s project files. The error is present in all configurations (Release and debug on both Win32 and x64).

Regards.

Dear Mr Holoborodko

not long ago albeit a newbie to OOP I found myself engaged in multiprecision calculus and your work happily found
appear to be a superb as quick start !
In order to implement complex numbers I boldly wrote complex (mpreal) u = new complex (mpreal) [xxx];
and all the ariphmetics remained alike but I found complex exponent 16 digits precision if written in exponential
form and of arbitrary precision if written as a sum of real and imaginary parts and the complex logariphm as well
Likely, I was to write my own complex sqrt function.
These things albeit no problem at all showed I might be having future troubles this way ahead .
I will be deeply indebted if you share your ideas of what they may appear to be and what my actions
should be in general cause I ‘ m a sort of newbie (hope not a noob though) in OOP.

Sincerely yours Valdes Coosk , Vilnius.

P S brackets enclosing mpreal type are of course correct ones . round brackets are used instead
cause they aren’t lost unlike angle brackets

Dear Pavel,
I’m using an old version of the Boost.Library UBLAS (1.42) and I’m programming a linear algebra program.
The fact is that the program compiles fine, but at runtime, even if I don’t call the function L1Norm(), I get the following error
../init2.c:52: MPFR assertion failed: p >= 2 && p >1))

See complete source code….

I really cannot understand where the problem lies… the real problem is that, since I’m working with sparse matrices I made a strong use of iterators in the whole of my program, so if dereferencing an iterator gives rise to a problem I’m in a really bad situation 🙂

Best wishes
Isaia

UPDATE:
I’ve discovered that if I access the matrix by A(rowindex,colindex) the problem does not occur.
The real problem is that accessing the matrix this way is way much slower than using iterators.

UPDATE2:
I also tried with the new libboost 1.46.1 and the wrapper for mpreal.
But I still get the same error at runtime.

Hi Pavel,
I am trying to use your code but the compiler is unable to indentify ‘intmax_t’ and ‘uintmax_t’ variables within file mpfr.h:

main.cpp
C:\MPFRC++\mpir_mpfr\mpfr\Win32\Debug\mpfr.h(354) : error C2061: syntax error : identifier ‘intmax_t’
C:\MPFRC++\mpir_mpfr\mpfr\Win32\Debug\mpfr.h(356) : error C2061: syntax error : identifier ‘intmax_t’
C:\MPFRC++\mpir_mpfr\mpfr\Win32\Debug\mpfr.h(357) : error C2061: syntax error : identifier ‘uintmax_t’
C:\MPFRC++\mpir_mpfr\mpfr\Win32\Debug\mpfr.h(359) : error C2061: syntax error : identifier ‘uintmax_t’

What is going on?

Note: I am using Visual C++ compiler in U++ framework

Thank you.

Javier

Pavel,

I have checked your VC++ 10 files (in Debug mode) and work fine. Thank you.

Some questions concerning the different files (I am not using Visual Studio but another C++ programming tool: U++):

1.- I notice that you have included .dll files; I have copied the .dll file -those within the ‘Debug’ folder- in the system32 and in the sysWOW64 sub folder within Windows folder; this works for ‘Debug’. But, if I wanted to use the ‘Release’ dll, how can I do it since both .dll (‘Debug’ and ‘Release’) have the same name?

2.- Concerning the other files: .exp,.ilk., what are they for? Do they need to be located in a specific folder?

Note: my operating system is Windows 7 64 bits.

Thank you,

Javier

Hi Pavel,

I have just tried out MPFRC++, and it really helps me by giving me the right answer in the calculation of the intersection between a great-circle arc and latitudinal line segment, which is wrong at normal “double” calculation. But the computing slows down considerably (set the default precision to 128 following the example).

Cheers,

Li

Spelling error i think:
s/Doug Lee/Doug Lea/

Hi Pavel,

I plan to use MPFRC++ together with Eigen. So far it looks very promising:-)

However, I have bumped into one problem

When trying to compile


typedef Matrix<mpreal, Dynamic, 1 > mpfr_vector;
mpfr_vector y;
mpreal t;

t = y.cwise().abs().minCoeff();

I’m getting error (gcc 4.4.3)

error: ‘class Eigen::Matrix’ has no member named ‘cwise’

I’m trying to find minimum mpreal value of |y|.

Is it a known limitation? Can

#include <unsupported/Eigen/MPRealSupport>

be updated to support cwise?

Thanks a lot!
Jirka

Hi Pavel,

thanks a lot for the quick reply! I have tried both ways and both are working just fine.

It’s obviously my mistake. I was starting with Eigen2 but I have found out that “unsupported/Eigen/MPRealSupport” is not part of my Eigen2 installation. So I have downloaded Eigen3 but I didn’t check if cwise operator is still there.

Thanks a lot for the clarification. Eigen together with MPFRC++ gives programmers a lot of power. I’m converting a program written with ARPREC to MPFR and I’m amazed how easily it goes with the right libraries:-)

Thanks
Jirka

Pavel,

I’ve been looking for an easy to use solution for arbitrary precision calculation for my fractal programs as there is a limit to the depth of zoom achievable. I’ve had a look at some alternatives which supported complex numbers and the implementation of the interface looked over complicated, so I looked at this wrapper and it is nice and simple in comparison, however with no apparent support for complex numbers.

It turns out that I needn’t have worried as a test program showed that using std::complex just works, even with the complex functions e.g. std::cos, so there is no need for a complex number wrapper at all. I haven’t tried it with the boost versions of complex functions that are present with g++ 4.4 but not with MSVC2010 but I don’t anticipate any problems.

Now that I’ve established the viability of adding arbitrary precision to my software I added the requirement for automatic switching from long double to arbitrary precision and back again for version 3.0. As version 3.0 is a major upgrade I don’t envisage incorporating MPFRC++ for several weeks.

When I have incorporated MPFRC++ I’ll add a link to here from my blog, I may even add link and blog post before then.

Thanks for hard work.

regards,
Mark Eggleston

Hi Pavel,

I’m looking for a way to do calculations with non-integer numbers that would *always* yield the same results, even with other compilers, other architectures etc. You cannot achieve this by using floats or doubles, so I’m trying to find a library that lets you do that, even if I need to lose a little bit of performance. The high precision of the results is not really important for me, the result should just always and everywhere be the same.
Is mpfr (hence mpfrc++) a good solution for what I’m looking for? According to “with correct rounding” from the GNU MPFR description, it seems like it is, but I would like to be sure before I change all my code to use mpreal…

And if it is, do you have better performances by setting the precision to a lower value, or is it always the same?

Sorry if these questions are already answered in the previous comments, but there are a lot of them and they are not really classified by topic, so hard to search in :p

Thank you in advance.

Hey Pavel,

How should we cite MPRC++ if we use it for our scientific research?

I am sorry, but I wanted to install linux port of your library, but I think, the repository does not work correctly. I get such following error:

W: Failed to fetch http://tech.unige.ch/packages/dists/quantal/main/source/Sources 404 Not Found
W: Failed to fetch http://tech.unige.ch/packages/dists/quantal/main/binary-amd64/Packages 404 Not Found
W: Failed to fetch http://tech.unige.ch/packages/dists/quantal/main/binary-i386/Packages 404 Not Found

Thank you in advance for help
Dariusz

I’m now testing my source package on various distributions of Linux. For Ubuntu 10.04, it has MPFR 2.4.2 and GMP 4.3.2. The library versions are greater than those stated as being minimum requirements for MPFR C++.

The build fails because MPFR_RNDN is not declared in MPFR 2.4.2 so the minimum requirements needs to be revised.

I have used the MPFR library earlier. I must say that this C++ implementation is much easier to use. I am wondering how you change the rounding mode (I believe the default is RNDN) from the C++ wrapper. For example in MPFR, we could choose the rounding mode during every operation (like add, sqrt etc). But how do I set the rounding mode to RNDZ for example in C++ wrappers?

Hello Pavel, I am reporting an error I encountered in reading formatted inputs when switching type from double to mpreal.
Specifically, if there is a comma after a number instead of a space, the c_str() call in “inline std::istream& operator>>(std::istream &is, mpreal& v)” causes an “Assertion Failed” runtime error.
A program demostrating the problem can be found in the first post at http://ubuntuforums.org/showthread.php?t=2160022
Nothing major, of course, but I think it is worth reporting since the change of type causes unexpected errors in an otherwise working code.
Thanks for the awesome wrapper!

I am having trouble getting mpreal to compile using vc++ 2005. Are there step by step instructions somewhere? Here is what I tried:
1. downloaded the zips suggested on this page
2. added the folders to my include directories listing
3. in code, used #include “mpreal.h”
4. used the following code:
using mpfr::mpreal;
mpreal number;
number = “5”;
5. Got the following error:
error LNK2019: unresolved external symbol _mpfr_get_default_rounding_mode referenced in function “public: static enum mpfr_rnd_t __cdecl mpfr::mpreal::get_default_rnd(void)” (?get_default_rnd@mpreal@mpfr@@SA?AW4mpfr_rnd_t@@XZ)

i know i’m doing something wrong, but i can’t figure out what it is

Dear Pavel:

You mentioned that user can equip Eigen with arbitrary precision arithmetic by:

1. Installing MPFR and GMP libraries.
2. Using MPFR C++ interface (mpreal.h, mpreal.cpp) along with header file mpreal_eigen.h
3. Using mpreal type (provided by MPFR C++) instead of built-in type double or float.

But I also found head file #include in this module

http://eigen.tuxfamily.org/dox/unsupported/group__MPRealSupport__Module.html

My questions is which head file is better ? mpreal_eigen.h or Eigen/MPRealSupport?

I tried mpreal_eigen.h with mpreal.h, but still get error :

In file included from test_test.cpp:3:
mpreal_eigen.h:51: error: expected unqualified-id before ‘<’ token
mpreal_eigen.h:56: error: expected ‘;’ before ‘inline’
mpreal_eigen.h:61: error: expected unqualified-id before ‘<’ token
test_test.cpp:15: error: expected ‘;’ at end of input
test_test.cpp:15: error: expected ‘}’ at end of input

my test_tes.cpp file is very simple:

#include
#include “mpreal.h”
#include “mpreal_eigen.h”

using namespace mpfr;
using namespace Eigen;

int main()
{
mpreal::set_default_prec(256);
typedef Matrix MatrixXmp;
MatrixXmp A = MatrixXmp::Random(100,100);
std::cout << "relative error: " << A << std::endl;
return 0;
}

Could you please give me some suggestions on how to resolve this problem? Thanks!

I am quite new to both mpfr and mpreal, so maybe I just haven’t read the manual thoroughly enough ..

I am transmitting mpreals over a network, and I want to do this with as little conversion as possible. As I want to be independent of 32/64 bit issues (and also for other reasons) I am not trying to access the raw internals, but mpfr_set/get_str instead.

This sort of works, but the precision is less than that of long doubles:

#define get_mandel_value(dst,src) { FLOAT_TYPE dst_tmp(src.val); dst = dst_tmp; }
#define set_mandel_value(dst,src) strncpy(dst.val,src.toString("%.128RNe").c_str(),mpfr_buff_size - 16)


(the buff_size – 16 is a leftover, when doing mpfr_get/set_str, the buffer need some extra space for sign etc.).

I would like to do something like this:

#define get_mandel_value(dst,src) \
{ \
if ( mpfr_set_str(dst.mpfr_ptr(),src.val,mpfr_str_base,MPFR_RNDN ) == -1 ) { printf("get_mandel_value failed!\n"); exit(1); } \
}

#define set_mandel_value(dst,src) \
{ \
mpfr_exp_t *expptr = new mpfr_exp_t(); \
memset(dst.val,0,mpfr_buff_size); \
if ( mpfr_get_str(dst.val,expptr,mpfr_str_base,mpfr_buff_size-16,src.mpfr_ptr(),MPFR_RNDN) == NULL ) { printf("set_mandel_value failed!\n"); exit(1); }\
delete expptr; \
}

As you can see, I am calculating Mandelbrot 🙂 I have a FLOAT_TYPE which can be either a long double or a mpreal float.
Also, I am a bit confused over the expptr, why is it necessary.

I have tried different format strings – maybe I didn’t hit the correct combination?
I have used mpfr_set_default_prec(1024) and even 8192 – no change.

What is the best (precise) way of marshalling mpreals?

Btw: Thanks for a great library – saved me tons of work 🙂

Dear Pavel,

thank you for sharing your code with us.

I have to use the exponential function with a negative argument. It seems that the identity

,

although mathematically correct, it has numerical evaluation problems when . For example please try: cout << exp( float_precision(-1.7E2) ) << endl;

The result is incorrect.

Using the standard c math library, the results is correct, i.e., cout << exp( -1.7E2 ) <<endl;.

I would much appreciate if you check the problem and let me know how the above problem can be corrected.

Thanks and best regards,
Nikos

Dear Pavel,

thank you so much for your help!

Following your suggestions I managed to correctly evaluate the exponential function with any negative argument.

Best,
Nikos

PS: The header “fprecision.h” mentioned above has nothing to do with the MPFR project. Sorry for any misunderstanding caused.

Dear Pavel,
first of all, thank you for your work and your package.
I have a question about an error I get when I am running a program using MPFR:

sub1sp.c:658: assertion failed: bbcp != (mp_limb_t) -1

The program uses and computes a lot of very small values.

Could you help me, please?

Thank you,
Florian

Recently I installed the ‘Ubuntu package for MPFR C++’ an my aged laptop computer and was completely surprised that replacing type double by mpreal caused no noticible increase in computation time for precisions till incredible 256 decimal digits. Similar tests two years ago saw computations slowed down by a factor of ~100. Unbelievable progress, congratulations !!!!

Just to correct my previous premature and over-optimistic note. The observation about slowing down by a factor ~100 was from 2009 and thus not only two years ago. The observation that using mpreal instead of double did not increase computation time noticibly was brought about by a program that was very special in being graphical to a high degree. Graphics-related floating point computations are done in my C+- system always in double so that mpreal was involved only in a small part of the computation. For a less-graphical, ‘normal’ program I got: The factor by which prec n is slower than double was found to be 2.36 2.50 3.40 for n = 64, 128, 256 respectively. Also this is admirable progress and the congratulations need not be withdrawn in any way.

Hi. I found your library very nice. I had written one but yours is much superior. Thanks for sharing it with the world.

I have a ticket to this code: when compiling with g++ -Wall -Wextra -Wfatal-errors, I get the warning:

mpreal.h:2402:102: warning: unused parameter 'r' [-Wunused-parameter]

My understanding is that this is because the function

inline const mpreal const_infinity (int sign = 1, mp_prec_t p = mpreal::get_default_prec(), mp_rnd_t r = mpreal::get_default_rnd())

is not using its last parameter, r.

Thus, it could have be re-written into

inline const mpreal const_infinity (int sign = 1, mp_prec_t p = mpreal::get_default_prec(), mp_rnd_t)

if we want to keep backward compatibility and library systematic input of rounding parameter, or to

inline const mpreal const_infinity (int sign = 1, mp_prec_t p = mpreal::get_default_prec())

if we allow backward incompatibility.

Regards,
Jorge

Hi, Pavel,

Thank you very much for your library! I like it.

Do you know if we can pass a function pointer of type mpreal->mpreal to Boost’s optimization function templates, say, of this interface:

template class F, class T
std::pair T, T brent_find_minima(F f, T min, T max, int bits, boost::uintmax_t& max_iter) ?

I got this compilation error: “reference to overloaded function could not be resolved” when calling

boost::math::tools:: brent_find_minima(p_implm, begin, end, bits, iter);

in which p_implm is a user-defined simple function of type mpreal->mpreal.

The compilation error is in the screenshot
https://www.evernote.com/shard/s306/sh/e357903e-245c-4c7b-851f-86c331bc04f1/253e2ecbb100465d560a6c53183073d3

Note that the error points to policy.hpp of boost library. So I guess I made something wrong or maybe
mpreal is not designed to work the way as I naively thought.

What do you think?

Hi!

I’ve tried to include your wrapper class in my Visual Studio 2013 project, but when I try to compile it I get the following errors:

mpreal.h(673): error C3861: ‘mpfr_set_uj’: identifier not found
mpreal.h(681): error C3861: ‘mpfr_set_sj’: identifier not found
mpreal.h(1001): error C3861: ‘mpfr_set_uj’: identifier not found
mpreal.h(1001): error C3861: ‘mpfr_set_uj’: identifier not found
mpreal.h(1727): error C3861: ‘mpfr_get_sj’: identifier not found
mpreal.h(1728): error C3861: ‘mpfr_get_uj’: identifier not found
mpreal.h(2395): error C2057: expected constant expression
mpreal.h(2395): error C2466: cannot allocate an array of constant size 0
mpreal.h(2395): error C2133: ‘p’ : unknown size

For the first six errors I observe that I cannot find these functions, but there are functions such as mpfr_set_ui. Should I use these instead?

For the last three erros (starting with error C2057) the code that doesn’t work is the following function:

inline const mpreal sum(const mpreal tab[], const unsigned long int n, int& status, mp_rnd_t mode = mpreal::get_default_rnd())
{
mpfr_srcptr p[n];//<------- ERROR is here!

for (unsigned long int i = 0; i < n; i++)
p[i] = tab[i].mpfr_srcptr();

mpreal x;
status = mpfr_sum(x.mpfr_ptr(), (mpfr_ptr*)p, n, mode);
return x;
}


Also, I used the Windows binaries for Visual Studio 2010 that you have linked to in your post. Should that cause any problems using VS2013?

I’m quite clueless here – and not at all experienced in installing third-party libraries – so I would appreciate some help. It took me quite some time just to get the settings right so that Visual Studio would find the mpfr and mpir libraries at all.. :p

Version 3.6.2 of mpfrc++ does not implement the modulus operator % nor does it support the (int) operator. Here are the errors emitted:

g++ FactorRSA.cpp
FactorRSA.cpp:37:16: error: invalid operands to binary expression
(‘mpfr::mpreal’ and ‘mpfr::mpreal’)
if((n % i) == zero) {
~ ^ ~
FactorRSA.cpp:49:19: error: cannot convert ‘const mpfr::mpreal’ to ‘int’ without
a conversion operator
k = (int)sqrt(j);
^~~~~~~~~~~~
2 errors generated.

All of the variables n, i, zero, k, and j are of type mpreal.

Really good library. I love. It make life so easier.

An annecdote;

Today I was working with mpz constant and was wondering how to transfer the value to a mpreal’s variable,and I just tested with a simple ‘=’ to see it work. **magic** for me.

Hi!

I have found problem with MPFR C++/Eigen/Visual Studio 2015 and std::complex.
Code in the file Eigen\src\Eigenvalues\ComplexSchur.h uses std::abs(std::complex) and std::sqrt(std::complex) that are not defined in the MPFR C++
Default Visual Studio implementation internally converts arguments to double and completely looses precision;
Without correct abs and sqrt, modules like Eigenvalues in the Eigen almost useless (in the case of the high precision)
When i have added these function to MPFR C++, everything has become good

Code to reproduce problem

mpfr::mpreal::set_default_prec(512);
std::cout.precision(32);
std::complex val(2);
std::cout<<sqrt(val).real();

Example of the abs and sqrt implementation:


#if defined(_MSC_VER)
namespace std {

mpfr::mpreal abs(const std::complex& a,
mp_rnd_t r = mpfr::mpreal::get_default_rnd())
{
return sqrt(a.real()*a.real()+ a.imag()*a.imag(),r);
};

std::complex sqrt(const std::complex& a,
mp_rnd_t r = mpfr::mpreal::get_default_rnd())
{
if (a.real() == mpfr::mpreal() && a.imag() == mpfr::mpreal()) {
return 0;
}

mpfr::mpreal b, c, d, e;

b = fabs(a.real(),r);
c = fabs(a.imag(),r);
if (b > c) {
d = c / b;
e = sqrt(b,r) * sqrt(0.5 * (1.0 + sqrt(1.0 + d*d,r)), r);
} else {
d = b / c;
e = sqrt(c, r) * sqrt(0.5 * (d + sqrt(1.0 + d*d, r)), r);
}

std::complex result;
if (a.real() >= 0.0) {
result.real(e);
result.imag(a.imag() / (2.0 * e));
} else {
result.imag(a.imag() >= 0.0 ? e : -e);
result.real(a.real() / (2.0*result.imag()));
}

return result;
}//namespace std


Dear Povel,

I am trying to use mpreal for complex numbers but I’m having trouble making it work. I read in the comments that Mark Eggleston used std::complex and worked fine for him. However, I get error when I try to do that. Is there a way that I can use MPFRC++ for complex numbers? Thank you for your great work.

Regards,
Musa

Hi Pavel,

I’ve found some little typo. I got trouble for const variables when using mpfrc++-3.6.2 for exponent manipulations =(( «const mpfr::mpreal» as «this» argument of «mp_exp_t mpfr::mpreal::get_exp()» discards qualifiers.

Regards,
Ivan

Hello

…and thank you for this wrapper, it makes things much more clear for beginners, like me. I am trying to make a small program involving polynomials and their roots, so I need to generate and calculate the roots on the fly. One of the polynomials involves factorials and the terms could have been integers, all, but, as I’ve seen in the comments, big integers are not well supported, and floats can be used, instead. So I did, but now I’m facing some strange results and I don’t know what to think now. Consider this simple implementation of a factorial:


mpfr::mpreal fact(const int &n)
{
mpfr::mpreal x(1);
for (int i=0; i<=n; ++i)
x *= i;
return (n==0 ? 1 : x);
}


This, when run with i=0..22 works fine, but when it reaches i=23, the results start being wrong. But, as I said, I don’t know what causes them, so I thought I’d first ask you to confirm, or infirm, my findings. My apologies if this turns out to be a mistake of mine.

Vlad

With all due respect….

I am a newbie to both C++ and Mandelbrot. I used the Intel Compiler to get “long double” for the “evaluation” period with minimal improvement (2E5 approximately?).

I am using “double” in VS2015 (release not debug) on a 64bit desktop. I am also using standard Windows threading, 6 out of the 8 threads. My test zoom value is 2,073,600 and maxiterations of 25,000. Without mpreal++ the Mandelbrot took 800ms. With the “double” changed to “mpreal” the same Mandelbrot took 578seconds. I was using the default 50 digit define. So mpreal took 722 times as long as stock standard Windows 🙁

I AM looking at arbitrary precision, perturbation and SuperFractalThing but was hoping to avoid them all by using mpreal++. I am a retired BASIC programmer with assembler skills and DO appreciate the achievement of mpreal++. I started C++ a couple of months ago so AM an absolute newbie, on the coding adventure of my life 🙂

I CAN reduce my test to 25 digits (temporarily) but hoped to use 50 or 100 digits in the long run. I AM sorry to conclude that mpreal isn’t my solution 🙁

Thanks quaz0r, I take your point(s). 🙂

The jump to perturbation theory (and coding) is HUGE. The jump to mpreal++ is minute hence I WAS hoping it was the solution…. 😉

I am also wary of the perturbation “glitches” but that has nothing to do with mpreal++. I am sorry mpreal isn’t my solution 🙁

Thanks for your responses 🙂

From GMP manual, notes for particular system (section 2.4):
“The GMP functions involving a double cannot be expected to operate to their full precision when the hardware is in single precision mode”

It does *not* say more precision (64 bits) is ok
The problem is floating point math might be involved even for integer multiply.

My guess is using gmp in directed rounding (e.g. towardzero) is also a BAD idea …

Hi Pavel,

As I know mpreal allocates memory for mantissa dynamically. Can mpreal be customized to allocate mantissa in stack?

Reqards,
Ivan

Hi Pavel,
I’ve found error in division operator realization (line 1516 , version 3.6.5).

can mpfr c++ use alias to avoid allocation / copying ?

mpreal x = “1.2”; … do stuff with x …
mpreal y = &x; // alias for x, no init or cleanup

maybe do the same thing with mpfr_t:

void function(…) {
static mpfr_t sz = {{._mpfr_prec = 0}};
if (sz->_mpfr_prec == 0) mpfr_init(sz); // only initialize one time
mpreal z = &sz; // alias of sz, but mpreal type
…
}

Pavel,

Upon further review, I’m not sure about mpfr_grandom being deprecated on the official version. I was using Brian Gladman’s github repository here: https://github.com/BrianGladman/mpfr, which is where I got the information I mentioned before. His repository has a version number of 4.0.0-dev. The official repository has the latest branch as 3.1.6-dev (as far as I can tell), and I can find no mention of the deprecation in the log. My proposed change may still be ok so I will add pull request. Just wanted to make you aware of the situation.

I faced a little problem when I used it to modify my code for the MPFR version.

for( long inx = 0, y = 0; y < bitmap.h(); ++y)
{
for( long x = 0; x < bitmap.w(); ++x, ++inx)
{
mpreal r = 0.0, g = 0.0, b = 0.0;
for( long n = 0, j = -radius; j<= radius; ++j)
// do something with r,g,b..
}
}

when I compiling it ,it shows the following error:
GNU MP: Cannot allocate memory (size=451066975599404656)
Aborted (core dumped)

PS： x, y are the image of the length and width of the pixel value in this loop, and finally will reach 480,640.

Hi,
I’m trying to use MPFRC++ and Eigen to compute the eigenvalues of a non-symmetric matrix with high precision. The test code for the LU-decomposition and for the symmetric eigenvalue problem run without a problem. However, when try the code (which I name testEigen.cpp):

#include
#include
#include
using namespace mpfr;
using namespace Eigen;

int main()
{
mpreal::set_default_prec(256);
typedef Matrix MatrixXmp;
MatrixXmp A = MatrixXmp::Random(100,100);
A.eigenvalues();
}

and compile it using

g++ -I eigen-3.3.4 -I eigen-3.3.4/unsupported -I eigen-3.3.4/unsupported/test/mpreal -lmpfr -lgmp testEigen.cpp -o testEigen

(where g++ is “Apple LLVM version 9.0.0 (clang-900.0.39.2)” ) I get the error:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/complex:679:20: error: cannot convert 'mpfr::mpreal' to 'int' without a conversion operator
__ilogbw = static_cast(__logbw);

After reading the questions and answers above, I gather that the error occurs because 1) non-symmetric matrices can have complex eigenvalues and this is implemented in Eigen using std::complex, 2) std::complex requires some conversions to simpler datatypes, 3) such conversions are risky since it may lead (on some systems) to loss of precision without a warning, 4) you therefore removed the conversions and caution against using MPFRC++ and std::complex. Is this correct? Does this preclude using MPFRC++ to compute the eigenvalues of non-symmetric matrices?

I am also a bit confused about why the conversion fails; the file Eigen/MPRealSupport (which I assume is related to Konstantin Holoborodko’s mpreal_eigen.h mentioned in previous questions) contains the definition:

template inline int cast(const mpfr::mpreal& x) { return int(x.toLong()); }

It seems to me like this line should take care of the conversion operator, but this level of C++ is a bit beyond me.

In a comment from a couple of years ago you mentioned that you may develop mpcomplex. I think this would be appreciated by a lot of people, especially if integrated with Eigen. In any case, thank you for developing this useful package.

I was able to compile a static MPIR lib on using Visual Studio 2017, but failed with MPFR.

The blob MPFR-MPIR-x86-x64-MSVC2010.zip has only DLLs — could I request a static MPFR library please?

AB

Hi Pavel,

I am new to arbitrary precision calculations and I would like to ask a few questions.
I am using boost::multiprecision wrapper of mpfr and mpir for calculating pi using Ramanujan’s formula for one of my school projects. I am also new to C++ as you might guess later, so
– I was wondering is it worth making my code using simd instructions or mpfr uses them internally already?
– If it makes sense to use simd what library would you suggest me to do it, cause I tried xsimd so far and it seems to be not working with mpfr type at first glance (like I said I am not really experienced C++ developer in order to debug external libraries and understand where the problem is)

Yanislav

Is this project dead? Example doesn’t even compile for me. Perhaps user error?

-*- mode: compilation; default-directory: “~/Downloads/mpreal-master/example/” -*-
Compilation started at Wed Oct 28 09:39:33

make
g++ -c example.cpp
In file included from example.cpp:50:
./../mpreal.h:2621:11: error: cannot convert ‘mpfr::mpreal’ to ‘long’ without a
conversion operator
r = long(x);
^~~~~~
./../mpreal.h:2630:11: error: cannot convert ‘mpfr::mpreal’ to ‘long long’ without a
conversion operator
r = (long long)(x);
^~~~~~~~~~~~~~
2 errors generated.
make: *** [example.o] Error 1

Compilation exited abnormally with code 2 at Wed Oct 28 09:39:34

Hi Mr. Pavel,

I am dealing with log() accuracy problem. I got the different log(x) values when computed when using your MPFR wrapper versus Python Decimal class. For instance, when I calculate log(2),

log(mpreal(“2”)) = 0.69314718055994528622676398299518041312694549560546875 when using MPFR C++

but

log(decimal.decimal(‘2’)) = 0.6931471805599453094172321214581765680755001343602552541 when using Python Decimal.

Digit disagreements begin after 15 decimal points…
Could you help me explaining the reason and how to rectify this problem. I feel like it is more likely that the error is coming from me, but I couldn’t find the source of the problem.

Thanks,
Rabie.

Dear Pavel,

Thank you for this excellent wrapper. There is some discussion above about serialization which I would love some more of your thoughts on. What do you recommend if I have a short-term need to serialize some mpreal objects? For detail
1) round-trip guarantee is important, and copied objects should have the same serialization (assuming global state unchanged)
2) speed, size not important
3) I have no objection to “going down” to mpfr or gmp underlying variables if necessary.

I was thinking to use strings (to_string()) in base 2, with n=precision+2, and a fixed rounding mode. However I am not confident that (1) will be satisfied. Do you have any recommendation?

Dear Pavel,

The work you have done is very impressive and the MPFR C++ project is exactly what I am looking for a scientific computation related task. I just have one trivial question that I could not determine myself based on the given documentation and the existing source code. Specifically, what is the proper type to be used for arbitrary precision integers? In the project that I am working in, we have to iterate over a large range of integers and perform computations for them, with the upper bound being in the range of . For this it would be the most convenient if we would run a for-loop over w.r.t. some variable over this range with having a type that allows one to represent numbers in the range of . I already tried to use the mpreal type, but at some points of the program we have to read data from (possibly large) indices, and as of writing reading data from a type const std::vector array with a type mpfr::mpreal caused the error that “error: no match for ‘operator[]’”, when data is being read as data[i] and i having a type mpfr::mpreal. If all else fails I suppose one fix could be iterate over the data structure and make appropriate changes to the code.

Best,
Sampo

Dear Pavel,

In the application I am working, I would like to use both mpz_t (technically of type mpz_class as per: https://gmplib.org/manual/C_002b_002b-Interface-Integers) and mpreal type variables. Occasionally, I have to do some arithmetic with both of these types together that would result in a real number, and so it should be stored to a type mpreal. As of writing I having some difficulties implementing the desired behavior. For example, in much the simplified code below:


mpr computation(const int & e, const mpz & m) {

const mpr modder { mpfr::pow(mpfr::mpreal(3), mpfr::mpreal(e)) };

const mpr m_mod = mpfr::mod(m, modder);

return m_mod;
}


I get the error message:

extended_main.cpp: In function ‘mpr computation(const int&, const mpz&)’:
extended_main.cpp:80:33: error: invalid initialization of reference of type ‘const mpfr::mpreal&’ from expression of type ‘const mpz’ {aka ‘const __gmp_expr’}
80 | const mpr m_mod = mpfr::mod(m, modder);
| ^
In file included from extended_main.cpp:14:

where the line 80 refers to the line where m_mod is defined. The same issue persists even if I change the code to:

mpr computation(const int & e, const mpz & m) {

const mpr modder { mpfr::pow(mpfr::mpreal(3), mpfr::mpreal(e)) };

const mpr m_mod = mpfr::mod(mpfr::mpreal(m), mpfr::mpreal(modder));

return m_mod;
}


My questions are:

1.) How should the code be modified to avoid compilation errors?

2.) If one has to do simple arithmetic computations that mix mpreal and mpz_class variables, what is the best way to correctly map the operands to types supported by MPFR C++?

Best,
Sampo

The digits2bits call has an argument of type int which on a current Mac with Xcode is a 4 byte integer. Recommend that it be changed to a mp_prec_t so that it can be a long which should be an eight byte integer. Without this, the digits2bits call will limit the bit precision to be 32 bits on some systems.

Bill James