Bit flip only function?

[Richard Damon]

On 7/21/14, 2:54 AM, Viktor Kletzhändler wrote:
> Thanks for the feedback.
>
> The situation is more complicated than expected.
>
>> Am I missing something?
>>
>>> I suspect that what you are missing is that the binary value 1111 1111 if it really means 255 decimal is REALLY the bit pattern
>>> +0 1111 1111 (to store the sign bit), and thus the complement would be -1 0000 0000 (where the sign is used to indicate that the leading bit is replicated to infinity (but can be ignored for value).
>>>
>
>>> You're all trying too hard to map bit strings to integers.  Sometimes a bit string is just a bit string.  For bitwise negation, obviously, 1111 1111 should negate to 0000 0000, and 10 1010 should negate to 01 0101.  There is no consideration of repetition to infinity, or sign, or any other arithmetic numerical properties.  The bit string is simply a bit string.
>>>
>> But you are NOT using a tool designed for "bit strings" but for unlimited precision arithmetic. "Unlimited precision numbers", like the package uses DO have sign (represented as an infinitely repeated sign bit).
>>
>
> That would mean, mpz_com assumes that all numbers are signed two's complement representations. Therefore it silently adds a sign bit to any positive argument, and calculates the two's complement for any negative argument.
>
> This is ok. However, that would also mean that mpz_com can't take unsigned arguments, i.e. a bit string without embedded sign, for example (unsigned int) 175. Or am I missing something again?
>
> Thanks again
> --vk
>
>
Yep,
from the web site:

There are several categories of functions in GMP:
1) High-level signed integer arithmetic functions (mpz). There are about 
150 arithmetic and logic functions in this category.

Thus the mpz family of functions are to deal with SIGNED integer with 
unlimited precision. In most cases, unsigned numbers won't make a 
difference. The cases that do are cases where unsigned doesn't make 
sense (like 3-5, which doesn't have a answer as an unsigned). For 
something like a complement, since numbers are unlimited precision, 
thinking of them as "unsigned" means the DO have an "unlimited" number 
of leading 0's which complement to an unlimited number of leading 1's 
which leads to an infinitely large number.

If you want to work with a fixed, but possibley large, length unsigned 
numbers, you need to decide how to handle over/under flow. If you want 
to adopt the C languages definition of modular arithmetic, then you need 
to and with the appropriate bit mask as needed.

-- 
Richard Damon