Why is the range of signed byte is from -128 to 127 (2's complement) and not from -127 to 127?

Question

I read Why is the range of bytes -128 to 127 in Java? it says

128 is 10000000. Inverted, it's 01111111, and adding one gets 10000000 again

so it concludes -128 is 10000000

so +128 cannot be represented in 2's complement in 8 bits, but that means we can represent it in 9 bits, so 128 is 010000000 and so taking its 2's complement -128 is 110000000,

so is representation of -128 10000000 or 110000000 ? Is the representaion bit dependent ?

Why not simply make the lower range -127 fot 8 bits instead of writing -128 as 10000000 ?

Oliver Charlesworth · Accepted Answer · 2012-07-11T13:46:10.720

47

Why is the range of unsigned byte is from -128 to 127?

It's not. An unsigned byte (assuming 8-bit) is from 0 to 255.

The range of a signed byte using 2's complement is from -128 to 127, directly from the definition of 2's complement:

01111111 = +127
01111110 = +126
01111101 = +125
...
00000001 = +1
00000000 =  0
11111111 = -1
...
10000010 = -126
10000001 = -127
10000000 = -128

so is representation of -128 10000000 or 110000000 ?

In 8-bit, it's 10000000, in a hypothetical 9-bit representation it's 110000000.

Why not simply make the lower range -127 for 8 bits?

Artificially restricting the range to -127 wouldn't achieve very much; you'd be disallowing a perfectly valid value, and generally making code more complex (what else would you do with the bit pattern 10000000?).

edited Jul 11 '12 at 13:46

answered Jul 11 '12 at 13:33

Oliver Charlesworth

252,669
29
530
650

3

when i started writing my answer, your answer was a one liner. Now i see that it mostly obsoleted my answer. Do you always do this? i mean answer a one liner to grab the first responder's place, then gradually improving it? Looking at your REP, i guess you are good at this technique. +1 – Aftnix Jul 11 '12 at 13:59
1

@Aftnix: It was originally a one-liner because I thought that's all the question required. Then someone downvoted it, so I thought I should improve it! – Oliver Charlesworth Jul 11 '12 at 14:00
@Aftnix: It's ok, no offence taken! – Oliver Charlesworth Jul 11 '12 at 14:03

score 18 · Answer 2 · answered Jul 11 '12 at 13:56

so is representation of -128 10000000 or 110000000 ? Is the representaion bit dependent ?

Yes, 2's complement representation is bit dependent

Why not simply make the lower range -127 fot 8 bits instead of writing -128 as 10000000

2^8 = 256. So whatever representation scheme you use, it should be able to represent 256 different values.

And you can draw a circle to understand how good 2's complement system is.

First look at this table :

Bits    Unsigned 2's complement
00000000    0   0
00000001    1   1
00000010    2   2
01111110    126     126
01111111    127     127
10000000    128     −128
10000001    129     −127
10000010    130     −126
11111110    254     −2
11111111    255     −1

for 2's complement system you can draw circle for understanding this system.

Here is the 4 bit version. You can easily develop a 8bit version on yourself. This circle represent what this 2's complement system actually is. Its a circular system. That means its representation depends on the "span" you give it to it. thats why 8bit version of a negative number will differ with a 16 bit version of same negative number. you can compare same negative number in 4bit version given in the circle with 8bit version given in the table.

                      0000  0
                 1111  -1     0001  1


        1110  -2                       0010  2




  1101  -3                                   0011  3



1100  -4                                       0100  4



  1011  -5                                   0101  5




        1010  -6                       0110  6


                 1001  -7     0111  7
                          1000  -8

On a side note, 2's complement arithmetic plays good with "fixed" width computation storages inside computers(registers, memory etc).

In first generation computers, there was a tendency to provide native decimal arithmetic. But this was quickly abandoned in favour of "complemented" or "circular" scheme because, decimal arithmetic is bizarre from a computer's point of view. We find it natural because "we have 10 fingers". These fingers were our ancestor's earliest computation tool. thats why we find decimal system so natural. its built into our genes.

+1 To put it in more mathematical language, 2s complement signed and unsigned just use different representatives for arithmetic modulo 256. Which implies that addition and multiplication result in the same bit pattern, independent of signed or unsigned representation. — starblue, Jul 12 '12 at 20:45
*That means its representation depends on the "span" you give it to it.* But the pattern is very simple. Sign-extending to a wider type just means copying the high bit to all the new bits. — Peter Cordes, Jul 10 '17 at 01:22
Ditto @starblue on the advantages of using two's complement -- from [Wikipedia](https://en.wikipedia.org/wiki/Two%27s_complement): "*The sum of a number and its two's complement will always equal 0 (since the last digit is truncated), and the sum of a number and its one's complement will always equal −0. The two's-complement system has the advantage that the fundamental arithmetic operations of addition, subtraction, and multiplication are identical to those for unsigned binary numbers*". — ruffin, Sep 21 '17 at 12:10

score 6 · Answer 3 · edited Jul 10 '17 at 01:07

6

The alternatives to two's complement would be

one's complement, which has issues due to its "negative zero"
sign/magnitude, which also has a negative zero
not assign a meaning to 10000000, in which case many functions that accept signed 8-bit integers will have to check for that invalid value, wasting time. (Unless your code is running on hypothetical hardware that treats this bit pattern as an integer NaN.)

It's easier to just assign a meaning to that bit pattern, and the natural meaning in the two's complement representation is -128.

For example, in two's complement, checking whether is negative mounts to checking whether its highest bit is set. In a variant where 10000000 is invalid, it's (pseudocode)

if (highest_bit_zero(x))
    return false;
else if (x == 0b10000000)
    ERROR
else
    return true;

You decide how to handle the error :)

