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

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.

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.

I hope that we all learned something today. Or at least some of us did.
Ok, fine, I hope that one person learned something today.

On Wed, May 29, 2013 at 2:55 PM, Arthur Corliss
<acorliss@nevaeh-linux.org>wrote:

> On Wed, 29 May 2013, bryanm@acsalaska.net wrote:
>
> Okay, I re-read the first few messages in this thread (including my
>> own), and I see the source of confusion.
>>
>> My objective was never to suggest a compression algorithm. I was saying
>> that if a string of bits is converted *poorly* -- to a base that isn't
>> a good match (a power of two, specifically) -- then in the new sequence
>> of data elements, not all values would be equally likely, as was the case
>> in the original post (binary -> hex).
>>
>> Maybe that will clear things up, if you can make it through that last
>> sentence.
>>
>
> ... I guess I'm still trying to figure out the point of this exercise.
>
> I think what you're missing is that once you start from a binary
> perspective -- which you are once you start talking about processing bits --
> *every* base system based on number of bits *is* a power of two base. In
> fact, your hypothetical three bit system is essentially octal. The fact
> that octal can look like decimal (minus the ability to use the '8' & '9'
> symbols) doesn't change anything. At best, you're expanding the bit stream
> by inserting zero bits into the stream at precise intervals. In which
> case,
> your decompression routine is a bitwise ANDs and shifts.
>
> Now, if you want to talk about non-power of two bases, like base 3, which
> would require two bits to store one of three possible values, when you can
> actually store four possible values... well, now you're just talking about
> processing numbers in a non-native format for binary computers, but which
> has to do all math/logical functions in binary anyway, which means they're
> converting between base 3 and binary purely for presentational purposes...
> so why are we doing this again?
>
>
> --Arthur Corliss
> Live Free or Die
> ---------
> To unsubscribe, send email to <aklug-request@aklug.org>
> with 'unsubscribe' in the message body.
>
>

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Wed May 29 15:04:34 2013