[OK, that thread is long dead but I din't notice how many miles of
massages I'm behind when I started reading ;-]
On 2002-04-16, Bengt Richter wrote:
On Mon, 15 Apr 2002 21:03:45 -0400, Tim Peters wrote:

In practice, if I'm working with 300-bit bitsets represented as longs, I
never do hex(x), but hex(x & mask) instead, where mask = ~(-1L << 300) (a
string of 300 low-order bits). Regardless of x's sign, that "shows the
bits" in a 1-means-on 0-means-off sense. The key is that I *know* the width
I have in mind, much as hex(int) knows the width of a platform C long today,
so can pull the same trick for regular ints.
Sure. But you can also pick a width for minus_sign-less-but-not-sign_bit-less
hex purposes by defining a normalized width that encompasses just enough bits
to show a hex 0 or F as the first digit, knowing that all to the left are
redundant duplication. (Credit to Greg Ewing for the suggestion of making sure
it's always a reader-friendly leading 0 or F to indicate sign, vs. my ensuring
just an msb of 0 or 1 within the ms hex digit).
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
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...

Beni Cherniavsky <cben at tx.technion.ac.il>

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2022 Grokbase