http://qs321.pair.com?node_id=1233618


in reply to Data compression by 50% + : is it possible?

Impossible! If your data is truly random.

You need a gnat's under 6.5 bits to represent each of your values and are currently using 8 bits. If you could pack it exactly (meaning using 1/2 bits), then the best you could achieve is 6.5/8 = 18.75%.

If you try dictionary lookup:

  1. The dictionary for 2 byte pairings requires 13 bits; no saving over 16.
  2. 3 byte pairings require 19.5, no saving over 24.
  3. Best you could do is using a 40-bit number to represent each of the 531441000000 6-byte pairings; giving 40/48 16.67% saving.

Beyond that, your into the luck of the draw. Some random datasets might contain enough common (sub)sequences to allow Lempel–Ziv or similar to get close to 50%, but for other datasets, the same algorithm will produce barely any reduction, (or even an increase).

See Kolmogorov_complexity for more.


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit
  • Comment on Re: Data compression by 50% + : is it possible?

Replies are listed 'Best First'.
Re^2: Data compression by 50% + : is it possible?
by bliako (Monsignor) on May 12, 2019 at 00:06 UTC

    BrowserUK: but it's not truly random, it sets some rules: can not have consecutive numbers in a single line. Can one work this out analytically?

      It makes a small -- insignificant -- difference to the outcome.

      A quick check -- because quicker than trying to derive a formula -- shows that of the 729,000 3-value combinations, 11,839 contain consecutive numbers:

      use Algorithm::Combinatorics qw[ variations_with_repetition ];; @c = variations_with_repetition( [ 1 .. 90 ], 3 );; print scalar @c;; 729000 $d = 0; $_->[0]+1 == $_->[1] or $_->[1]+1 == $_->[2] and ++$d for @c; +print $d;; 7922

      And there are 8010 combinations of 2 sets of three that must be excluded because the last digit of the first set of 3 is one less that the first digit of the second set:

      $d = 0; $_->[0] == $_->[2]+1 and ++$d for @c; print $d;; 8010

      Which means that instead of 531,441,000,000 6-value combinations, there are only (729,000 - 7922 )**2 - 8010 = 519,953,474,074, which means it would still take 40-bits to represent any legal 6-value string; so the math doesn't change: ( 1 - 40/48 ) *100 = 16.67% is best possible for *any* dataset.

      Any algorithm that achieves better on any given dataset; will not achieve the same results for all datasets; nor even a high percentage of them.

      Ie. To achieve better, you'd need to reduce the size of the domain so that you could compress 36-bits into 48 which would give 25% compression. But that would require throwing away 87% of the possible datasets


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
      In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit

        BrowserUk:

        There are remarkably fewer combinations than it would appear at first glance. The OP creates a vector of four random digits (0..9), but then enforces a few rules:

        • The four digits are sorted: This reduces 10,000 input vectors to 715 possible outputs.
        • Then the code eliminates duplicate values and sequential values reducing the 715 inputs to 102 outputs.
        • Then the first value is removed from the list reducing the possible outputs to 50.

        As a result of those rules, none of the output groups will contain 0 or 1. So with the OPs script, you should never see the characters:

        $ perl -e 'print join(" ", map { chr(33+$_), chr(33+$_+1) } map {10*$_ +} 0 .. 8)' ! " + , 5 6 ? @ I J S T ] ^ g h q r

        That removes 18 of the 90 values, greatly reducing the number of possible records generated. Additionally, the remaining digits aren't equally distributed: 2 appears about half as often as 3 and about a third as often as 9.

        ...roboticus

        When your only tool is a hammer, all problems look like your thumb.

Re^2: Data compression by 50% + : is it possible?
by LanX (Saint) on May 12, 2019 at 02:56 UTC
      but you are wrong.

      Prove it!

      Take time out of your always 'too busy' schedule, and post some code. Working, code. Code that I can throw a few sample datasets at and see if you roboticus have really defeated a 30+ y/o CompSci theoretical fact.

      If you can post code that can compress *all* OP-compliant datasets, by more that 16.67%; I'll buy you him dinner.

      Better still -- and you'll like this idea -- I'll stop coming around here.

      So, PROVE IT!; or forever pursue your favorite pastime and "hold your piece".


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
      In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit
        Lol ... the "gnat" is certainly with you. :)

        edit

        Read my post, read the code, read the output.

        I need maximum 51 bits per line that's already a 58% win. (Even before applying Huffman)

        Realize that you misunderstood the question.

        > PROVE IT!

        Whenever I "prove " things, you just silently fuck off after shouting around.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

        update

        s/proof/prove/