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

Groups > comp.compression > #1201 > unrolled thread

Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles

Back to article view | Back to comp.compression

Contents

  Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles LawCounsels@aol.com - 2012-03-31 10:32 -0700
    Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles Thomas Richter <thor@math.tu-berlin.de> - 2012-04-03 11:32 +0200
      Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles James Dow Allen <jdallen2000@yahoo.com> - 2012-04-03 09:07 -0700
        Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles LawCounsels@aol.com - 2012-04-06 01:24 -0700
          Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles LawCounsels@aol.com - 2012-04-08 00:41 -0700
            Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles James Dow Allen <jdallen2000@yahoo.com> - 2012-04-08 04:25 -0700
              Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles lawcounsels@gmail.com - 2012-04-08 22:58 -0700
                Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles James Dow Allen <jdallen2000@yahoo.com> - 2012-04-09 04:19 -0700
                  Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles biject <biject.bwts@gmail.com> - 2012-04-09 09:03 -0700
                    Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles LawCounsels@aol.com - 2012-04-10 02:29 -0700
                      Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles James Dow Allen <jdallen2000@yahoo.com> - 2012-04-10 05:43 -0700
                        Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles lawcounsels@gmail.com - 2012-04-10 06:39 -0700
                          Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles lawcounsels@gmail.com - 2012-04-10 06:51 -0700
                            Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles lawcounsels@gmail.com - 2012-04-10 07:29 -0700
                              I knew I was going to dislike New Google Groups! James Dow Allen <jdallen2000@yahoo.com> - 2012-04-10 09:03 -0700
                                Re: I knew I was going to dislike New Google Groups! LawCounsels <lawcounsels@gmail.com> - 2012-04-10 09:56 -0700
                                  Re: I knew I was going to dislike New Google Groups! James Dow Allen <jdallen2000@yahoo.com> - 2012-04-10 10:34 -0700
                                    Re: I knew I was going to dislike New Google Groups! lawcounsels@gmail.com - 2012-04-10 10:54 -0700
                                      Re: I knew I was going to dislike New Google Groups! James Dow Allen <jdallen2000@yahoo.com> - 2012-04-11 13:16 -0700
                                        Re: I knew I was going to dislike New Google Groups! LawCounsels <lawcounsels@gmail.com> - 2012-04-12 03:10 -0700
                                          Re: I knew I was going to dislike New Google Groups! LawCounsels <lawcounsels@gmail.com> - 2012-04-12 03:57 -0700
                                            Re: I knew I was going to dislike New Google Groups! biject <biject.bwts@gmail.com> - 2012-04-12 08:38 -0700
                                              Re: I knew I was going to dislike New Google Groups! LawCounsels <lawcounsels@gmail.com> - 2012-04-13 02:34 -0700
                                  Re: I knew I was going to dislike New Google Groups! Fibonacci Code <anglikai@gmail.com> - 2012-04-30 07:36 -0700
                                    Re: I knew I was going to dislike New Google Groups! lawcounsels@gmail.com - 2012-04-30 08:34 -0700
                                      Re: I knew I was going to dislike New Google Groups! Thomas Richter <thor@math.tu-berlin.de> - 2012-04-30 18:53 +0200
                                      Re: I knew I was going to dislike New Google Groups! Fibonacci Code <anglikai@gmail.com> - 2012-04-30 09:58 -0700
                                        Re: I knew I was going to dislike New Google Groups! lawcounsels@gmail.com - 2012-04-30 10:18 -0700
                      Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles LawCounsels@aol.com - 2012-04-10 05:58 -0700
                      Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles biject <biject.bwts@gmail.com> - 2012-04-10 07:26 -0700
                        Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles LawCounsels <lawcounsels@gmail.com> - 2012-04-10 08:10 -0700
                          Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles biject <biject.bwts@gmail.com> - 2012-04-10 11:02 -0700
                            Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles LawCounsels <lawcounsels@gmail.com> - 2012-04-11 02:43 -0700
                      Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles Thomas Richter <thor@math.tu-berlin.de> - 2012-04-11 02:47 +0200
                        Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles LawCounsels <lawcounsels@gmail.com> - 2012-04-11 02:56 -0700
                          Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles Thomas Richter <thor@math.tu-berlin.de> - 2012-04-11 16:26 +0200
                            Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles James Dow Allen <jdallen2000@yahoo.com> - 2012-04-11 07:36 -0700
                              Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles LawCounsels@aol.com - 2012-04-11 10:29 -0700
                              Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles Thomas Richter <thor@math.tu-berlin.de> - 2012-04-12 02:27 +0200
                                Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles LawCounsels <lawcounsels@gmail.com> - 2012-04-12 03:08 -0700
                                  Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles LawCounsels <lawcounsels@gmail.com> - 2012-04-12 03:34 -0700
                                    Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles Thomas Richter <thor@math.tu-berlin.de> - 2012-04-13 13:48 +0200
                                      Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles James Dow Allen <jdallen2000@yahoo.com> - 2012-04-13 05:15 -0700
                                        Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles lawcounsels@gmail.com - 2012-04-13 06:57 -0700
                                          Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles lawcounsels@gmail.com - 2012-04-13 07:03 -0700
                                      Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles lawcounsels@gmail.com - 2012-04-13 06:52 -0700
                                        Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles Thomas Richter <thor@math.tu-berlin.de> - 2012-04-14 00:54 +0200
                                          Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles LawCounsels <lawcounsels@gmail.com> - 2012-04-16 02:48 -0700
                                            Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles Thomas Richter <thor@math.tu-berlin.de> - 2012-04-16 13:08 +0200
                                              Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles lawcounsels@gmail.com - 2012-04-16 04:40 -0700
                                              Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles James Dow Allen <jdallen2000@yahoo.com> - 2012-04-16 08:11 -0700
                                                Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles Thomas Richter <thor@math.tu-berlin.de> - 2012-04-16 19:31 +0200
                                                  Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles James Dow Allen <jdallen2000@yahoo.com> - 2012-04-16 14:27 -0700
                                                    Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles LawCounsels <lawcounsels@gmail.com> - 2012-04-24 03:46 -0700
                                                      Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles Jim Leonard <mobygamer@gmail.com> - 2012-04-24 07:27 -0700
                                                      Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles Fibonacci Code <anglikai@gmail.com> - 2012-04-28 09:55 -0700
                      Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles LawCounsels <lawcounsels@gmail.com> - 2012-04-16 02:34 -0700
      Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles LawCounsels@aol.com - 2012-04-04 00:35 -0700
        Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles LawCounsels@aol.com - 2012-04-04 00:38 -0700
          Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles LawCounsels@aol.com - 2012-04-04 04:06 -0700
    Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles Ernst <Ernst_Berg@sbcglobal.net> - 2012-04-06 19:48 -0700
    Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles LawCounsels@aol.com - 2012-04-07 02:28 -0700
      Re: Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles lawcounsels@gmail.com - 2012-04-07 03:22 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#1201 — Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles

Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles now comes to this :

