[mturmon]

> ...If you shift that range down so that 0 is in the middle of the range of values instead of the minimum...

Not a downvoter, but: your concept of "shifting the range" is also misleading.

In the source domain of 16-bit numbers, [0...65535] can be split into two sets:

    [0...32767]
    [32768...65535]

The first set of numbers maps to [0...32767] in 2's complement.

But the second interval maps to [-32768...-1].

So it's not just a "shift" of [0...65535] onto another range. There's a discontinuous jump going from 32767 to 32768 (or -1 to 0 if converting the other direction).

And actually, we don't know if the processor used 2's complement or 1's complement -- if it was 1's complement, they would have a signed 0!

I think they'd have to say "remapping" the range? On the whole, I think OP did about as well as you're going to do, given the audience.

[dragonwriter]

> And actually, we don't know if the processor used 2's complement or 1's complement -- if it was 1's complement, they would have a signed 0!

We can infer it used two's complement, and absolutely rule out one's complement or any signed-zero system, because the range is [-2^15,2^15) and with a signed zero you can't represent every integer in that range in 16-bits, you have one too many unique numbers.

[joshAg]

The range is of values, not their representation in bits, which can be mapped in any order. You could specify that the bit representation for 0 was 0x1234 and the bit representation for 1 was 0x1134 and proceeded accordingly and the range of values for those 16 bits could still independently be [-32768, 32767] or [0, 65535] or [65536, 131071] if you wanted.

We know the signed int they're talking about can't be the standard 1's complement because its stated range of values is [-32768, 32767]. If the representation were 1's complement the range would be [-32767, 32767] to accommodate the -0. It could be some modified form of 1's complement where they redefine the -0 to actually be -32768, but that's not 1's complement anymore.