edited Jul 10 '17 at 01:07

Peter Cordes

245,674
35
423
606

answered Jul 11 '12 at 13:36

Fred Foo

328,932
68
689
800

The other major alternative is sign/magnitude, which also has a negative zero. The ISO C and C++ standards both specify that signed integer types may be two's complement, one's complement, or sign/magnitude. – Peter Cordes Jul 10 '17 at 00:58
If you did simply disallow `-128`, you could treat it as a NaN, the same as floating-point does. If you use the same semantics as IEEE FP, a comparison could have 4 results: greater, equal, less, or unordered. So `x < 0` would be false (unordered) if `x` was `0x80`. But `x > 0` would also be false, and so would `x == 0`. So would `x == x`. – Peter Cordes Jul 10 '17 at 01:01

score 3 · Answer 4 · edited Jul 10 '17 at 01:13

so is representation of -128 10000000 or 110000000 ? Is the representaion bit dependent ?

In a 9-bit world, it would be 110000000. In a 16-bit world, it would be 1111111110000000. At least, as long as we're talking two's complement.

Why not simply make the lower range -127 for 8 bits instead of writing -128 as 10000000 ?

As larsmans pointed out, you'd end up with an "invalid" value, which you would constantly have to check against. Two's complement has been chosen because it's so easy for the ALU to handle. Just like byte widths have been chosen to be power-of-two (which was not always the case either). At a hardware level, two's complement addition is identical to unsigned, so no special instructions or extra hardware is needed (unlike with one's complement).

With things the way they are, all values with the highest bit set are negative, all values with the highest bit unset are non-negative (positive or zero). Easy, isn't it? The negative range being one larger than the positive range is simply an artifact of trying to keep two's complement simple.

Varun · Answer 5 · 2017-06-25T11:13:22.870

Reason for why you cannot have range from to .

It looks like and are represented by the same pattern. This is not good. A non-zero integer and its negative can't both be represented by the same pattern. So can not be represented in eight bits. The maximum positive integer that can be represented in eight bits is .

What number is represented by 1000 0000? Add the representation of to it:

A good choice for ? is . Therefore 1000 0000 represents . Eight bits can be used to represent the numbers ... 0 ... .

For example, the range of integers that can be represented in eight bits using two's complement is:

Notice that one more negative integer can be represented than positive integers.

Source:- http://programmedlessons.org/AssemblyTutorial/Chapter-08/ass08_20.html

Why is the range of signed byte is from -128 to 127 (2's complement) and not from -127 to 127?

5 Answers5

Linked