3

Suppose I am dealing with 4 bit operations. So if I encounter an binary digit say 

1111

then what should I infer ? Is it -1 or 15 ?

Sheldor
  • 198
  • 1
  • 1
  • 10
  • 3
    It depends on the format, but if it's 2s complement then it's -1. (If it's 1's complement it would be -0, if it's sign + magnitude then it's -7, and if it's offset binary then it's +7). – Paul R Oct 13 '16 at 18:39
  • It depends on the *context*. Even the mighty CPU does not know its sign: you would use the appropriate instructions. – Weather Vane Oct 13 '16 at 18:41
  • 1
    Since your question is about C, you don't just have a sequence of binary digits. You probably have a *value* stored in an *object* of some specific *type*. (And that object is bigger than 4 bits, unless it's a bit-field.) If you can explain in exactly what form you have those 4 bits, the question is likely to answer itself. As it is, you say nothing about C in your question. Can you update your question to show us the C code you're using? – Keith Thompson Oct 13 '16 at 18:45
  • @PaulR if it is unsigned it is +15. And...if it is weird encoding it can be anything! – Jean-Baptiste Yunès Oct 13 '16 at 18:46
  • @Jean-BaptisteYunès: true, but I think the OP is talking about signed values (see title). – Paul R Oct 13 '16 at 18:52
  • There is a _[discussion here on interpretation of bits in storage](http://stackoverflow.com/questions/6910115/how-to-represent-float-number-in-memory-in-c/6911412#6911412)_ for floating points that may shed some light on some of the dependencies that must be considered to accurately answer your question. – ryyker Oct 13 '16 at 18:54
  • @PaulR that could be an unsigned so that the answer is "it is not a negative binary number". – Jean-Baptiste Yunès Oct 13 '16 at 18:56
  • @Jean-BaptisteYunès: strictly speaking you may be correct. ;-) – Paul R Oct 13 '16 at 18:57

1 Answers1

2

"That depends".

The bits are (in this case) encoding a number, but you have to know which kind of number (signed or unsigned, integer, fixed-point or float) in order to interpret the encoded bits.

If the number is supposed to be signed in two's complement, then the proper interpretation is -1, if it's unsigned then it's 15.

It's not possible to decide from those four bits alone, it's simply not enough information.

This of course is true for a "full-sized" value too, it could be an int or an unsigned int and you have to know that in order to correctly interpret the bits.

Update: If you know that your number is supposed to be signed, the easiest way to deal with it (assuming C, which generally doesn't have a signed 4-bit integer type) is to sign-extend it into a usable form.

Sign-extending merely involves taking the most significant bit of the fewer-bits number, and repeating it to the left up to (and including) the most significant bit of the target one.

So in your case, you have 0xf, whose top bit is 1. Extending to an int8_t, we get:

const int8_t number = 0xff;

Which is -1.

There is no built-in way to do this sign-extension from an arbitrary few-bits number, since C can't natively deal with those.

Here's a naive approach:

// Sign-extend a n-bit number into 32 bits.
int32_t extend(uint32_t bits, size_t n)
{
  const bool top = bits & ((uint32_t) 1 << (n - 1));
  if (top)
  {
    for (size_t i = n; i < 32; ++i)
      bits |= 1 << i;
  }
  return bits;
}

If you call the above with your number:

printf("%d\n", (int) extend(0xf, 4));

it prints -1.

unwind
  • 391,730
  • 64
  • 469
  • 606
  • @ryyker No, the number width doesn't matter, it's equally hard if you say "I'm dealing with 2-bit numbers, what is `11`?" or "I'm dealing with 16-bit numbers, what is `1111111111111111`?". I don't understand your second quote-looking text. – unwind Oct 13 '16 at 19:12