1

I'm testing boost::multiprecision:int128_t using VS 2022. The value int128_t (-1) is not equal to int128_t ("0XFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"), but their difference is zero as expected. The issue is illustrated by

void TestEqualityof_int128_t ()
{
    using namespace boost::multiprecision;

    const int128_t minusOne ("0XFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF");

    // Using difference to detect equality
    if ((minusOne - int128_t (-1)) == 0)
        std::cout << "Using test (minusOne - int128_t (-1)), are equal." << std::endl;
    else
        std::cout << "Using test (minusOne - int128_t (-1)), are not equal." << std::endl;

    // Using equality
    if (minusOne == int128_t (-1))
        std::cout << "Using test (minusOne == int128_t (-1)), are equal." << std::endl;
    else
        std::cout << "Using test (minusOne == int128_t (-1)), are not equal." << std::endl;
}

which produces the following output:

Using test (minusOne - int128_t (-1)), are equal.
Using test (minusOne == int128_t (-1)), are not equal.

This issue is common to any integer.

Catriel
  • 461
  • 3
  • 11

1 Answers1

1

I posted this question to boostorg, and Maddock replied that this is not a bug. The extended precision integer implementations of boost does not guarantee that (x-y) == 0 <=> x == y. In addition, their integers are not two's complement. You may follow this link to read his reply.

Beware, I can't validate at this moment, but suspect that boost::multiprecision::int128_t defaults to __int128_t in linux which tells me that the same code in Windows will behave differently than the same code in linux.

Catriel
  • 461
  • 3
  • 11