Representing a Sequence of Shorts in Bits

[Hahnemann]

Is there a sample in C out there to represent a sequence of numbers
(shorts) using bits? With the intention of saving space, instead of
using the full 16 bits per short. Thanks.

- Hahnemann

[viza]

Hi

On Wed, 25 Jun 2008 15:23:28 -0700, Hahnemann wrote:

Is there a sample in C out there to represent a sequence of numbers
(shorts) using bits? With the intention of saving space, instead of
using the full 16 bits per short. Thanks.

So, if the short is 0, you set the bit to 0.
If the short is 1 you set the bit to 1.
If the short is 2... do you see the problem yet?
The bit can only contain 0 or 1.

If you have a large number of shorts, and there is significant
correlation between them, ie: many of them have the same value or they
follow some pattern, then you can compress the data and save some space
at the expense of time, but even then in most cases you will do well to
get 16:1.

Try http://google.com/search?q=compression+algorithms

HTH

[Ben Bacarisse]

viza <to******@gmil.comwrites:

On Wed, 25 Jun 2008 15:23:28 -0700, Hahnemann wrote:

>Is there a sample in C out there to represent a sequence of numbers
(shorts) using bits? With the intention of saving space, instead of
using the full 16 bits per short. Thanks.

So, if the short is 0, you set the bit to 0.
If the short is 1 you set the bit to 1.
If the short is 2... do you see the problem yet?
The bit can only contain 0 or 1.

I think the OP is looking represent a set of smallish integers as a
bit set. The term sequence is confusing but the OP had written "set"
everywhere where they wrote "sequence" I think you'd have offered a
different answer.

To the OP: search for "bit set in C" or something like that.

--
Ben.

[CBFalconer]

Hahnemann wrote:

>
Is there a sample in C out there to represent a sequence of numbers
(shorts) using bits? With the intention of saving space, instead of
using the full 16 bits per short. Thanks.

shorts can have any number of bits. To get an idea of the size on
your system, have your machine print out the value of USHRT_MAX,
after "#include <limits.h>". Another indicative value is
"(sizeof(short) * CHAR_BIT)".

You can save unsigned values upto USHRT_MAX in an unsigned short.
Upto UCHAR_MAX in an unsigned char. Remove the Us and you can save
negative values, down to SHRT_MIN and SCHAR_MIN, in short and
signed char. Now you will have to use SHRT_MAX and SCHAR_MAX for
the upper limits.

Read that limits.h file.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[rahul]

On Jun 26, 3:23 am, Hahnemann <[e-mail]:

Is there a sample in C out there to represent a sequence of numbers
(shorts) using bits? With the intention of saving space, instead of
using the full 16 bits per short. Thanks.

- Hahnemann

You can save some space by using bitwise operators to store and
retrieve the values but remember, you can not actually read and write
in terms of bits ( not even in assembly/machine language). If you are
writing 1, even though it can be represented using 1 bit, you will
have to use 1 byte.

I am not aware how a typical bit set works but that too is not going
to very helpful in saving space.

[forkazoo]

On Jun 25, 11:16*pm, rahul <[e-mail]:

I am not aware how a typical bit set works but that too is not going
to very helpful in saving space.

If the platform provides a 16 bit short, and the range of values the
OP is interested only range between, for example, 0-511, then you
could pack each number into 9 bits. This would be nearly half the
storage space.

Obviously, the utility of such a technique depends on the situation.

[Hahnemann]

I read the following from a book called "Compression Algorithms for
Real Programmers":

"...Programmers have long known that it is silly to use double
precision values or long integers when regular floating point numbers
or integers will serve the purpose... David Kopf takes this one step
further with an algorithm that carefully adjusts the number of bits in
a sequence. If this is too many bits, then it reduces the size by i
bits for the next value. If it is too few, then it increases the size
by j bits and repeats the value. In some cases, the algorithm uses a
fixed i and j, and, in others, it uses a preset number".

I am wondering how this works in actual C code. I Googled that
algorithm but I can't find it. Does this make sense? Maybe I'm
getting this "packing of bits" idea incorrectly.

- Hahnemann

[pete]

Hahnemann wrote:

I read the following from a book called "Compression Algorithms for
Real Programmers":

"...Programmers have long known that it is silly to use double
precision values or long integers when regular floating point numbers
or integers will serve the purpose... David Kopf takes this one step
further with an algorithm that carefully adjusts the number of bits in
a sequence. If this is too many bits, then it reduces the size by i
bits for the next value. If it is too few, then it increases the size
by j bits and repeats the value. In some cases, the algorithm uses a
fixed i and j, and, in others, it uses a preset number".

I am wondering how this works in actual C code. I Googled that
algorithm but I can't find it. Does this make sense? Maybe I'm
getting this "packing of bits" idea incorrectly.

It's wrong in C.

Your default choice of floating point type should be (double).
If you want the smallest, then use (float).
If you want the one with the most precision or range,
then use (long double).

(float) is implicitly converted to (double)
by the default argument promotions,
which indicates that (double)
is the more natural of the two types.

"%f" is the fprintf format specifier for type (double).

--
pete

[Richard Heathfield]

Hahnemann said:

I read the following from a book called "Compression Algorithms for
Real Programmers":

"...Programmers have long known that it is silly to use double
precision values or long integers when regular floating point numbers
or integers will serve the purpose...

Programmers have long known lots of wrong things. Er... so what?

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999