Stuffing LSBs of long into unsigned short

F

Fred Ma

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
 
F

Fred Ma

Fred said:
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
 
P

pete

Fred said:
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.
 
F

Fred Ma

pete said:
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.


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
 
E

Eric Sosman

Fred said:
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.)
 
F

Fred Ma

Eric said:
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.
 
F

Fred Ma

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
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top