On 4/17/22 8:21 AM, Robin Vowels wrote:
> On Saturday, April 16, 2022 at 1:18:40 PM UTC+10, gah4 wrote:
>> On Friday, April 15, 2022 at 7:39:02 PM UTC-7, Robin Vowels wrote:
>>
>>
>>> They are NOT twos complement products. [when an integer is squared]
>>> The products are ALWAYS positive.
> .
>> Two's complement is the representation used on most machines now.
>>
>> It can represent both negative and positive values. It is still called
>> two's complement even when the values are positive.
> .
> You are mistaken. It is only negative values that are represented
> in twos complement form.
Here is the wikipedia article about twos-complement arithmetic.
https://en.wikipedia.org/wiki/Two%27s_complement
As you can see there, the term "twos-complement" can be regarded both as
an operation applied to a string of bits and also as the name of the
storage representation used for integers.
For this discussion, the important feature of twos-complement arithmetic
(i.e. the storage representation) is that the bits that result from
integer operations for the signed twos-complement values are the same as
would result from treating those bits as an unsigned integer and
ignoring any overflow of the high-order bit. Thus the "twos-complement
operation" never appears explicitly in the addition and multiplication
integer operations, the correct result just happens naturally.
Another interesting way to view the twos-complement representation
(which is discussed in that wiki article) is that the integer value of
an unsigned integer is simply the result of the polynomial evaluation
Sum(i=0:N-1) b(i) * 2**(i)
over all the bits. The twos-complement value for those same bits is the
same expression, except the high-order bit term is replaced by
-b(N-1)*2**N. I learned this long ago from one of Hamming's books, and
over the years, that expression has clarified a lot of algorithms for me.
This then brings up the lack of an unsigned integer type in fortran. If
all hardware supported two-complement arithmetic, then I think it would
be straightforward to allow this type into the language. Compilers would
need to do little to support the type and its semantics. But those
computers that use different integer representations (e.g.
ones-complement and signed-magnitude), the twos-complement results would
need to be simulated, and that could be expensive and slow. I'm not
familiar with the current C standard, but in the past the C language
punted on this issue by defining results for unsigned arithmetic only
when there is no overflow (i.e. when the high-order bit can be ignored).
If a C compiler happens to give correct results also when there is
overflow (i.e. when the high-order bit comes into play), then that is
great, but it was not required by the language. Fortran could have taken
that same approach, but it didn't.
This issue also arises in the discussions over the decades for fortran
to support an intrinsic bit data type. When those bits are moved between
the bit data type and integer variables, then the meaning of the
high-order bit, or the sign bit, must be accounted for correctly, making
portable code difficult to write.
$.02 -Ron Shepard