http://groups.google.com/group/comp.compression/browse_thread/thread/c3b4127eab5f7a0e?hl=en# 

can each of these many 'start'/ 'end' sequences  ( each consists of ternary
symbols a b c only condition here is total# of c ALWAYS exact = total# b + 2  &
this occurs only at EOSequence , ie at any stage IF progressive total#
c becomes = progressive # b  + 2    then a sequence ends ....  total# a  unrestricted , but usually around same as total# b BUT this is irrelevant ) be better represented encoded 'shorter'.... take care the encoded bitstring MUST be self-delimiting meaning unambiguous as to where the encoded bitsstring ends ( subsequent follows / merged with other bits , needs able distinguish this boundary from the encoded bitstring itself )  

The entropy of all these many 'start'/'end' sequences together with
total N symbols ( total # a + total # b + total # c = N , which is N * 1.5 binary bits )  already OBVIOUS smaller than N * 1.5 binary bits

REWARDS for 1st person put forth a practical solution , and REWARDS also for the best practical solution put forth 

Look Forward , 
LawCounsels

[toc] | [next] | [standalone]

#1202

Am 31.03.2012 19:32, schrieb LawCounsels@aol.com:
>
> Mankind's centuries old Kraft's Inequality / Pigeonholes hurdles now comes to this :
>
> http://groups.google.com/group/comp.compression/browse_thread/thread/c3b4127eab5f7a0e?hl=en#
>
> can each of these many 'start'/ 'end' sequences  ( each consists of ternary
> symbols a b c only condition here is total# of c ALWAYS exact = total# b + 2&
> this occurs only at EOSequence , ie at any stage IF progressive total#
> c becomes = progressive # b  + 2    then a sequence ends ....  total# a  unrestricted , but usually around same as total# b BUT this is irrelevant ) be better represented encoded 'shorter'.... take care the encoded bitstring MUST be self-delimiting meaning unambiguous as to where the encoded bitsstring ends ( subsequent follows / merged with other bits , needs able distinguish this boundary from the encoded bitstring itself )
>
> The entropy of all these many 'start'/'end' sequences together with
> total N symbols ( total # a + total # b + total # c = N , which is N * 1.5 binary bits )  already OBVIOUS smaller than N * 1.5 binary bits
>
> REWARDS for 1st person put forth a practical solution , and REWARDS also for the best practical solution put forth

As undefined as it can be. First of all, you say "the sequence ends if 
#c = #b +2", but you do not say whether the number of c's before that 
point is smaller or larger than the number of b's, that is, whether the 
sequence ends if the number of c's drops to #b+2, or rises to #b+2. 
Then, you say nothing about the statistics of the sequence. For all 
practical matters, pick a MQ coder, and encode the symbols by binary 
decisions like 0->a, 10->b, 11-> c.

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

#1203

On Apr 3, 4:32 pm, Thomas Richter <t...@math.tu-berlin.de> wrote:
> Am 31.03.2012 19:32, schrieb LawCouns...@aol.com:
> > REWARDS for 1st person put forth a practical solution , and REWARDS also for the best practical solution put forth
>
> As undefined as it can be. First of all, you say "the sequence ends if
> #c = #b +2", but you do not say whether the number of c's before that
> point is smaller or larger than the number of b's,...

I hardly noticed OP before you responded (especially given
the April 1 date!) but I think I can answer this.
#c = #b = 0 initially, so #c can never exceed #b + 1 before
termination (If #c > #b + 2, the sequence would have
terminated earlier.)

I'll read OP if/when "REWARDS" is clarified.  Are we talking
brownie points?  Fame and Glory?  Billions of Zimbabwe dollars?

April Fools!!

James

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

#1207

On Tuesday, April 3, 2012 5:07:04 PM UTC+1, James Dow Allen wrote:
> On Apr 3, 4:32 pm, Thomas Richter <t...@math.tu-berlin.de> wrote:
> > Am 31.03.2012 19:32, schrieb LawCouns...@aol.com:
> > > REWARDS for 1st person put forth a practical solution , and REWARDS also for the best practical solution put forth
> >
> > As undefined as it can be. First of all, you say "the sequence ends if
> > #c = #b +2", but you do not say whether the number of c's before that
> > point is smaller or larger than the number of b's,...
> 
> I hardly noticed OP before you responded (especially given
> the April 1 date!) but I think I can answer this.
> #c = #b = 0 initially, so #c can never exceed #b + 1 before
> termination (If #c > #b + 2, the sequence would have
> terminated earlier.)
> 
> I'll read OP if/when "REWARDS" is clarified.  Are we talking
> brownie points?  Fame and Glory?  Billions of Zimbabwe dollars?
> 
> April Fools!!
> 
> James

there will be many happy just to be part of contribute to this history 'breakthrough' [ if indeed it turns out ] !

however I am not averse to confirm REWARDS :

. your choice whether to accept one-time immediate US$1,000 payment on delivery of the software ( prefers C# ) 

OR

. accept a retainer ( standard type agreement will be made available for yourself to decide ) whereby 'minimum' entitled to revenues share of US$3Million in return for 'part' time competent manner R&D development  , over 3 years period 


you may also opt to communicate your solutions by private email 1st  

Cheers,
LawCounsels  

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

#1212

On Friday, April 6, 2012 9:24:03 AM UTC+1, LawCo...@aol.com wrote:
 
> there will be many happy just to be part of contribute to this history 'breakthrough' [ if indeed it turns out ] !
> 
> however I am not averse to confirm REWARDS :
> 
> . your choice whether to accept one-time immediate US$1,000 payment on delivery of the software ( prefers C# ) 
> 
> OR
> 
> . accept a retainer ( standard type agreement will be made available for yourself to decide ) whereby 'minimum' entitled to revenues share of US$3Million in return for 'part' time competent manner R&D development  , over 3 years period 
> 
> 
> you may also opt to communicate your solutions by private email 1st  
> 


NOTE : to win the REWARDS your solution needs attain 8 bits Net compression savings or more if taking compresses 100 such sequences , attain 80 bits Net compression savings or more if taking compresses 1,000 such sequences , attain 800 bits Net compression savings or more if taking compresses 10,000 such sequences ... so forth 

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

#1213

On Apr 8, 2:41 pm, LawCouns...@aol.com wrote:
> NOTE : to win the REWARDS your solution needs attain 8 bits Net compression savings or more

I enjoy compression puzzles and might investigate this one except ...

Skimming your posts I find I have no idea whatsoever
what problem you're posing, nor how the compression savings would
be measured.  You do mention some ternary system with a
token termination condition, but any (terminated) sequence
of trits would be valid, just with different token boundaries.

At one point you imply a trit is 1.5 bits.
Wrong, it's 1.5849625 bits.  Don't know if this
makes your puzzle easier or harder.

Before you waste time trying to tell us what your
actual requirement is, be aware that, if I solve it,
I will not divulge my solution until the REWARD is in escrow.

James

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

#1217

On Sunday, April 8, 2012 11:25:47 AM UTC, James Dow Allen wrote:
> On Apr 8, 2:41 pm, LawCouns...@aol.com wrote:
> > NOTE : to win the REWARDS your solution needs attain 8 bits Net compression savings or more
> 
> I enjoy compression puzzles and might investigate this one except ...
> 
> Skimming your posts I find I have no idea whatsoever
> what problem you're posing, nor how the compression savings would
> be measured.  You do mention some ternary system with a
> token termination condition, but any (terminated) sequence
> of trits would be valid, just with different token boundaries.
> 
> At one point you imply a trit is 1.5 bits.
> Wrong, it's 1.5849625 bits.  Don't know if this
> makes your puzzle easier or harder.
> 
> Before you waste time trying to tell us what your
> actual requirement is, be aware that, if I solve it,
> I will not divulge my solution until the REWARD is in escrow.
> 
> James

you choose eg 1,000 such subsequence ( each such subsequence terminates when # of c = # of b + 2 ) .... yes , each such sequence can be of various lengths as you mentioned ( # of symbols within ) BUT you know the distributions of the sequence lengths eg you can ALWAYS generate any # of such sequences ( for testing your compressions algorithm ) from a source with probability of producing an 'a' symbol 25% of time  a 'b' symbol 25% of times a 'c' symbol 50% of times 

Yes , a trit is 1.5849625 bits ( as when uses Arithmetic coder )  ... but I was
thinking perhaps using combinatorial C(100 , 50, 25, 25 ) this comes to average near 1.5 bits each trit ?( ignoring recording the multiplicities costs )

you should provide .exe takes in any generated # of such sequences , encode smaller then decode back to same # of such sequences [ NEEDS ONLY SHOW ON AVERAGE ATTAINS THIS , so wont be 'faulted' on very rare extreme input sequences generated  ]  

YES , REWARDS WILL BE IN ESCROW on request provided an time-expired .exe 1st clear shows saves 0.08 bits per sequence encoded


LawCounsels

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

#1218

On Apr 9, 12:58 pm, lawcouns...@gmail.com wrote:
> a source with probability of producing an 'a' symbol 25% of time
> a 'b' symbol 25% of times a 'c' symbol 50% of times

Allow me to recommend the optimal Huffman code:
   c - 0
   a - 10
   b - 11
This can be improved, though only slightly, using details
you've omitted from your summary.

This was so trivial, I'll discount it down to, say $950.

If this is unsatisfactory, I'll withdraw from the contest.
Even paid at minimum wage I'm afraid it would take significant
funds (payable in advance, please!) just to elicit a
proper problem statement from you.

I don't have PayPal.  Contact me for instructions on how
to pay the $950.  :-)

James

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

#1219

On Apr 9, 5:19 am, James Dow Allen <jdallen2...@yahoo.com> wrote:
> On Apr 9, 12:58 pm, lawcouns...@gmail.com wrote:
>
> > a source with probability of producing an 'a' symbol 25% of time
> > a 'b' symbol 25% of times a 'c' symbol 50% of times
>
> Allow me to recommend the optimal Huffman code:
>    c - 0
>    a - 10
>    b - 11
> This can be improved, though only slightly, using details
> you've omitted from your summary.
>
> This was so trivial, I'll discount it down to, say $950.
>
> If this is unsatisfactory, I'll withdraw from the contest.
> Even paid at minimum wage I'm afraid it would take significant
> funds (payable in advance, please!) just to elicit a
> proper problem statement from you.
>
> I don't have PayPal.  Contact me for instructions on how
> to pay the $950.  :-)
>
> James

  Lets see c is .5 * 1 = .5  b = .25*2 = .5  c = .25*2 = .5
see thats .5 + .5 + .5 = 1.5  for the average sequence  while
if you encode each with 1.5849625  you save about .0849625 which
is more than the .08  It appears your in the money. I have a
hunch that there still is something missing in which case I would
not count on the money yet.

 First of all does he want at least .08 bits saved in every case
or just the average case.  If its the average case you could be
on the right track.  If its every case then since you write only
whole numbers of bits the .08 savings gets a little harder. It
would be nice if the guy decides you haven't won just what does
he want. I have read it several times and yet I do not think its
clear enough to tackle without him saying oh I meant this and not
that.

Assuming he doesn't declare you the winner
1) is the savings an average things or does each file have to be less.
2) how do you measure the savings is it .08 from a 1.5849625 per
symbol
or is it .08 less then 1.5
3) not sure why you say source C = .5 while A and B = .25  the
fact is even if the source is A = B = C = 1/3  for short files
if you run the sources enough times and created a 100 files each
you still could get the same set of 100 files for both cases.
So you test set up is not valid. There is nothing magical about
your source.  Except if I know its a fixed IID souce from say 2 or
3 different models as you create more files. You can with increasing
probability determine which one it most likely is. But you can't be
100% certain which one it is unless you do an ever increasing number
of file.


 David A. Scott
--
 My Crypto code
http://bijective.dogma.net/crypto/scott19u.zip
http://www.jim.com/jamesd/Kong/scott19u.zip old version
My Compression code http://bijective.dogma.net/
**TO EMAIL ME drop the roman "five" **
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.
As a famous person once said "any cryptograhic
system is only as strong as its weakest link"

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

#1220

On Monday, 9 April 2012 17:03:04 UTC+1, biject  wrote:
> On Apr 9, 5:19 am, James Dow Allen <jdallen2...@yahoo.com> wrote:
> > On Apr 9, 12:58 pm, lawcouns...@gmail.com wrote:
> >
> > > a source with probability of producing an 'a' symbol 25% of time
> > > a 'b' symbol 25% of times a 'c' symbol 50% of times
> >
> > Allow me to recommend the optimal Huffman code:
> >    c - 0
> >    a - 10
> >    b - 11
> > This can be improved, though only slightly, using details
> > you've omitted from your summary.
> >
> > This was so trivial, I'll discount it down to, say $950.
> >
> > If this is unsatisfactory, I'll withdraw from the contest.
> > Even paid at minimum wage I'm afraid it would take significant
> > funds (payable in advance, please!) just to elicit a
> > proper problem statement from you.
> >
> > I don't have PayPal.  Contact me for instructions on how
> > to pay the $950.  :-)
> >
> > James
> 
>   Lets see c is .5 * 1 = .5  b = .25*2 = .5  c = .25*2 = .5
> see thats .5 + .5 + .5 = 1.5  for the average sequence  while
> if you encode each with 1.5849625  you save about .0849625 which
> is more than the .08  It appears your in the money. I have a
> hunch that there still is something missing in which case I would
> not count on the money yet.
> 
>  First of all does he want at least .08 bits saved in every case
> or just the average case.  If its the average case you could be
> on the right track.  If its every case then since you write only
> whole numbers of bits the .08 savings gets a little harder. It
> would be nice if the guy decides you haven't won just what does
> he want. I have read it several times and yet I do not think its
> clear enough to tackle without him saying oh I meant this and not
> that.
> 
> Assuming he doesn't declare you the winner
> 1) is the savings an average things or does each file have to be less.
> 2) how do you measure the savings is it .08 from a 1.5849625 per
> symbol
> or is it .08 less then 1.5
> 3) not sure why you say source C = .5 while A and B = .25  the
> fact is even if the source is A = B = C = 1/3  for short files
> if you run the sources enough times and created a 100 files each
> you still could get the same set of 100 files for both cases.
> So you test set up is not valid. There is nothing magical about
> your source.  Except if I know its a fixed IID souce from say 2 or
> 3 different models as you create more files. You can with increasing
> probability determine which one it most likely is. But you can't be
> 100% certain which one it is unless you do an ever increasing number
> of file.
> 
> 
>  David A. Scott
> --
>  My Crypto code
> http://bijective.dogma.net/crypto/scott19u.zip
> http://www.jim.com/jamesd/Kong/scott19u.zip old version
> My Compression code http://bijective.dogma.net/
> **TO EMAIL ME drop the roman "five" **
> 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.
> As a famous person once said "any cryptograhic
> system is only as strong as its weakest link"


