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

From: Arthur Corliss <acorliss@nevaeh-linux.org>
Date: Wed May 29 2013 - 13:43:47 AKDT

On Wed, 29 May 2013, bryanm@acsalaska.net wrote:

> That's not what I'm saying at all. I'm talking about unused pattern space.
> As an extreme example, imagine representing binary data by letting each
> *byte* represent either a 0 or a 1. Obviously, there would be tremendous
> opportunity for compression. The same thing happens (to a lesser degree)
> in my binary triplet -> decimal digit conversion. In each case, there
> are some possible values for each data element that will *never* be used.
>
> I'm speaking mathematically, and don't claim to know how to implement an
> algorithm to take advantage of this property.

Actually, that *is* what you're saying. You explicitly talked about taking
a binary stream and processing it chunks of three just to narrow your your
search space. I'm just taking your approach to an abusrd level, processing
chunks of one. But, let's say we meet in the middle and process chunks of
two. According to you that narrows your search space in decimal from 0 - 3,
should be better, no? But it's not.

Again, presentation doesn't matter. Decimal, octal, hexadecimal, even of
partial bytes, won't gain you any advantage. That's not how the math works.
If anything, you're just jumping through needless hoops for an ephemeral
advantage. And that means you might have a working compression algorithm,
but one's that no more effective than any other, but almost guaranteed to
perform worse.

> The idea of pattern recognition for the purpose of data compression
> intrigues me, though I've never fully researched the details.

It's a good thought experiment, agreed.

         --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 13:44:18 2013

This archive was generated by hypermail 2.1.8 : Wed May 29 2013 - 13:44:18 AKDT