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
    Dept. of Electronics, Carleton University
    1125 Colonel By Drive, Ottawa, Ontario
    Canada, K1S 5B6
     
    Fred Ma, Nov 20, 2003
    #1
    1. Advertising

  2. Fred Ma

    Fred Ma Guest

    Fred Ma wrote:
    >
    > 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.


    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
    Dept. of Electronics, Carleton University
    1125 Colonel By Drive, Ottawa, Ontario
    Canada, K1S 5B6
     
    Fred Ma, Nov 20, 2003
    #2
    1. Advertising

  3. Fred Ma

    pete Guest

    Fred Ma wrote:
    >
    > 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?


    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
     
    pete, Nov 20, 2003
    #3
  4. Fred Ma

    Fred Ma Guest

    pete wrote:
    >
    >
    > 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



    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
    Dept. of Electronics, Carleton University
    1125 Colonel By Drive, Ottawa, Ontario
    Canada, K1S 5B6
     
    Fred Ma, Nov 20, 2003
    #4
  5. Fred Ma

    Eric Sosman Guest

    Fred Ma wrote:
    >
    > pete wrote:
    > >
    > >
    > > 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

    >
    > 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.


    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

    Eric Sosman wrote:
    >
    > 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.)



    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
    Dept. of Electronics, Carleton University
    1125 Colonel By Drive, Ottawa, Ontario
    Canada, K1S 5B6
     
    Fred Ma, Nov 21, 2003
    #6
  7. Fred Ma

    Fred Ma Guest

    > 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.


    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
    Dept. of Electronics, Carleton University
    1125 Colonel By Drive, Ottawa, Ontario
    Canada, K1S 5B6
     
    Fred Ma, Nov 21, 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. George Marsaglia

    Assigning unsigned long to unsigned long long

    George Marsaglia, Jul 8, 2003, in forum: C Programming
    Replies:
    1
    Views:
    749
    Eric Sosman
    Jul 8, 2003
  2. Daniel Rudy

    unsigned long long int to long double

    Daniel Rudy, Sep 19, 2005, in forum: C Programming
    Replies:
    5
    Views:
    1,247
    Peter Shaggy Haywood
    Sep 20, 2005
  3. David Geering

    longs, long longs, short short long ints . . . huh?!

    David Geering, Jan 8, 2007, in forum: C Programming
    Replies:
    15
    Views:
    592
    Keith Thompson
    Jan 11, 2007
  4. Replies:
    4
    Views:
    866
    Kaz Kylheku
    Oct 17, 2006
  5. fancyerii
    Replies:
    21
    Views:
    1,611
    Roedy Green
    Nov 5, 2007
Loading...

Share This Page