Boost C++ Libraries: Ticket #11165: using cpp_int and other integer types gives unknown type name 'cpp_int' error when compiled on Xcode 6 on a macbook.

Steven Watanabe — Fri, 03 Apr 2015 19:33:43 GMT

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 — Fri, 03 Apr 2015 19:47:46 GMT

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 — Fri, 03 Apr 2015 20:46:45 GMT

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

anonymous — Fri, 03 Apr 2015 21:40:09 GMT

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 — Fri, 03 Apr 2015 21:54:33 GMT

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.

component changed; owner set

Steven Watanabe — Fri, 03 Apr 2015 21:55:37 GMT

owner set to John Maddock
component None → multiprecision

anonymous — Fri, 03 Apr 2015 22:37:49 GMT

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 — Sat, 04 Apr 2015 08:00:07 GMT

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).

status changed; resolution set

John Maddock — Fri, 08 May 2015 11:56:59 GMT

status new → closed
resolution → worksforme