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

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 ?

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?).

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.

Fred Foo

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 :)

DevSolar

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.

Reason for why you cannot have range from