Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!ucsd!sdcsvax!ucsdhub!hp-sdd!trwrc!agnew
From: agnew@trwrc.UUCP (Robert A. Agnew)
Newsgroups: comp.lang.modula2
Subject: Re: WriteInt(-32768, n)
Summary: -32768 a BOGUS number
Message-ID: <503@trwrc.UUCP>
Date: 20 Apr 89 20:31:04 GMT
References: <1007@psueea.UUCP> <1029@gmdzi.UUCP>
Organization: TRW-MEAD, San Diego, Ca.
Lines: 34

In article <1029@gmdzi.UUCP>, kloppen@gmdzi.UUCP (Jelske Kloppenburg) writes:
> That is correct:
>    int is declared as INTEGER and -32768 is LONGINT.

	Whether -32768 is or is not a legal number in two's compliment number
systems is a topic which could spark a lot of worthless discussion, but I
hope not.  It seems that each implementor treats it differently. In theory,
two's compliment arithmetic is modulo 32768 arithmetic and as such should not
be capable of expressing the modulus. The most common implementation of
two's compliment arithmetic uses the MSB bit to signify a negative number. The
lower 15 bits, the mantissa, are two's complimented. Theoretically, that
means -n (0 <= n <= 32767) is represented by 32768 - n which are congruent
modulo 32768. This operation is accomplished in hardware by taking the one's
compliment ( logical NOT) and adding 1. This works because the logical 
compliment of n is 32767 - n (try it).

	The problem arrises because the value 0x8000 can and does occur. The 
hardware interprets this number as -0, a value which is regarded by many
to be as unclean and wierd as the square root of minus one; many systems
thus treat it as an "illegal" number. Other systems choose to interpret it
as -32768 since 32768 is congruent to 0 modulo 32768. 0x8000 behaves like
any other number in most respects and produces correct results. The only
bizarre thing about this number is that is it's own two's compliment; i.e.
the ones compliment of 0x8000 is 0x7FFF and adding 1 yields 0x8000. Now
since -(-0) = -0 does that mean that -0 is not negative to begin with? We
note no overflow occurs in this example, but how do we get the value in
the first place?

	I cannot think of any computation that produces 0x8000 without
causing an overflow (carry into sign bit # carry out of sign bit) short
of getting it from a 16 bit A/D converter where it's usually considered
BOGUS. Since, it does not occur naturally in signed arithmetic, why should
we admit it? The problem is that most hardware manufacturers specify the 
range of signed 16 bit numbers to be -32768 to +32767.