[aklug] Re: [OT] Re: random bits vs random Hex

On Wed, 29 May 2013, Doug Davey wrote:

> The point is that we are discussing how compression works, how binary is
> displayed, and also bringing up some common mistakes when storing binary
> values. Namely storing it in a silly format. Typical data storage schemes
> for files will have unused space, and heavily repeated patterns, which make
> compression worthwhile. Random strings do not. If you make a mistake with
> storing your random number, and add a ton of space, you will see a
> compression algorithm work on it, and bring it back down in size to the
> actual data being represented.

I think people are likely to get themselves confused and tied up by what is
not a data issue, but a presentation issue. In order for this to have any
practical impact on the coder whatsoever said coder would have to go out of
their way to create this problem in storage, like taking a binary stream,
converting every octal value to string-encoded decimal, and storing *that*
all concatenated. I would be extremely surprised if anyone here, new coder
or not, would do something like that.

> And yes, James, sometimes you might get a random stream of bits that have
> some patterns in it that will be compressible, but that should be a warning
> sign that your stream might be less than random.

Anything truly random will be unpredictable in anticipation, but that does
not mean that a random stream is not compressable. Long enough streams
will almost certainly be, it is simply that the level of compression gained
will be low in comparison to, say, English text. Any given short sequence
of data can reoccur within a stream and as long as you can't predict in
advance *when* it will recoccur it will still be considered random.

In short, compression may be an indicator of randomness, but it is not a
guarantee. Just to clarify your point a bit.

         --Arthur Corliss
           Live Free or Die
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Wed May 29 15:51:27 2013