THE COMPLETE SPECIFICATIONS :
=============================

1. generates a number eg 1,000 of such sequences ( each sequence composed of ternary symbols 'a' 'b' 'c' , when # of 'c' = # of 'b' + 2 Then sequence ENDS  & next sequences begins ) using a source producing symbol 'a' 25% of times symbol 'b' 25% of times symbol 'c' 50% of times ) .... call the total # of symbols in these 1,000 sequences N . NOTE : among these eg 1,000 sequences the # of 'a' is invariable near = the # of 'b'  & the # of 'c' is invariable near = 2 * the # of 'b'  THUS the probability model here is 25% : 25% : 50% 

2. compresses these eg 1,000 generated sequences using your .exe , & must decode back to the same 1,000 sequences 

3. IF you compressed file bitslength  =<  1.5 * N   - ( 0.08 * N )  THEN YOU WIN THE REWARDS !   ie if your .exe saves 'on average' 0.08 bit each sequences you WON ( needs not be invariable every time on every conceivable file ! ) , but note the original # of sequences is here taken to be of bitslength N * 1.5 bits long   ( as originally 'explicit' stated to be 1.5 * N bits long , NOT 1.5849625 * N bits long )

4. there is no restrictions on memory storage requirements , you may even show your .exe works on 'research network supercomputer cluster' , BUT processing must complete within a day

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

#1221

On Apr 10, 4:29 pm, LawCouns...@aol.com wrote:
> THE COMPLETE SPECIFICATIONS :
> =============================
>
> 1. generates a number eg 1,000 of such sequences ( each sequence composed of ternary symbols 'a' 'b' 'c' , when # of 'c' = # of 'b' + 2 Then sequence ENDS  & next sequences begins ) using a source producing symbol 'a' 25% of times symbol 'b' 25% of times symbol 'c' 50% of times ) .... call the total # of symbols in these 1,000 sequences N . NOTE : among these eg 1,000 sequences the # of 'a' is invariable near = the # of 'b'  & the # of 'c' is invariable near = 2 * the # of 'b'  THUS the probability model here is 25% : 25% : 50%

I'm not clear on what "invariable near =" means.  I think you specify
that the trit is from a random memoryless source.  (Anyway, a
different
intepretation would have smallish effect.)

> 2. compresses these eg 1,000 generated sequences using your .exe , & must decode back to the same 1,000 sequences

Does the decompressor know, in advance, the exact number of bits in
the
sequence?  (Even if it does, the compression savings will be tiny,
when
amortized over 1000 strings.)

> 3. IF you compressed file bitslength  =<  1.5 * N   - ( 0.08 * N )  THEN YOU WIN THE REWARDS !

Starting with a source of exactly 1.500 bits/token of info,
we wait for the 1000th terminal, then compress it to
1.420 bits/token.  Right?  Good luck!  :-)

I'll leave my bet on Shannon, Kraft, and the pigeons.

James Dow Allen

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

#1223

On Tuesday, April 10, 2012 1:43:45 PM UTC+1, James Dow Allen wrote:
> On Apr 10, 4:29 pm, LawCouns...@aol.com wrote:
> > THE COMPLETE SPECIFICATIONS :
> > =============================
> >
> > 1. generates a number eg 1,000 of such sequences ( each sequence composed of ternary symbols 'a' 'b' 'c' , when # of 'c' = # of 'b' + 2 Then sequence ENDS  & next sequences begins ) using a source producing symbol 'a' 25% of times symbol 'b' 25% of times symbol 'c' 50% of times ) .... call the total # of symbols in these 1,000 sequences N . NOTE : among these eg 1,000 sequences the # of 'a' is invariable near = the # of 'b'  & the # of 'c' is invariable near = 2 * the # of 'b'  THUS the probability model here is 25% : 25% : 50%
> 
> I'm not clear on what "invariable near =" means.  I think you specify
> that the trit is from a random memoryless source.  (Anyway, a
> different
> intepretation would have smallish effect.)

If source produces symbol 'a' 25% of times symbol 'b' 25% of times symbol 'c' 50% of times THEN after eg 1,000 symbols sequences generated ( total N # of symbols within these 1,000 sequences ) THEN  can with very high confidence level says the # of 'a' will be around N/4   the # of 'b' will be around N/4   the # of 'c' will be around N/2 

> 
> > 2. compresses these eg 1,000 generated sequences using your .exe , & must decode back to the same 1,000 sequences
> 
> Does the decompressor know, in advance, the exact number of bits in
> the
> sequence?  (Even if it does, the compression savings will be tiny,
> when
> amortized over 1000 strings.)

you can ALWAYS choose ONLY a particular fixed # of sequences eg 1,000 or 10,000 etc to compress , so decompressor knows in advance the EXACT # of sequences compressed ..... but may ONLY guess at the total # of bits quite accurate ( since this is not known in advance )  
> 
> > 3. IF you compressed file bitslength  =<  1.5 * N   - ( 0.08 * N )  THEN YOU WIN THE REWARDS !
> 
> Starting with a source of exactly 1.500 bits/token of info,
> we wait for the 1000th terminal, then compress it to
> 1.420 bits/token.  Right?  Good luck!  :-)
> 
> I'll leave my bet on Shannon, Kraft, and the pigeons.

SO WOULD I should these 1,000 sequences being 'random' structureless .... here the structure is within each sequence the # of 'c' is EXACT = the # of 'b' + 2

IN FACT ... all sequence MUST END with a 'c'  , immediate before this 'c'  ONLY an 'a' OR a 'c'  can occur [ NEVER  a 'b' ! ] .... if you look more careful, there are many more restrictions on possible permutations 'ordered'arrangements between the # of 'a's & 'b' & 'c' within a sequence , eg if there are 6 symbols in a sequence 1st 2 symbols cant be both 'a's    &  last 3 symbols cant be ALL 'b's  .... etc so forth .... IT IS THESE THAT MAY MAKE YOUR SOUGHT FOR 1.420bits/token p[ossible achievable ( ? )  


 
> 
> James Dow Allen

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

#1224

> > Starting with a source of exactly 1.500 bits/token of info,
> > we wait for the 1000th terminal, then compress it to
> > 1.420 bits/token.  Right?  Good luck!  :-)
> > 
> > I'll leave my bet on Shannon, Kraft, and the pigeons.


SO WOULD I should these 1,000 sequences being 'random' structureless .... here the structure is within each sequence the # of 'c' is EXACT = the # of 'b' + 2
 
IN FACT ... all sequence MUST END with a 'c'  , immediate before this 'c' IF # of symbols within this sequence is > 2 THEN ONLY an 'a' OR a 'c'  can occur [ NEVER  a 'b' ! ] .... if you look more careful, there are many more restrictions on possible permutations 'ordered'arrangements between the # of 'a's & 'b' & 'c' within a sequence , eg if there are 6 symbols in a sequence 1st 2 symbols cant be both 'a's    &  last 3 symbols cant be ALL 'b's  .... etc so forth .... IT IS THESE THAT MAY MAKE YOUR SOUGHT FOR 1.420bits/token possible achievable ( ? )  

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

#1225

Originally Posted by JamesB  
This makes no sense!

If the data is truely randomly generated with p(A)=.25, p(B)=.25 and p(C)=.5 then on average the entropy will be 1.5 bits per symbol. It's been proven that you cannot go lower than this. (And a simple huffman tree of C=0, A=10, B=11 will work fine.) So you're just wasting time.

If the data is NOT randomly generated, then it needs to be explained better. Are you saying that no randomly generated string of symbols can ever have more than 2 more c than b symbols (yet we still have p(C) = 2*p(B))? However you just slice the string of symbols at that point and keep going? If so it is completely identical to the initial random case, but split into segments. That cannot possibly improve your compression as on average it's the exact same data.

The only practical way I see is to find a weakness or prediction of the random number generator, but then it's not truely random - only psuedo random - and it's all a fake and irrelevant.

[ ABOVE is from   http://encode.ru/threads/1520-US-3-Million-Data-compression-Prize?p=29054#post29054 ] 

PROFOUND ! Thanks 

I would refer you to Entropy Definition : Request for Comments 

https://groups.google.com/forum/#!to...on/w7QSfqtfeg4 


These sequences have already been encoded compression saves minimum Net 0.063 bits per sequence !!!

1st to reach 0.08 bits Net compression savings per sequence WINS US$3M+ 

LawCounsels

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

#1228 — I knew I was going to dislike New Google Groups!

Does it seem strange that I knew I was going to dislike
New Google Groups? (though I didn't know *what* I'd dislike
about it.)  Almost every change made in some systems seems
for the worse not better.

In the example below, I click on lawcounsel's link only
to get some "overview" page with no content.

(Old Google Groups is amusing too, of course.  I'm now
looking at a window with no less than five scroll-bars,
3 of which I had to manipulate just to get this far!)

On Apr 10, 9:29 pm, lawcouns...@gmail.com wrote:
> I would refer you to Entropy Definition : Request for Comments
> https://groups.google.com/forum/#!to...on/w7QSfqtfeg4
> These sequences have already been encoded compression saves minimum Net 0.063 bits per sequence !!!
> 1st to reach 0.08 bits Net compression savings per sequence WINS US$3M+

Three comments:
1.  Your earlier post had
   <= 1.5 * N   - ( 0.08 * N )
Are we now to understand that the first N here is number of trits,
and the second number of sequences?
2.  I didn't read about the "saves minimum Net 0.063 bits per
sequence."
(As I said the link doesn't work.)  By "minimum" do you mean
"actual in one experiment"?  I'm guessing fluke.
3.  It may seem paradoxical that no compression savings are available
despite the c=b+2 constraint.  But consider a simpler related problem:
   Flip a coin and stop on the first Heads.  Compress the result.
H occurs with prob. 1/2
TH occurs with prob 1/4
TTH with prob 1/8, etc.
No way to compress despite the constraint.

James

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

#1229 — Re: I knew I was going to dislike New Google Groups!

On Apr 10, 5:03 pm, James Dow Allen <jdallen2...@yahoo.com> wrote:
> Does it seem strange that I knew I was going to dislike
> New Google Groups? (though I didn't know *what* I'd dislike
> about it.)  Almost every change made in some systems seems
> for the worse not better.
>
> In the example below, I click on lawcounsel's link only
> to get some "overview" page with no content.
>
> (Old Google Groups is amusing too, of course.  I'm now
> looking at a window with no less than five scroll-bars,
> 3 of which I had to manipulate just to get this far!)
>
> On Apr 10, 9:29 pm, lawcouns...@gmail.com wrote:
>
> > I would refer you to Entropy Definition : Request for Comments
> >https://groups.google.com/forum/#!to...on/w7QSfqtfeg4
> > These sequences have already been encoded compression saves minimum Net 0.063 bits per sequence !!!
> > 1st to reach 0.08 bits Net compression savings per sequence WINS US$3M+
>
> Three comments:
> 1.  Your earlier post had
>    <= 1.5 * N   - ( 0.08 * N )
> Are we now to understand that the first N here is number of trits,
> and the second number of sequences?

YES ... corrected since to read  <= 1.5 * N   - ( 0.08 * # OF
SEQUENCES )


> 2.  I didn't read about the "saves minimum Net 0.063 bits per
> sequence."
> (As I said the link doesn't work.)  By "minimum" do you mean
> "actual in one experiment"?  I'm guessing fluke.

FOR "ANY" ONE SUCH SEQUENCE [ mathematics 'guaranteed' minimum 0.063
bits savings ]

 .... ALSO VERIFIED OVER LARGE # OF SUCH SEQUENCES

> 3.  It may seem paradoxical that no compression savings are available
> despite the c=b+2 constraint.  But consider a simpler related problem:
>    Flip a coin and stop on the first Heads.  Compress the result.
> H occurs with prob. 1/2
> TH occurs with prob 1/4
> TTH with prob 1/8, etc.
> No way to compress despite the constraint.

perhaps particular constraint here is superficial ... reducible
'fundamental' equivalent to common 'fair coin' tosses type here

> James

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

#1230 — Re: I knew I was going to dislike New Google Groups!

On Apr 10, 11:56 pm, LawCounsels <lawcouns...@gmail.com> wrote:
> FOR "ANY" ONE SUCH SEQUENCE [ mathematics 'guaranteed' minimum 0.063
> bits savings ]

Congratulations!  It sounds like you've disproved
the Kraft's Inequality.  Have you published or is
it secret?  And why the REWARD ($3 million or $1000?)
to extend the 0.063 win to 0.080?
Once you have a perpetual compressor, can't you just
run several copies in series to get as much compression
as you want?

James

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

#1231 — Re: I knew I was going to dislike New Google Groups!

On Tuesday, April 10, 2012 6:34:11 PM UTC+1, James Dow Allen wrote:
> On Apr 10, 11:56 pm, LawCounsels <lawcouns...@gmail.com> wrote:
> > FOR "ANY" ONE SUCH SEQUENCE [ mathematics 'guaranteed' minimum 0.063
> > bits savings ]
> 
> Congratulations!  It sounds like you've disproved
> the Kraft's Inequality.  Have you published or is
> it secret?  And why the REWARD ($3 million or $1000?)
> to extend the 0.063 win to 0.080?
> Once you have a perpetual compressor, can't you just
> run several copies in series to get as much compression
> as you want?
> 
> James

because the 'smaller' compressed 1,000 such sequences is NOT in 
same such sequences format again any more .....

TO BE REPEATABLE needs 1st improve bits saving to average 0.08 bits per sequence
.... possible improvements schemes a plenty , promising !  

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

#1239 — Re: I knew I was going to dislike New Google Groups!

On Apr 11, 12:54 am, lawcouns...@gmail.com wrote:

> because the 'smaller' compressed 1,000 such sequences is NOT in
> same such sequences format again any more .....

It is straightforward to convert a uniform random string of
bits into a string of your (a,b,c) format with the expected
entropy increased only by a small constant.

James

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

#1242 — Re: I knew I was going to dislike New Google Groups!

On Apr 11, 9:16 pm, James Dow Allen <jdallen2...@yahoo.com> wrote:
> On Apr 11, 12:54 am, lawcouns...@gmail.com wrote:
>
> > because the 'smaller' compressed 1,000 such sequences is NOT in
> > same such sequences format again any more .....
>
> It is straightforward to convert a uniform random string of
> bits into a string of your (a,b,c) format with the expected
> entropy increased only by a small constant.
>
> James


I have posted reasons related to WHY here needs 1st wait for 0.08 bits
savings
attained

LawCounsels

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

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.compression

csiph-web