The thing with signed complement is I didn't see how it could be
implemented with a common algorithm, since the wrap around is at the
same point and lands in a different place ... -MAX and 0.
But if in signed magnitude an unsigned number cannot specific a number
that is a signed negative, there's no problem ... just do the signed
WITHIN and its valid for unsigned.
On Mar 31, 5:21 pm, Jonah Thomas <jethom...@[EMAIL PROTECTED]
> wrote:
> 1's complement can be designed like sign magnitude to allow only
> unsigned numbers that leave the sign bit unset. Then there should be no
> trouble except with -0. But if you have high unsigned numbers you have a
> problem. In an illustrative 16-bit 1's-complement system, -0 = 65535 and
> -1 = 65534. So when you do an implicit conversion between negatve and
> high unsigned numbers, you get a different result from 2's-complement.
> If you get the same result for -2 2 WITHIN for both systems, then you'll
> have to get different results for 65533 2 WITHIN .
Huh?
-2 2 WITHIN should be TRUE (-0) for -2 -1 -0 0 1
True for -2 stepping by 1+, including wrap-around, until and not at 2.
65533 2 WITHIN should be TRUE (-0) for 65533 65534 65535 0 1
True for 65533 stepping by 1+, including wrap-around, until and not at
2.
Sure you get a different result from 2's complement if you write the
value in binary and then change the base to DECIMAL, but if you write
both the value to test and the range as one's complement numbers,
that's _pari passu_.
So after thinking that through, I'm thinking that the U< based WITHIN
works for one's complement signs, provided you are willing to accept
that 0's sort as:
-1 < -0 < 0 < 1
.... since in that approach, -0 -10 0 WITHIN would yield -0 or TRUE.
That seems reasonable to me, though, since ( value negative 0 ) WITHIN
to me feels like a test for a negative smaller or equal to a given
magnitude, and -0 would be your negative number smaller than any other
negative number.
|
