Does Python need a '>>>' operator?
bokr at oz.net
Tue Jun 11 12:01:04 CEST 2002
On Mon, 10 Jun 2002 14:11:31 +0300 (IDT), Beni Cherniavksy <cben at techunix.technion.ac.il> wrote:
>On 2002-06-10, Ken Seehof wrote:
>> Beni Cherniavsky <cben at tx.technion.ac.il> wrote:
>> > I just got another idea: use 0x1234 for 0-filled numbers and 1xABCD for
>> > 1-filled ones. That way you impose no restrictions on what follows the
If there are no restrictions, 1x7 must have a meaning.
What do you want it to mean?
>> > prefix and keep backward compatibility. 0xFFFFFFFF stays a 2^n-1
>> > _positive_ number, as it should be. The look of 1x is weird at first but
>> > it is very logical...
Well, consider the logic of a different format: The prefix is always 0h
and the hex data part always includes just enough duplicated-as-necessary
sign bits to make the first hex digit 0 for positive numbers and f for negative.
IOW, you could pretend to store the integer value in a 4*k bit wide register,
where k is just large enough so the top 4 bits are either all 0 or all 1.
Then just print with k hex digits for the data.
A previous version had a bug for sure, and I never got around to fixing it
and posting it to answer Martin's last objection. Still no guarantees, but
the version below illustrates the format...
>Unfortunately, you cannot represent such a number in hex, atleast not
>under any of the usual conventions: the convention is that you can
>strip infinitely many leading zeroes, but stripping off infinitely many
>leading ones is confusing.
With Greg Ewing's suggestion (to make sure leading hex digits are 0 or F rather
than just having 0 or 1 in the msb of the first hex digit to indicate sign, as
I had first suggested), I think it can be done very clearly:
Pretend that you have printed with extra width (e.g., infinite) and just strip
leading duplicate 0's or F's from the left of the data part until you have either
0h0.... or 0hF....
This illustrates the format, anyway:
>>> def newhex(n, width=0):
... """prints hex bits with leading 0 for positive and leading f for negative"""
... if n<0: nh = ((~long(n))<<4)&long(n)
... else: nh = (( long(n))<<4)&(~long(n))
... nh = len('%x' % nh)
... ret = '0h%s%x' % ((n>0 and '0' or ''),long(n)&((1L<<(nh*4))-1))
... if width>len(ret):
... return '0h'+ret*(width-len(ret))+ret[2:]
... return ret
>>> for i in range(12): print '%16s%16s' % (newhex( 1L<<i ), newhex(-1L<<i ))
>>> for i in range(12): print '%16s%16s' % (newhex( 7L<<i ), newhex(-7L<<i ))
>>> for i in range(12): print '%16s%16s' % (newhex( 1L<<i,5), newhex(-1L<<i,5))
>>> for i in range(12): print '%16s%16s' % (newhex( 1L<<i,10), newhex(-1L<<i,10))
>>> for n in xrange(-32,33,4): print '%3d %16X %s' % (n,n,newhex(n))
-32 FFFFFFE0 0hfe0
-28 FFFFFFE4 0hfe4
-24 FFFFFFE8 0hfe8
-20 FFFFFFEC 0hfec
-16 FFFFFFF0 0hf0
-12 FFFFFFF4 0hf4
-8 FFFFFFF8 0hf8
-4 FFFFFFFC 0hfc
0 0 0h0
4 4 0h04
8 8 0h08
12 C 0h0c
16 10 0h010
20 14 0h014
24 18 0h018
28 1C 0h01c
32 20 0h020
After 0h0 or 0hf there are no restrictions to the hex that follows (or doesn't),
and the abstract integer value is unambiguously determinable.
More information about the Python-list