using cpp_int and other integer types gives unknown type name 'cpp_int' error when compiled on Xcode 6 on a macbook.

[yavuz@…]

#include <iostream> #include </Users/yavuz/boost_1_57_0/boost/multiprecision/cpp_int.hpp>

int main(int argc, const char * argv[]) { using namespace boost::multiprecision; cpp_int factorial = 1; return 0; }

BTW, since boost installation doesn't specify where boost should be installed, I installed it in my home directory and that led me to writing out the path to it in the include directive. Otherwise, include gives an error message.

[Steven Watanabe]

You need to add /Users/yavuz/boost_1_57_0 to the include directories instead of passing the full path. The command line option is -I. I don't know where you configure this in XCode.

[anonymous]

Replying to steven_watanabe:

You need to add /Users/yavuz/boost_1_57_0 to the include directories instead of passing the full path. The command line option is -I. I don't know where you configure this in XCode.

Thank you. I fixed this by including a path in the user search options on Xcode. I have another question. I receive an error when I execute the following assignment statement:

cpp_int f=123456789123456789123;

If I remove 3 at the end, it shows a warning, and when I also remove 2, it works fine. This same error occurs with uint256_t and uint256_t as well. The number of digits is about 21 and I would think that all three multi precision types should be fine with it, but they all result in an error message. Any explanation?

[Steven Watanabe]

123456789123456789123 is not a cpp_int. It's a built in integer literal. You can use the string constructor for larger values.

[anonymous]

Replying to steven_watanabe:

123456789123456789123 is not a cpp_int. It's a built in integer literal. You can use the string constructor for larger values.

That makes sense. The reason I had brought it up was I have run into a problem with the following declaration: uint128_t M[1000][1000]; I am doing simple additions on pairs of values in this matrix. Can you please confirm that this will create a 1000 by 1000 matrix where each element is a 128-bit integer? And also, will my additions be performed with results represented as uint128_t numbers? Thank you.

[Steven Watanabe]

Replying to anonymous:

That makes sense. The reason I had brought it up was I have run into a problem with the following declaration: uint128_t M[1000][1000]; I am doing simple additions on pairs of values in this matrix. Can you please confirm that this will create a 1000 by 1000 matrix where each element is a 128-bit integer?

Yes.

And also, will my additions be performed with results represented as uint128_t numbers? Thank you.

I assume that your additions are of the form (M[i][j] + M[k][l]). I think you are correct, but the result might also be an expression template type. You'll have to check the documentation. In any case, the result of the addition will be convertible to uint128_t.

[anonymous]

Replying to steven_watanabe:

Thank you. Actually, the additions work when the matrix row (column) dimension is capped around 700. It is not so much the matrix size, but the numbers I compute get to be 21 or 22 decimal digit big when the matrix row (column) dimension gets to be about 710. I suspect that the additions are capped at 64-bits because 64 bits roughly correspond to 21-22 decimal digits. So, it seems that uint128_t does not seem to be working as intended.

[John Maddock]

I think you need to post a test case if you want us to investigate that further. One simple thing you can try first is to replace uint128_t with checked_uint128_t, and if it throws an exception somewhere then you know you have numeric overflow in the calculation.

With respect to one of your earlier questions, large numeric literals are possible in C++11 mode, see: http://www.boost.org/doc/libs/1_57_0/libs/multiprecision/doc/html/boost_multiprecision/tut/lits.html

And finally.... note that GCC (though not other compilers) has a built-in __int128 type which will be a little faster than boost::multiprecision::uint128_t (uint128_t will actually be a thin wrapper around unsigned __int128 on GCC).