math - 为什么有符号字节的范围是从 -128 到 127（2 的补码）而不是从 -127 到 127？

Question

我读了为什么Java中的字节范围是-128到127？它说

128是10000000，倒过来就是01111111，加一又是10000000

所以它得出结论 -128 是 10000000

所以 +128 不能用 8 位的 2 的补码表示，但这意味着我们可以用 9 位表示它，所以 128 是 010000000，所以取它的 2 的补码 -128 是 110000000，

-128 10000000 或 110000000 的表示也是如此吗？表示位依赖吗？

为什么不简单地将较低范围 -127 fot 8 位而不是将 -128 写为 10000000 ？

score 48 · Accepted Answer

为什么无符号字节的范围是-128到127？

它不是。一个无符号字节（假设为 8 位）是从 0 到 255。

使用 2 的补码的有符号字节的范围是从 -128 到 127，直接来自2 的补码的定义：

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

-128 10000000 或 110000000 的表示也是如此吗？

在 8 位中，它是10000000，在假设的 9 位表示中，它是110000000.

为什么不简单地为 8 位设置较低的范围 -127？

人为地将范围限制为 -127 不会有太大的效果；您将不允许一个完全有效的值，并且通常会使代码更复杂（您还会对位模式做10000000什么？）。

score 18 · Accepted Answer

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.

score 6 · Accepted Answer

二进制补码的替代方案是

一个补码，由于其“负零”而存在问题
sign/magnitude，它也有一个负零
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 :)

score 3 · Accepted Answer

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.

score 2 · Accepted Answer

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 .