Stuffing LSBs of long into unsigned short

Discussion in 'C Programming' started by Fred Ma, Nov 20, 2003.

  1. Fred Ma

    Fred Ma Guest

    Hello,

    I want to assign a long int to an unsigned
    short int. From what I've read, it will do
    what I want, which is to assign as many of
    the least significant bits as can fit.
    Would I be right in assuming that the
    LSBs are used regardless of whether the
    sign is preserved?

    Just for background, I am using a pair of
    long ints returned by Posix's gettimeofday
    to initialize erand48's 48-bit pseudorandom
    generator. The context problem itself is
    not one of ISO C, but the above behaviour
    of assigning long to unsigned is (hopefully)
    generic enough.

    I suspect that the answer is that the bits
    are treated as bits, signedness be damned,
    and regardless of the numeric representation
    (1 or 2's complement, or whatever else might
    be out there). For my purposes, that's OK,
    since the low order bits are still a good
    random seed for when I initialize the
    generator many times in quick succession.
    I'm not using the standard "time" function
    because I may initialize the generator
    within 1 second of the last initialization.

    Thanks for any confirmation or correction
    of this assignment behaviour.

    Fred
     
    Fred Ma, Nov 20, 2003
    #1
    1. Advertisements

  2. Fred Ma

    Fred Ma Guest

    I just realized that I left out some
    description of context problem above.
    In case anyone got puzzled,
    I am using gettimeofday's 32-bit
    tv_usec for the lower 32 bits of
    erand48, and the lower 16 bits of
    tv_sec for the remaining bits in
    erand 48. However, this is extremely
    platform dependent, and quit
    secondary to the generic assignment
    question. Thanks again for any
    replies on the latter.

    Fred
     
    Fred Ma, Nov 20, 2003
    #2
    1. Advertisements

  3. Fred Ma

    pete Guest

    No, the above is true for positive values.

    The rule for conversion, is by value.

    The rule for converting a positive value, to an unsigned short value,
    is to take the modulo (USHRT_MAX + 1) value.

    A particular negative value
    will convert to particular unsigned value,
    regardless of the representation of negative values.
    after:
    int x = -1;
    unsigned short y = x;
    y will be equal to USHRT_MAX,
    regardless of the representation of negative values.

    The rule for converting a negative value, to an unsigned short value,
    is to keep adding (USHRT_MAX + 1), until a positive value is reached.
     
    pete, Nov 20, 2003
    #3
  4. Fred Ma

    Fred Ma Guest


    Hi, Pete,

    I think that what you describe corresonds to
    exactly lopping off the higher bits of an
    integer, regardless of whether it is represented
    as 2's complement in the case of signed numbers,
    or just plain old binary coded decimal in the
    case of unsigned numbers. I highly suspect that
    the rule originates from this, so I'm not surprised.
    Thanks for confirming.

    Fred
     
    Fred Ma, Nov 20, 2003
    #4
  5. Fred Ma

    Eric Sosman Guest

    The procedure is equivalent to "lopping off the bits"
    only for two's complement representations. Although two's
    complement is by far the most common representation in
    contemporary computers, the C Standard permits two other
    representations, at least in theory:

    - Ones' complement. Negative one has the bit
    pattern 11...10, but the result after conversion
    to an unsigned type is 11...11. Note that the
    rightmost bit has changed.

    - Signed magnitude. Negative one has the bit
    pattern 10...01, but the result after conversion
    to an unsigned type is 11...11. Note that all
    but the two extreme bits have changed.

    Binary coded decimal is still in use (perhaps in wider
    use than ones' complement and signed magnitude), but not
    in C implementations: the Standard forbids it, along with
    Gray codes and other clevernesses. (Well, there's the "as
    if rule" that allows the implementation to engage in all
    manner of jiggery-pokery behind the scenes, and it would
    be *possible* to implement C on base-thirteen hardware.
    But the exercise would not be of practical interest.)
     
    Eric Sosman, Nov 20, 2003
    #5
  6. Fred Ma

    Fred Ma Guest


    I sort of expected that there is always some exception
    to the assumption of 2's complement. My point was that
    the C-rule seems to be conveniently based on the picture
    of 2's complement, however this behaviour is realized
    for other representations. That's good enough for me,
    it allows me not to worry about what's really happening
    under the hood.

    Fred

    P.S. There was some article in some Institute
    Electrical and Electronics Engineers publication
    that talks about reasons for changing bases.
    Can't find it in IEEEexplore right now.
     
    Fred Ma, Nov 21, 2003
    #6
  7. Fred Ma

    Fred Ma Guest

    P.S. There was some article in some Institute
    Dimitrov, V.S.; Jullien, G.A.
    "Loading the bases: a new number representation with applications"
    IEEE Circuits and Systems Magazine
    Volume: 3, Issue: 2, Year: Second Quarter 2003

    You're probably right about the fact that there may
    not be the impetus to implement this on general
    purpose processors. Maybe as a hardware engine for
    specialized applications.

    Fred
     
    Fred Ma, Nov 21, 2003
    #7
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.