Bitcmp - differences between uint8 and int8 assumedtypes

Hi,

I am using the function bitcmp for a school project and I came across a strange behaviour of this function, shown below:

>> a = bitcmp(53, 'int8')
a =
   -54
>> b = bitcmp(53, 'uint8') 
b =
   202
   

Assuming the decimal defined in this example is well within the 8 bit representation (both signed and unsigned ranges), why is the outcome different? I was expecting it to be exactly the same.

Do you know which type of operation is bitcmp performing for uint8 and int8 types? I would like to do the same procedure "manually" to better understand this function.

Thanks

Answer 1

[Walter Roberson]

bitxor(int8(53), int8(-1))

ans = int8 -54

bitxor(uint8(53), uint8(255))

ans = uint8 202

typecast(int8(-54), 'uint8')

ans = uint8 202

You should not be expecting the same result for the two. If you are expecting -54 for both, then you have the problem that negative values are out of range for uint8. If you are expecting 202 for both, then you have the problem that values > 127 are out of range for int8.

If you are using signed integers, then bitwise complement of a positive number is always negative, because the sign bit gets flipped. If you are using signed integers, then bitwise completement of a negative number is positive unless the number is the one with all bits set (in which case the result is 0), because the sign bit gets flipped.

If you are using unsigned integers, then bitwise complement of a number less than half of the maximum is always greater than half of the maximum, because the most significant bit gets flipped. If you are using unsigned integers, then bitwise complement of a number greater than half of the maximum is always less than half of the maximum, because the most significant bit gets flipped.

[Catarina Carvalho]

Hi Walter,

Thanks for your reply. I think I get the logic behind the process but could you please explain the intermidiate steps?

When I convert 53 to decimal, using 8 bits, I get

>> dec2bin(53,8)

ans =

    '00110101'
    

If then I do the one's complement, I get

complement = '11001010'
    

and if I convert it to binary again, I get

>> bin2dec(complement)

ans =

   202
   

which is what the bitcmp(53, 'uint8') returns. But what about the value of the bitcmp(53, 'int8'). Which steps do I have to take to can I get it?

Thanks again,

[Steven Lord]

202 is outside the range of values int8 can represent. The minimum value it can represent is:

intmin('int8')

ans = int8 -128

and the maximum is:

intmax('int8')

ans = int8 127

Similarly, if you're working with uint8 data you can store numbers in the range:

boundsOfType = @(x) [intmin(x) intmax(x)];
boundsOfType('uint8')

ans = 1×2

0 255

●

[Catarina Carvalho]

Hi Steven,

Yes. I understand 202 is outside int8 range. But my question was what were the intermediate steps computed to produce the same results as:

>> a = bitcmp(53, 'int8')
a =
   -54

Thanks

[Bruno Luong]

The bit representation of int8(53) is

>> dec2bin(53,8)

ans =

    '00110101'

The 2-complement is '11001010'

    
>> char((1-(dec2bin(53,8)-'0'))+'0')

ans =

    '11001010'

This is the binary representation of int8(-54) or uint8(202). They are identical in binary since (202=2^8-54)

>> u=typecast(int8(-54),'uint8')

u =

  uint8

   202

>> dec2bin(u)

ans =

    '11001010'

>> dec2bin(int8(-54))

ans =

    '11001010'

[Steven Lord]

Look at the binary representation.

dec2bin(int8(53), 8)

ans = '00110101'

The complement of that is 11001010. If we use that bit pattern to create a signed 8-bit integer:

x = 0b11001010s8

x = int8 -54

See Wikipedia for more information.

[Walter Roberson]

x = 0:10;
[x; bitcmp(int8(x))]

ans = 2×11

0 1 2 3 4 5 6 7 8 9 10 -1 -2 -3 -4 -5 -6 -7 -8 -9 -10 -11

●

Notice the pattern: for values up to 127, bitcmp(x) is -x-1 . Or to look at it another way, the sum of x and bitcmp(x) is -1 .

00110101
11001010
--------
11111111

In every case with bitcmp, 0 is replaced by 1 and 1 is replaced by 0, so the sum of the value and its bitwise complement will have 1 in every place -- either it was originally 0 and the complement was 1, or else it was originally 1 and the complement was 0. It is never possible to have a carry when you add together a value and its bitwise complement, and its is never possible to end up with a 0 in any position.

You can also think of this as starting with the all-1 value, and subtracting the bitwise representation of the original value to get the bit representation of the new value.