Tricky Problem: Representing -37 in 8-Bit Two's Complement

Execute the full binary-invert-add-1 two's complement algorithm across the entire fixed bit width, including leading zero bits, rather than only the digits that look 'significant.'

Represent -37 using 8-bit two's complement. The expected steps are: convert 37 to binary, invert every bit, then add 1.

Why This Problem Is Tricky

37 in plain binary is only 6 bits wide (100101), but the problem specifies an 8-bit field. The trap is inverting only the 'meaningful' 6 bits of 100101 and forgetting that, in an 8-bit representation, 37 is actually 00100101 — with two explicit leading zero bits that are just as much a part of the number as any other bit and must be inverted along with everything else. Skipping them produces a result with the wrong bit width and the wrong value.

Step-by-Step Worked Solution

Step 1 — binary: write 37 as an 8-bit binary number. 37 = 32 + 4 + 1 = 2^5 + 2^2 + 2^0, so 37 = 00100101 in 8 bits (note the two explicit leading zeros needed to fill the 8-bit field).

Step 2 — invert: flip every one of the 8 bits, including the leading zeros. 00100101 inverted is 11011010.

Step 3 — add 1: 11011010 + 00000001 = 11011011. Since the last bit of 11011010 is 0, adding 1 simply flips that last bit to 1 with no carry propagation needed, giving 11011011.

So -37 in 8-bit two's complement is 11011011. Verify by converting back: interpret 11011011 as an unsigned 8-bit number: 128+64+16+8+2+1 = 219. Since the two's complement value equals (unsigned value) - 256 for an 8-bit negative number, 219 - 256 = -37, confirming the result.

Why the Obvious Wrong Answer Is Wrong

A common mistake is working only with the minimal 6-bit binary form of 37 (100101), inverting just those 6 bits to get 011010, and then either padding the result incorrectly or forgetting the two extra bit positions altogether — producing a final answer such as 00011011 that has the wrong magnitude and does not represent -37 in an 8-bit field at all.

The fix is procedural, not conceptual: always write the positive number out to the FULL declared bit width first (with explicit leading zeros), and only then invert every bit in that full-width representation. Two's complement is defined relative to a specific, fixed bit width — 'the binary form of 37' is meaningless without first stating how many bits the field has.

Two's Complement Algorithm (Fixed Width)

To represent -N in an n-bit field:
  1. Write +N in binary, padded with leading zeros to exactly n bits.
  2. Invert every one of the n bits (this is the one's complement).
  3. Add 1 to the inverted n-bit result (discard any overflow carry beyond bit n-1).

Code Examples

Every one of the 8 bit positions is carried through all three steps, including the two leading zero bits from step 1, which become 1s in step 2 and remain 1s through step 3 since the addition of 1 only affects the least significant bit here (no carry propagation was needed). Expected result: 11011011 -37 = 11011011 (8-bit two's complement)

Step 1 (binary, 8-bit, all bits including leading zeros):
   0 0 1 0 0 1 0 1   = 37

Step 2 (invert every bit / one's complement):
   1 1 0 1 1 0 1 0

Step 3 (add 1):
   1 1 0 1 1 0 1 0
 +           1
 -------------------
   1 1 0 1 1 0 1 1   = -37 (two's complement)

Verify: unsigned value of 11011011 = 128+64+16+8+2+1 = 219; 219-256 = -37

Bit-by-Bit Transformation

Step 1 (37, 8-bit):    0 0 1 0 0 1 0 1
Step 2 (invert):       1 1 0 1 1 0 1 0
Step 3 (+1):           1 1 0 1 1 0 1 1   <-- -37
                       ^ ^
                       these two leading bits are
                       easy to forget to invert

Why Bit-Width Discipline Matters

This exact category of mistake — forgetting to account for a value's full, fixed bit width — is the root cause of real sign-extension bugs when a signed value moves between registers or variables of different widths in real CPUs and compilers; getting the width wrong silently changes a value's numeric meaning without any error being raised.

Inverting only the 6 significant bits of 100101, ignoring the two leading zero bits of the 8-bit field

Write 37 as the full 8-bit value 00100101 first, then invert all 8 bits

Two's complement is always relative to a declared, fixed bit width. Treating 37 as if it were naturally 6 bits wide and only inverting those digits skips two bit positions that are just as real as any other bit in an 8-bit field, producing an incorrect final value.

What is -37 in 8-bit two's complement? A. 11011011 B. 11011010 C. 00100101 D. 00011011

A. 11011011 — 37 = 00100101 in 8 bits. Inverting all 8 bits gives 11011010 (one's complement). Adding 1 gives 11011011. Verifying: the unsigned value of 11011011 is 219, and 219-256=-37, confirming this is correct. 11011010 (option 2) is the one's complement, missing the final add-1 step; 00011011 (option 4) results from forgetting to invert the field's leading zero bits.

When computing the two's complement of a positive number, which bits must be inverted in step 2? A. Only the bits that are currently 1 B. Only the minimal significant bits, ignoring any leading zeros C. Every bit in the declared fixed width, including any leading zeros D. Only the most significant bit

C. Every bit in the declared fixed width, including any leading zeros — Two's complement is defined relative to a specific, fixed bit width. Every bit position within that width — including leading zeros needed to pad the number up to the declared width — must be inverted in step 2; skipping the leading zero bits produces an incorrect one's complement and therefore an incorrect final two's complement value.

Represent -50 using 8-bit two's complement.

50 = 00110010 (8-bit). Invert: 11001101. Add 1: 11001110. Verify: unsigned value of 11001110 = 128+64+8+4+2 = 206; 206-256 = -50.

Convert 50 to a full 8-bit binary value first, including any leading zeros, before inverting.