Compression - Outline of compression theorem

Author

Outline of compression theorem

jacko

2007-08-28, 6:56 pm

can't reply to mangodrunk directly as a browser error makes reply link
not work on google groups.

but

if it was proved that you could expand a file n+77 bits by 2 bits
1/8th the time, compress it by 1 bit 7/16ths the time and have it
remain the same size 7/16ths the time then by consequence

2/8 < 7/16 the file should shrink to 77 bits.

after this time no further shrinkage would be possible as n=0

and buffers have no content out of bounds.

any flaw in this apparent hypothetical yet?

cheers

Willem

2007-08-28, 6:56 pm

jacko wrote:
) can't reply to mangodrunk directly as a browser error makes reply link
) not work on google groups.
)
) but
)
) if it was proved that you could expand a file n+77 bits by 2 bits
) 1/8th the time, compress it by 1 bit 7/16ths the time and have it
) remain the same size 7/16ths the time then by consequence

If you compress by 1 bit 7/16ths of the time, then you have mapped the
original code space for 7/8ths. This leaves room for less than 1/8 of
the files to remain the same, so more than 7/16th would have to be expanded.

SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

jacko

2007-08-29, 6:56 pm

So we have the bit patterns bellow and we make an indexing system to
make reffering to bit easy to type row-column style

0123
====
0000 0
0001 1
0010 2
0011 3
0100 4
0101 5
0110 6
0111 7
1000 8
1001 9
1010 a
1011 b
1100 c
1101 d
1110 e
1111 f

now if bits 00 to 70 all being zeros, could be removed 7/16ths of the
time depending on the critical 77 carrier bits.
and bits 80 to f0 all being ones, could be turned into zeros 7/16ths
of the time depending on the 77 carrier bits.
and 1/8th the time depending on the carrier bits, 1 (sorry about the 2
in my above post this should have been 1) extra bit is added which is
always a 1.

so 0000 -> 10000 1/8th the time.

so 7/8ths the time a leading 1 turns to a zero or a leading zero is
removed.

at this point i am not arguing with you about placing the removed bits
back into the added bits, but as can be seen, i am not removing the
bits, just to add them, i am only adding 1s and only removing 0s.

and the addition or removal process also logically depends on the 77
carrier bits.

cheers

jacko

2007-08-29, 6:56 pm

On Aug 29, 4:11 pm, jacko <jackokr...@gmail.com> wrote:
> So we have the bit patterns bellow and we make an indexing system to
> make reffering to bit easy to type row-column style
>
> 0123
> ====
> 0000 0
> 0001 1
> 0010 2
> 0011 3
> 0100 4
> 0101 5
> 0110 6
> 0111 7
> 1000 8
> 1001 9
> 1010 a
> 1011 b
> 1100 c
> 1101 d
> 1110 e
> 1111 f
>
> now if bits 00 to 70 all being zeros, could be removed 7/16ths of the
> time depending on the critical 77 carrier bits.
> and bits 80 to f0 all being ones, could be turned into zeros 7/16ths
> of the time depending on the 77 carrier bits.
> and 1/8th the time depending on the carrier bits, 1 (sorry about the 2
> in my above post this should have been 1) extra bit is added which is
> always a 1.
>
> so 0000 -> 10000 1/8th the time.

xxxx -> 1xxxx etc.
this is carrier dependant (critical bit) =1 and has no modulation
open.

> so 7/8ths the time a leading 1 turns to a zero or a leading zero is
> removed.

this is a bit decision which is held on the carrier by either
modulating the carrier (0 -> 1 of the critical bit) on leaving it 0.

> at this point i am not arguing with you about placing the removed bits
> back into the added bits, but as can be seen, i am not removing the
> bits, just to add them, i am only adding 1s and only removing 0s.

the 77 bits of the carrier form a reverable state machine with at
least one critical bit with =1 1/8th time and =0 7/8ths the time. and
this critical bit can be changed from 0->1 and still leave the state
machine in a valid state.

so your argument would be that such said critical bit could not have
an entropy of
around 1/8*log2(8)+7/8*log2(8/7) just because it can't

using reducto obserdum i could say i found a solution just because you
haven't.

'cos that would be an 'opposite.' and i couldn't prove 'you found a
sloution'

of course you would say my reducto obserdum was a complete fantasy,
and promptly miss your own fantastic attatchment to the reducto
obserdum 'proof' of the counting argument.

so please do explain why a critical bit could not have the said
entropy or lower entropy.

cheers
http://indi.hpsdr.com

jacko

2007-08-29, 6:56 pm

and on the compressing a file by one bit, an n bit file would go to a
(n-1)+77 bit file, itself not a violation of the counting argument.

the lucky thing is the same 77 bits will suffice for another
compression cycle.

so the output could be considered to be (n=0) + 77*cycles.

but due to the massive mutual information in the groups of 77 bits, it
suffices to just store the one set of 77.

cheers

Sponsored Links