Re: [boost] [mp_int] Incorrect comparison with native types

Subject: Re: [boost] [mp_int] Incorrect comparison with native types
From: Nathan Kitchen (nathan.kitchen_at_[hidden])
Date: 2009-01-12 12:28:27

On Sun, Jan 11, 2009 at 5:58 AM, Kevin Sopp <baraclese_at_[hidden]> wrote:
>> (2)
>>
>> mp_int<> a = 13;
>> int b = -1;
>> cout << (a | b) << endl; // Should be -1, right?
>
> No, -13 is the correct answer here. You're ORing the magnitude of both
> numbers when using mp_ints. Unlike the built in integral types for
> which the answer depends on the internal binary representation of
> numbers (usually it's two's complement).

The interpretation of OR that you describe is consistent with
libtommath (of course) but not with other arbitrary-precision-integer
packages that I have tried. When I try either 13 OR -1 or (BIG(1) <<
200) | -1, I get -1 from all of the following:

gmp
java.math.BigInteger
Python's built-in long type
Ruby's built-in Bignum type

Likewise, all of these give me -14 for (BIG(13) ^ -1), while
libtommath and mp_int give -12.

-- Nathan
-- Nathan