Does Python need a '>>>' operator?

[Bengt Richter]

On Mon, 15 Apr 2002 00:06:34 -0700, "Ken Peek" <Ken.Peek at SpiritSongDesigns.comNOSPAM> wrote:

>
>"Martin v. Loewis" <martin at v.loewis.de> wrote in message
>news:m34ridmq00.fsf at mira.informatik.hu-berlin.de...
>
>| That's what I'm trying to tell you all the time: the
>| '>>>' operator is meaningless if it is defined as
>| "fill in zeroes". How does it know where to start
>| inserting zeroes?
>
>No, it isn't meaningless:
>
>The 'long' class has an internal representation for the
>long number.  The number of bytes that are currently
>being used to contain the number are known (internally)
>to the object.  The zeroes get shifted into the high bit
>of the number, no matter how many bytes are used to
>contain the number.
>
Actually the longs may not be byte-based at all. They could
be based on an array of shorts with 15-bit values. You don't
want to see the actual bit pattern of that, do you? At least,
not as a general purpose thing.

>An int type simply shifts a zero into bit 31, so that
>this works the same as it will on a long.
>
>The '>>' operator should also work the same for a long
>as it does for an int.
It can't, because the long does not represent a fixed-width
bit pattern, it represents an infinite bit pattern. The infinite
comes from extending the sign bit. Thus shifting in zeroes at
the 'top' of a negative number implies shifting them in at bit
position infinity. You can say that we don't actually use an
infinite number of bits in the internal representations, but
the/a point of numeric unification is to hide that representation.
All you can legitimately refer to is the implied abstraction, which
has indefinitely extended sign bits.

If you do choose some top bit in the indefinite extension as 'the'
sign bit, it should be done consistently, and what you are doing
should be clear. For example, if you scanned down from the left until
you found two adjacent differing bits (or a single bitif you reach the
bottom) you could say the ms bit of those was 'the' sign bit. Now you have
a width, and this can be computed for any integer, positive or negative.

On the basis of that width, you could shift in zeroes. I'm not sure how
useful that is, but I would say it would be more consistent that picking
an arbitraryly occuring k*4 or k*8 or k*15 bit width value that you might
get from the current state of an internal representation.

In any case, you can define a function to whatever you actually want.
(I suspect you'll wind up specifying width explicitly). But if
you want a >>> operation, what width should it use? Remember, different
platforms may use different internal long representations.

>
>The '<<' operator should also work the same for a long
>as it does for an int.
>
That one's easy ;-)

>The 'hex()' method should work the same for a long as
>it does for and int.
>
I think that's agreed too, just not the details. I agree with you that
sign/magnitude is not very useful if you're interested in bits. (I might
be referring to different bits than you though).

>Why is this so confusing to you?  Java programmers have
>been putting the difference between the '>>' and the
>'>>>' operators to good use for years!
>
I doubt whether Martin is confused, but he may have a different perspective.

Regards,
Bengt Richter