On Fri, 14 Jan 2005 20:13:48 +0100, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>Bengt Richter wrote: >> On Thu, 13 Jan 2005 08:18:25 -0500, Peter Hansen <[EMAIL PROTECTED]> wrote: >> >>>[EMAIL PROTECTED] wrote: >>>> In Mythical Future Python I would like to be able to use any base in >>>> integer literals, which would be better. Example random syntax: >>>> >>>> flags= 2x00011010101001 >>>> umask= 8x664 >>>> answer= 10x42 >>>> addr= 16x0E800004 # 16x == 0x >>>> gunk= 36x8H6Z9A0X >>> >>>I think I kinda like this idea. Allowing arbitrary values, >>>however, would probably be pointless, as there are very >>>few bases in common enough use that a language should make >>>it easy to write literals in any of them. So I think "36x" >>>is silly, and would suggest limiting this to 2, 8, 10, and >>>16. At the very least, a range of 2-16 should be used. >>>(It would be cute but pointless to allow 1x000000000. :-) >>> >> My concern is negative numbers when you are interested in the >> bits of a typical twos-complement number. (BTW, please don't tell me >> that's platform-specific hardware oriented stuff: Two's complement is >> a fine abstraction for interpreting a bit vector, which is another >> fine abstraction ;-) >> >> One way to do it consistently is to have a sign digit as the first >> digit after the x, which is either 0 or base-1 -- e.g., +3 and -3 would be >> >> 2x011 2x101 >> 8x03 8x75 >> 16x03 16xfd >> 10x03 10x97 > >Why not just -2x11? IMHO, Py2.4 does not produce negative values out of >hex or oct literals any longer, so your proposal would be inconsistent. > Inconsistent with what? This is a new based-literal representation, not the old hex or octal representation. It is separate and self-consistent, and can live along side the old. The fact that there is no longer a way to represent negative numbers with traditional octal or hex is due to getting away from the platform-dependent assumptions that bit 31 was a sign bit of a 32-bit two-s complement machine represenentation. That was a good thing to get away from. But it means you now have to write a unary minus expression for negative numbers, not a self-contained literal. Re your question, -2x11 is the same as -(2x11) so you have to decide what you want 2x11 to mean. If it means +3, we are back to the original problem of having no way to see any of the 111111111111....101 or ffff....fd of a -3 ;-) (Except of course by '%02x'%(-0x3&0xff) -- ick) I am not proposing a change to the new Py2.4 positive-only hex and octal literals. I just want to be able to write literals for both positive and negative numbers as self-contained literals (not expressions) without a '-' sign, and have the representation be a readable representation of typical twos-complement representation. You can't do that with -0x3, because (though the expression equals -3) it doesn't show the information about the bits that you get with 16xfd or 2x101. Note that -16xfd == 16x03 and -2x101 == 2x011 and -16x03 == 16xfd and -2x011 == 2x101. The '-' sign is not part of the literal. Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
