hex(-5) => Futurewarning: ugh, can't we have a better hex than '-'[:n<0]+hex(abs(n)) ??

Discussion in 'Python' started by Bengt Richter, Aug 17, 2003.

  1. >>> hex(-5)
    __main__:1: FutureWarning: hex()/oct() of negative int will return a signed string in Python 2.4
    and up
    '0xfffffffb'
    >>> hex(-5)

    '0xfffffffb'
    >>> hex(-5L)

    '-0x5L'

    That is sooo ugly. I suppose it is for a backwards compatible repr, but couldn't we
    at least have hex(n, newformat=False) so that we can do

    hex(-5, True) => 1xb # 1x signals an arbitrary number of prefixed f's
    hex( 5, True) => 0x5

    and have int() and long() recognize these?

    Also would need a variant of %x and %X for formatting with the % operator.

    Regards,
    Bengt Richter
    Bengt Richter, Aug 17, 2003
    #1
    1. Advertising

  2. "Bengt Richter" <> schrieb im Newsbeitrag
    news:bhomem$jg8$0@216.39.172.122...
    > >>> hex(-5)

    > __main__:1: FutureWarning: hex()/oct() of negative int will return a

    signed string in Python 2.4 and up '0xfffffffb'

    [...]

    There is a thread from this morning ("bitwise not ...") - this should be an
    excellent contribution!
    I have no mercy with someone writing hex(-5)

    Kindly
    Michael P
    Michael Peuser, Aug 17, 2003
    #2
    1. Advertising

  3. Bengt Richter

    Freddie Guest

    "Michael Peuser" <> wrote in news:bhot6f$65j$07$-
    online.com:

    >
    > "Bengt Richter" <> schrieb im Newsbeitrag
    > news:bhomem$jg8$0@216.39.172.122...
    >> >>> hex(-5)

    >> __main__:1: FutureWarning: hex()/oct() of negative int will return a

    > signed string in Python 2.4 and up '0xfffffffb'
    >
    > [...]
    >
    > There is a thread from this morning ("bitwise not ...") - this should be an
    > excellent contribution!
    > I have no mercy with someone writing hex(-5)
    >
    > Kindly
    > Michael P
    >
    >


    What about crazy people like myself? If you generate a crc32 value with zib,
    you occasionally get a negative number returned. If you try to convert that
    to hex (to test against a stored CRC32 value), it spits out a FutureWarning
    at me. So you end up with silly things like this in your code:


    # Disable FutureWarning, since it whinges about us making bad hex values :(
    import warnings
    try:
    warnings.filterwarnings(action='ignore', category=FutureWarning)
    except NameError:
    del warnings


    --
    Remove the oinks!
    Freddie, Aug 18, 2003
    #3
  4. Bengt Richter

    Juha Autero Guest

    Re: hex(-5) => Futurewarning: ugh, can't we have a better hex than

    Freddie <> writes:

    >> There is a thread from this morning ("bitwise not ...") - this should be an
    >> excellent contribution!
    >> I have no mercy with someone writing hex(-5)
    >>
    >> Kindly
    >> Michael P
    >>
    >>

    >
    > What about crazy people like myself? If you generate a crc32 value with zib,
    > you occasionally get a negative number returned. If you try to convert that
    > to hex (to test against a stored CRC32 value), it spits out a FutureWarning
    > at me.


    Read the thread about bitwise not. Tell Python how many bits you
    want. In case of CRC32 that is of course 32 bits:
    hex(-5&2**32-1)

    Two questions: What is the best way to generate bitmask of n bits all
    ones? And would sombody explain why hexadecimal (and octal) literals
    behave differently from decimal literals? (see:
    http://www.python.org/doc/current/ref/integers.html ) Why hexadecimal
    literals from 0x80000000 to 0xffffffff are interpetred as negative
    numbers instead of converting to long integers?

    --
    Juha Autero
    http://www.iki.fi/jautero/
    Eschew obscurity!
    Juha Autero, Aug 18, 2003
    #4
  5. Bengt Richter

    Jeff Epler Guest

    On Mon, Aug 18, 2003 at 07:56:42AM +0300, Juha Autero wrote:
    > Two questions: What is the best way to generate bitmask of n bits all
    > ones?


    def ones(n):
    r = (1l << n) - 1
    try:
    r = int(r)
    except OverflowError:
    pass
    return r

    does this do what you want? It gives these results:

    # 2.3b1 (old, but should have 2.3's long vs int quirks)
    >>> for i in (0, 1, 2, 3, 31, 32, 33, 63, 64, 65):

    .... print "%2s %22s %22s" % (i, `ones(i)`, hex(ones(i)))
    ....
    0 0 0x0
    1 1 0x1
    2 3 0x3
    3 7 0x7
    31 2147483647 0x7fffffff
    32 4294967295L 0xFFFFFFFFL
    33 8589934591L 0x1FFFFFFFFL
    63 9223372036854775807L 0x7FFFFFFFFFFFFFFFL
    64 18446744073709551615L 0xFFFFFFFFFFFFFFFFL
    65 36893488147419103231L 0x1FFFFFFFFFFFFFFFFL

    # 2.2.2
    >>> for i in (0, 1, 2, 3, 31, 32, 33, 63, 64, 65):

    .... print "%2s %22s %22s" % (i, `ones(i)`, hex(ones(i)))
    ....
    0 0 0x0
    1 1 0x1
    2 3 0x3
    3 7 0x7
    31 2147483647 0x7fffffff
    32 4294967295L 0xFFFFFFFFL
    33 8589934591L 0x1FFFFFFFFL
    63 9223372036854775807L 0x7FFFFFFFFFFFFFFFL
    64 18446744073709551615L 0xFFFFFFFFFFFFFFFFL
    65 36893488147419103231L 0x1FFFFFFFFFFFFFFFFL
    Jeff Epler, Aug 18, 2003
    #5
  6. On Mon, 18 Aug 2003 09:16:48 +0200, "Michael Peuser" <> wrote:

    >
    >"Juha Autero" <> schrieb im Newsbeitrag
    >news:...
    >> Freddie <> writes:
    >>
    >> >> There is a thread from this morning ("bitwise not ...") - this should

    >be an
    >> >> excellent contribution!
    >> >> I have no mercy with someone writing hex(-5)
    >> >>
    >> >> Kindly
    >> >> Michael P
    >> >>
    >> >>
    >> >
    >> > What about crazy people like myself? If you generate a crc32 value with

    >zib,
    >> > you occasionally get a negative number returned. If you try to convert

    >that
    >> > to hex (to test against a stored CRC32 value), it spits out a

    >FutureWarning
    >> > at me.

    >>
    >> Read the thread about bitwise not. Tell Python how many bits you
    >> want. In case of CRC32 that is of course 32 bits:
    >> hex(-5&2**32-1)
    >>
    >> Two questions: What is the best way to generate bitmask of n bits all
    >> ones?

    >
    >Why do you object to 2**n-1? This is just fine I think.
    >
    >> And would sombody explain why hexadecimal (and octal) literals
    >> behave differently from decimal literals? (see:
    >> http://www.python.org/doc/current/ref/integers.html ) Why hexadecimal
    >> literals from 0x80000000 to 0xffffffff are interpetred as negative
    >> numbers instead of converting to long integers?

    >
    >Most of all this has practical reasons because of the use most programmers
    >have for stating hexadecimal literals.
    >
    >Of couse some hex literals are not interpreted as negative numbers but the
    >memory contents, because it has become undistinguishable what the origin had
    >been.
    >
    >One will not expect
    > print int(0xffffffff )
    >do something different from
    > x=0xffffffff
    > print int(x)
    >

    Unfortunately, the path to unification of integers to hardware-width independence
    has backwards compatibility problems. I guess they are worse than for true division,
    but has anyone really attempted to get a measure of them?

    The options for hex representation seem to be (in terms of regexes)

    1) signed standard: [+-]?0x[0-9a-fA-F]+
    2) unprefixed standard: [0-9a-fA-F]+
    which are produced by hex() and '%x' and '%X'
    and interpreted by int(x, 16)

    There is a need for a round trip hex representation/interpretation for signed integers
    of arbitrary size, but IMO a prefixed '-' does violence to the usual expectation
    for hex representation (i.e., a sensible view of the bits involved in a conventional
    "two's complement" representation of the number to whatever width required).

    I hope it can be avoided as a default, but that at a minimum, that an alternative will be provided.

    For hex literals, the [01]x[0-9a-fA-F]+ variation seems clean (I forgot again who came up with that as
    the best emerging alternative in an old thread, but credit is due). Tim liked it too, I believe ;-)

    Since hex() will change anyway, how much more breakage will hex(-1) => 1xf create vs => -0x1 ?
    Not to harp, but obviously the -0x1 gives no sense of the conventional underlying bit pattern
    of ...fffff. (I am talking about an abstract bit pattern that extends infinitely to the left,
    not a concrete implementation. Of course it is often useful to know how the abstraction gets
    implemented on a particular platform, but that is not the only use for hex. It is also handy
    as a human-readable representatation of an abstract bit sequence).

    The other question is what to do with '%x'. The current 2.3 version doesn't seem to pay much
    attention to field widths other than as a minimum, so that may offer an opportunity to control
    the output. It does not generate an '0x' prefix ( easy for the positive case to specify as
    0x%x) yet negatives presumably will prefix a '-'. (Will 0x-abcd be legal??)
    What are some other possibilities?

    Looking forward to using widths, what would one hope to get from '%2.2x'%-1 ?
    I would hope for 'ff', personally ;-) And ' 1' for '%2.2x'%1 and '01' for %02.2x'%1.

    Coming at it from this end, what happens if we drop the max width? What should we get
    for '%02x'%1 ? That's easy: '01' as now. But '%02x'%-1 => 'ffffffff' currently, and that has
    to change. Apparently to '-1' if things go as they're going? (Again, hexness is lost).

    A possibility for unrestricted output width would be to print enough hex characters for an
    unambiguous interpretation of sign. I.e., so that there are enough bits to include the sign
    and an optional number of copies to pad to a full 4-bit hex character as necessary. This would
    mean '%02x'%-1 => ff since that gives the first hex character the right sign.

    That has the wrong interpretation (if you want to recover the signed value) for
    int(('%02x'%-1),16) so that would need a fix for easy use. Although I usually dislike passing
    flag info to functions by negating nonzero parameters, it would have mnemonic value in this case.
    E.g., int(('%02x'%-1), -16) or the equivalent int('ff', -16) could mean use the leading bit as sign.
    This convention would translate nicely to octal and binary string representations as well.

    Of course int(('%02x'%255) could not return 'ff' as an unconstrained-width representation. It
    would have to be '0ff' to provide the proper sign. Note that constraining this to a max width
    of 2 would give 'ff'. This works for octal and binary too.

    IMO this way of avoiding '-' in hex, octal, and binary string formats would make the strings
    represent the data more clearly. These formats are mainly to communicate bit patterns IMO,
    not just alternative ways to spell integer values.

    If we have 1xf as a literal for spelling -0x1, I guess we don't need a literal format
    for the leading-bit-as-sign convention. But the latter would be a way of reading and writing
    signed arbitrary-width hex without losing the hexness of n the way you would with

    '%c%x'%('-'[:n<0],abs(n)) #yech, gak ;-/

    Regards,
    Bengt Richter
    Bengt Richter, Aug 18, 2003
    #6
  7. Bengt Richter

    Juha Autero Guest

    Re: hex(-5) => Futurewarning: ugh, can't we have a better hex than

    "Michael Peuser" <> writes:

    >> Two questions: What is the best way to generate bitmask of n bits all
    >> ones?

    >
    > Why do you object to 2**n-1? This is just fine I think.


    Maybe I should have said "What other ways there are to generate a
    bitmask of n bits all ones?" 2**n-1 seemed like a hack since it relies
    on certain properties of binary numbers, but on the other hand all
    bitmask processing relies on certain properties of binary numbers.

    --
    Juha Autero
    http://www.iki.fi/jautero/
    Eschew obscurity!
    Juha Autero, Aug 19, 2003
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mike

    FutureWarning question

    Mike, Apr 13, 2004, in forum: Python
    Replies:
    2
    Views:
    344
    A. Lloyd Flanagan
    Apr 13, 2004
  2. Egor Bolonev

    FutureWarning

    Egor Bolonev, Dec 24, 2004, in forum: Python
    Replies:
    2
    Views:
    354
    Bengt Richter
    Dec 28, 2004
  3. Grant Edwards
    Replies:
    8
    Views:
    387
    J Correia
    Apr 6, 2005
  4. Peter Bencsik
    Replies:
    2
    Views:
    808
  5. Klaas Vantournhout

    f2c's abs conflicts with <complex> abs

    Klaas Vantournhout, Oct 31, 2006, in forum: C++
    Replies:
    3
    Views:
    375
    Victor Bazarov
    Oct 31, 2006
Loading...

Share This Page