Does Python need a '>>>' operator?

[Bengt Richter]

On 15 Apr 2002 23:06:43 +0200, martin at v.loewis.de (Martin v. Loewis) wrote:

>bokr at oz.net (Bengt Richter) writes:
>
>> IMO 'internal representation' is a red herring. We have an abstract
>> concept of number representation (twos complement) that corresponds
>> to many hardware devices' usage, but it is the abstraction that is
>> important IMO, not the hardware.
>
>Yes, but this notion is inherently bound with the notion of "size" of
>an integer, atleast in the signed variant (for unsigned integers,
>there is no need for twos complement). If you create the complement,
>you have to know how many bits to invert.
All of them ;-) I don't need an infinite number of representation bits
if they are all the same value. Thus sign can be considered to be
indefinitely extended in the abstraction, and you don't need to specify
width.
>
>I absolutely agree with your (earlier) conclusion that bit arithmetic
>is best done with unsigned numbers.
I don't remember using those words ;-) In any case, in the abstract, you
don't do bit arithmetic on the numbers per se (i.e., taking a number
as a point on the real axis). We first have to get to bits. And I think
you can get to bits just as well from negative numbers as from positive.
What's the difference between an infinite number of extended 0 sign bits
vs the same number of 1 sign bits? Either way, they're all the same and
can be represented by a single bit.

>
>> When looking at integers cast as arrays of booleans, hex provides a
>> representation, but w.r.t. boolean values it is not very useful to
>> print it as base-16 integer with sign+absolute value.
>
>I also agree.
>
>> If I infer correctly, Ken is arguing that hex is more often used to
>> view the boolean aspect of integers than their numeric
>> aspect. That's true for me too.
>
>And so it is for me. Still, I disagree that a display of a hex number
>with a sign is illogical or incorrect. In fact, when talking about
>"unbounded" numbers, it is illogical to assume twos complement.
>
I don't think I said it was illogical. I didn't mean to. As you pointed out,
base 16 is just another base that can be used like base 10, and analogous
signed representations of numbers are logical. I just think the signed
hex is not terribly useful.

>> >Yes-- I read the PEP too-- when this happens, I will consider it a
>> >Python "_WART_", and will set about inventing ways around it for my
>> >own use.  I have forgotten more computer languages than most people
>> >will ever learn-- an I have NEVER found printing a hexadecimal
>> >number in sign and magnitude format to be useful...
>>
>> I'll second that.
>
>At a minimum, you need to propose an alternative behaviour then. I
>must say that I don't find the proposed behaviour of mandatory leading
>zeroes (the 0h proposal) very intuitive, or following tradition.
Actually, my intent was to follow tradition, but tradition in hex
representation needed an adaptation to work for non-fixed width integers.
It occurred to me that if you included an actual sign bit the way the
traditional integer hex representation does, then all you'd have to
do was to make sure positive numbers had a zero sign bit represented.
That would imply a leading zero hex digit if the next digit was binary 1xxx.
Pretty simple.

>
>Instead, there is a simple solution: use unsigned numbers if you want
>to represent bit arrays.
>
Well, that assumes I want to use bit arrays without transformations
to/from general signed integers. That's a bit restrictive.

>> I would guess so. I do. But for language purposes my preference is
>> to refer to an abstract bit pattern, not hardware (even though
>> hardware mappings will exist and be useful).
>
>That is only meaningful for positive numbers - it just doesn't work
>for twos complement.
>
I works fine the way I'm thinking of it ;-) You must be looking at
it differently, and I'm not sure what view it doesn't work for.
My view is an abstraction where the sign bit is indefinitely duplicated
to the left, but since they're all the same, you can think of them
as represented by a single sign bit. If there is more than one bit
in the whole number, the top two bits will be different. In any case,
the top bit's value will be -(0|1)*2**N and the rest (0|1)*2**n, where
n is >=0 and <N. Ie.e, if the bits are numbered 0..N from the lsb,
and have values b[n], the numerical value would be
-b[N]*2**N plus b[n]*2**n for n=0..N-1.

Duplication of the topmost bit (changing N) doesn't change the numeric value,
whether + or -, so you can consider it to extend indefinitely, if convenient.
To represent such a number in hex, you would duplicate the
sign bit to fill the top hex digit. Thus +3and -3would be

+3   (0)011  0h7 -0*2**2 + 1*2**1 + 1*2**0    0+2+1 =  3  or  0+0+2+1
-3   (1)101  0hd -1*2**2 + 0*2**1 + 1*2**0   -4+0+1 = -3  or -8+4+0+1

The (x) are duplications to fill out the hex digit
but +8 and -8 would be

+8   01000 => 0001000 => 0h08  -0*2**4 + 1*2**3 + 0*2**2 + 0*2**1 + 0*2**0   0+8+0+0+0 =  0
-8    1000 =>    1000 => 0h8            -1*2**3 + 0*2**2 + 0*2**1 + 0*2**0    -8+0+0+0 = -8
or with a redundant digit
-8   11000 => 1111000 => 0hf8
 => -1*2**7 +  1*2**6 + 1*2**5 + 1*2**4 +1*2**3 + 0*2**2 + 0*2**1 + 0*2**0
       -128       +64      +32      +16      +8       +0       +0       +0  = -8

Of course the "two" in twos complement is scaled to match whatever point you want to stop at,
even infinity, by induction ;-)

Regards,
Bengt Richter