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

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.
Received on Wed May 29 14:55:41 2013