On 14 Aug 2002, Martin v. Loewis wrote: >Oren Tirosh <oren-py-d@hishome.net> writes: > >> >>> hex(-16711681) >> '0xff00ffff' >> >>> hex(-16711681L) >> '-0xff0001L' # ??!?!? >[...] >> The hex representation of longs is something I find quite misleading and >> I think it's also unprecedented. This wart has bothered me for a long >> time now but I didn't have any use for it so I didn't mind too much. Now >> it is proposed to extend this useless representation to ints so I do. > >I don't find it misleading - in fact, the C representation is >misleading: 0xff00ffff looks like a positive number (it does not have >a sign) - this is misleading, as the number is, in fact, negative. > >The representation is not misleading: it does not make you believe it >is something that it actually isn't. It might be surprising, but after >thinking about it, it should be clear that it is correct: -N is the >number that, when added to N, gives zero. Indeed: > >>>> -16711681L+0xff0001L >0L > >If you want the bitmask for the lowest 32 bits, you can write > >>>> hex(-16711681L & (2**32-1)) >'0xFF00FFFFL' > >Notice that -16711681 is a number with an infinite amont of leading >ones - just as 16711681 is a number with an infinite amount of leading >zeroes. Just a thougth: if it's true that those using hex() and %x are more interested in the bit values than the numerical value of the whole number, would a format like ~0xff000 be easier to interpret (and stop this debate) ? /Paul
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4