Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compression > #2217 > unrolled thread

compressing files with a simple equation

Back to article view | Back to comp.compression

Contents

  compressing files with a simple equation Alemayehu Ewnetu <abelalem1981@gmail.com> - 2014-02-09 13:26 -0800
    Re: compressing files with a simple equation Robert Wessel <robertwessel2@yahoo.com> - 2014-02-09 16:18 -0600
      Re: compressing files with a simple equation Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-02-10 17:42 +0200

#2217 — compressing files with a simple equation

I have this new idea this idea is if you read files as a constant block of bits and the file contains smaller number than the bit block can contain then you can compress the file by applying a simple equation to it.
For example lets say you have 30 bits file.

001011110000001010111011111010

now if you read the file dividing it in 2 bits you will read only 3 different values.

The result of 4 to the power of 15 will take 30 bit.

The result of 3 to the power of 15 will take 25 bit.

If you add 4 bits for determining witch value exist then you can save 1 bit for the previous 30 bits file.

The equation is n(x - 1) + y

this equation will work by using an array

[toc] | [next] | [standalone]

#2218

On Sun, 9 Feb 2014 13:26:37 -0800 (PST), Alemayehu Ewnetu
<abelalem1981@gmail.com> wrote:

>I have this new idea this idea is if you read files as a constant block of bits and the file contains smaller number than the bit block can contain then you can compress the file by applying a simple equation to it.
>For example lets say you have 30 bits file.
>
>001011110000001010111011111010
>
>now if you read the file dividing it in 2 bits you will read only 3 different values.
>
>The result of 4 to the power of 15 will take 30 bit.
>
>The result of 3 to the power of 15 will take 25 bit.
>
>If you add 4 bits for determining witch value exist then you can save 1 bit for the previous 30 bits file.
>
>The equation is n(x - 1) + y
>
>this equation will work by using an array


The chances of a file have 15 pairs of bits only using three of the
possible values are only about 1.34%.

So 1.34% of the time you can encode the sequence as 29 bits, and
98.66% of the time you need 30 bits.  So far this still sounds like a
win - on average you'll only need 29.9866 bits to encode a 30 bit
string.  But you're missing something crucial - you need to be able to
encode *which* method you need to use to decode the compressed string
(the 29 or 30 bit output string), and you have to do that with no more
than .0134 bits per 30 bit input block to keep a net gain.  And that
you can't do - encoding that 98.66/1.34% distribution takes at least
.0195 bits per block, hence you've have negative compression to the
tune of about .0061 bits per 30 bit input block.

[toc] | [prev] | [next] | [standalone]

#2220

Robert Wessel <robertwessel2@yahoo.com> writes:
> On Sun, 9 Feb 2014 13:26:37 -0800 (PST), Alemayehu Ewnetu
> <abelalem1981@gmail.com> wrote:
> 
> >I have this new idea this idea is if you read files as a constant block of bits and the file contains smaller number than the bit block can contain then you can compress the file by applying a simple equation to it.
> >For example lets say you have 30 bits file.
> >
> >001011110000001010111011111010
> >
> >now if you read the file dividing it in 2 bits you will read only 3 different values.
> >
> >The result of 4 to the power of 15 will take 30 bit.
> >
> >The result of 3 to the power of 15 will take 25 bit.
> >
> >If you add 4 bits for determining witch value exist then you can save 1 bit for the previous 30 bits file.
> >
> >The equation is n(x - 1) + y
> >
> >this equation will work by using an array
> 
> The chances of a file have 15 pairs of bits only using three of the
> possible values are only about 1.34%.

"Compression by coincidence", I like to call that.
 
> So 1.34% of the time you can encode the sequence as 29 bits, and
> 98.66% of the time you need 30 bits.  So far this still sounds like a
> win - on average you'll only need 29.9866 bits to encode a 30 bit
> string.  But you're missing something crucial - you need to be able to
> encode *which* method you need to use to decode the compressed string
> (the 29 or 30 bit output string), and you have to do that with no more
> than .0134 bits per 30 bit input block to keep a net gain.  And that
> you can't do - encoding that 98.66/1.34% distribution takes at least
> .0195 bits per block, hence you've have negative compression to the
> tune of about .0061 bits per 30 bit input block.

Just pull out the big gun - Kraft.

However, the other way this concept is wrong is that it's not "new".
People have been using alphabets just sufficient to encode the data
that they have since the beginning of time. There's no novelty in it
at all.

Phil
-- 
What Alice Hill, President at Slashdot Media, writes:
 Proven track record innovating and improving iconic websites 
 (Slashdot.org, ...) while protecting their voice and brand integrity
What Alice Hill means: 
 2013: Completely fucked up Slashdot, and ignored almost endless
 negative feedback about her unwanted changes. 2014: Killed slashdot.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compression

csiph-web