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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

On Apr 12, 11:10 am, LawCounsels <lawcouns...@gmail.com> wrote:
> 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

>HINT : HOWEVER BUT STILL YES  , the present exact 1,000 sequence CAN
>INDEED BE COMPRESSED SMALLER

>( not withstanding this said to be 'proven' to be 1,5 bits / symbol
>entropy !!!  BUT as James said I could not be at liberty to publicise this
>complete 'new' method at this time ... INDEED they
>were experimentally tested proven & mathematics proved )

would your acquianted companies / compressions research Institutes be
interested acquire
this IP ? .exe ready to show

I suppose a lot of usual paperworks needs be exchanged signed 1st to
send this .exe over ,
and terms in place between us

LawCounsels

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

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

On Apr 12, 4:57 am, LawCounsels <lawcouns...@gmail.com> wrote:
> On Apr 12, 11:10 am, LawCounsels <lawcouns...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > 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
> >HINT : HOWEVER BUT STILL YES  , the present exact 1,000 sequence CAN
> >INDEED BE COMPRESSED SMALLER
> >( not withstanding this said to be 'proven' to be 1,5 bits / symbol
> >entropy !!!  BUT as James said I could not be at liberty to publicise this
> >complete 'new' method at this time ... INDEED they
> >were experimentally tested proven & mathematics proved )
>
> would your acquianted companies / compressions research Institutes be
> interested acquire
> this IP ? .exe ready to show
>
> I suppose a lot of usual paperworks needs be exchanged signed 1st to
> send this .exe over ,
> and terms in place between us
>
> LawCounsels

  Actually the start of each sequnce to next sequence is not fixed.
You bijective map any sequence of symbols of ABC to a file that is
meets his ending criteria.

  Since your putting strings together take a sequence of 2000 symbols
from the IID source he mentioned.  It will be 1.5 bits per symbol.
know to map that to a series string that ends in his type of ending
bijectively is childs play.  He seemed to be aware of the Craig trap
when I asked to map to several strings. But the fact is you always
save
some bits per mapping since the last symbol is FREE often more than
one symbol is free so you will always save at least 1 bit since last
C is never needed.

example if N = 1
use A for ACC
use B for BCCC
use C for CC

use CC for CCCC when N=2

Know that it is known that you always save some bits for any
such squence regardless of number of sequences allowed in his
large compressed file.  IN fact you always save bits if the
number of sequences is unconstrained.

Know if you really want to play the game and fix N to say 1000
such sequences you play the combination game which is obviously
the game he wishes to play.  You find the exact number of combinations
needed and that assign strings 0 to first combination and 1 to second
and 00 to third and so on.  Big Deal I don't wish to code this for him
for at least 2 reasons. He most likely has already done it. Its not
that
hard and secondly I doubt I would ever see a dime from him. Wjy would
anyone give money for this it makes no sense to me.


 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]

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

On Apr 12, 4:38 pm, biject <biject.b...@gmail.com> wrote:
> On Apr 12, 4:57 am, LawCounsels <lawcouns...@gmail.com> wrote:
>
>
>
>
>
> > On Apr 12, 11:10 am, LawCounsels <lawcouns...@gmail.com> wrote:
>
> > > 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
> > >HINT : HOWEVER BUT STILL YES  , the present exact 1,000 sequence CAN
> > >INDEED BE COMPRESSED SMALLER
> > >( not withstanding this said to be 'proven' to be 1,5 bits / symbol
> > >entropy !!!  BUT as James said I could not be at liberty to publicise this
> > >complete 'new' method at this time ... INDEED they
> > >were experimentally tested proven & mathematics proved )
>
> > would your acquianted companies / compressions research Institutes be
> > interested acquire
> > this IP ? .exe ready to show
>
> > I suppose a lot of usual paperworks needs be exchanged signed 1st to
> > send this .exe over ,
> > and terms in place between us
>
> > LawCounsels
>
>   Actually the start of each sequnce to next sequence is not fixed.
> You bijective map any sequence of symbols of ABC to a file that is
> meets his ending criteria.
>
>   Since your putting strings together take a sequence of 2000 symbols
> from the IID source he mentioned.  It will be 1.5 bits per symbol.
> know to map that to a series string that ends in his type of ending
> bijectively is childs play.  He seemed to be aware of the Craig trap
> when I asked to map to several strings. But the fact is you always
> save
> some bits per mapping since the last symbol is FREE often more than
> one symbol is free so you will always save at least 1 bit since last
> C is never needed.
>
> example if N = 1
> use A for ACC
> use B for BCCC
> use C for CC
>
> use CC for CCCC when N=2
>
> Know that it is known that you always save some bits for any
> such squence regardless of number of sequences allowed in his
> large compressed file.  IN fact you always save bits if the
> number of sequences is unconstrained.
>
> Know if you really want to play the game and fix N to say 1000
> such sequences you play the combination game which is obviously
> the game he wishes to play.  You find the exact number of combinations
> needed and that assign strings 0 to first combination and 1 to second
> and 00 to third and so on.  Big Deal I don't wish to code this for him
> for at least 2 reasons. He most likely has already done it. Its not
> that
> hard and secondly I doubt I would ever see a dime from him. Wjy would
> anyone give money for this it makes no sense to me.
>
>  David A. Scott
> --
>  My Crypto codehttp://bijective.dogma.net/crypto/scott19u.ziphttp://www.jim.com/jamesd/Kong/scott19u.zipold version
> My Compression codehttp://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"- Hide quoted text -
>
> - Show quoted text -

without .exe there is no way to know if your solution attains 0.08
bits savings per sequence

should above attains your solution itself already guarantees
underwrites the prize

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

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

On Apr 11, 12:56 am, LawCounsels <lawcouns...@gmail.com> wrote:
> 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

Any very high entropy binary file when chopped to ternary trits will
have close distribution of 50 percent 0, 25 percent 10 , 25 percent
11.

Where reverse Huffman apply 0-A, 10-B, 11-C

So this is what law mean turning a random file to biases probability.

He is now try to ask this room to compress the reverse Huffman
probability,

An attempt to create recursive compression


0101100010101111000001111
0
10
11

Well, 3 million usd was nothing to this kind of feat, well until now
luckily,

No one found the solution yet,  include me !

it won't work dear, I did work on the same bias 7 years ago.

I do have a few close to jackpot algorithms, but still I had abandon
them, the reason  is simple,

50% 25% 25% is not precise and not constant for all the files you try
to resolve.

The differences need entropy and thus overwrite the savings.


Regards,

Fibonacci

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

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

On Monday, April 30, 2012 3:36:33 PM UTC+1, Fibonacci Code wrote:
> 
> Any very high entropy binary file when chopped to ternary trits will
> have close distribution of 50 percent 0, 25 percent 10 , 25 percent
> 11.

am awful busy at the moment hardly time to spare .... can you kindly 1st help quick clear simple explain how arbitrary choosing any # of bits from a random binary file will ALWAYS give 50%  '0'   25% '10'    25%  '11' ? 

... to proceed then : ) 


BTW : are you  or anyone here fluent with C#  & leading edge combinatorics ( 'multinomial' enumerative lexicocographic rank Index etc , or can easy quick pick up ) ... am looking for a few more high calibre 'confidential' co-researchers developers on this unprecedented immensely rewarding profit-shares .

email your short details private  to LawCounsels at aol dot com 
 
> Where reverse Huffman apply 0-A, 10-B, 11-C
> 
> So this is what law mean turning a random file to biases probability.
> 
> He is now try to ask this room to compress the reverse Huffman
> probability,
> 
> An attempt to create recursive compression
> 
> 
> 0101100010101111000001111
> 0
> 10
> 11
> 
> Well, 3 million usd was nothing to this kind of feat, well until now
> luckily,
> 
> No one found the solution yet,  include me !
> 
> it won't work dear, I did work on the same bias 7 years ago.
> 
> I do have a few close to jackpot algorithms, but still I had abandon
> them, the reason  is simple,
> 
> 50% 25% 25% is not precise and not constant for all the files you try
> to resolve.
> 
> The differences need entropy and thus overwrite the savings.
> 
> 
> Regards,
> 
> Fibonacci

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

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

Am 30.04.2012 17:34, schrieb lawcounsels@gmail.com:
> On Monday, April 30, 2012 3:36:33 PM UTC+1, Fibonacci Code wrote:
>>
>> Any very high entropy binary file when chopped to ternary trits will
>> have close distribution of 50 percent 0, 25 percent 10 , 25 percent
>> 11.
>
> am awful busy at the moment hardly time to spare .... can you kindly 1st help quick clear simple explain how arbitrary choosing any # of bits from a random binary file will ALWAYS give 50%  '0'   25% '10'    25%  '11' ?

If the file is a perfect Bernoulli source, then indeed the probabilities 
are exactly that: p(0) = 1/2 = p(1). Since we assume the source to be 
iid, symbol probabilities are independent, hence p(x_n x_{n-1} ) = 
p(x_n) * p(x_{n-1}) and hence p(00) = p(10) = p(01) = p(11) = 1/2 * 1/2 
= 1/4.

This is a five-second argument. Note that "random" may mean a lot of 
things, but Bernoulli source is probably a good interpretation (as in: 
what an ideal coin throw experiment should generate, for a fair coin).

> BTW : are you  or anyone here fluent with C#&  leading edge combinatorics ( 'multinomial' enumerative lexicocographic rank Index etc , or can easy quick pick up ) ... am looking for a few more high calibre 'confidential' co-researchers developers on this unprecedented immensely rewarding profit-shares .

No thanks - not interested in doing business with you.

Greetings,
	Thomas

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

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

On Apr 30, 11:34 pm, lawcouns...@gmail.com wrote:
> On Monday, April 30, 2012 3:36:33 PM UTC+1, Fibonacci Code wrote:
>
> > Any very high entropy binary file when chopped to ternary trits will
> > have close distribution of 50 percent 0, 25 percent 10 , 25 percent
> > 11.
>
> am awful busy at the moment hardly time to spare .... can you kindly 1st help quick clear simple explain how arbitrary choosing any # of bits from a random binary file will ALWAYS give 50%  '0'   25% '10'    25%  '11' ?
>
> ... to proceed then : )
>
> BTW : are you  or anyone here fluent with C#  & leading edge combinatorics ( 'multinomial' enumerative lexicocographic rank Index etc , or can easy quick pick up ) ... am looking for a few more high calibre 'confidential' co-researchers developers on this unprecedented immensely rewarding profit-shares .
>
> email your short details private  to LawCounsels at aol dot com
>
>
>
>
>
>
>
> > Where reverse Huffman apply 0-A, 10-B, 11-C
>
> > So this is what law mean turning a random file to biases probability.
>
> > He is now try to ask this room to compress the reverse Huffman
> > probability,
>
> > An attempt to create recursive compression
>
> > 0101100010101111000001111
> > 0
> > 10
> > 11
>
> > Well, 3 million usd was nothing to this kind of feat, well until now
> > luckily,
>
> > No one found the solution yet,  include me !
>
> > it won't work dear, I did work on the same bias 7 years ago.
>
> > I do have a few close to jackpot algorithms, but still I had abandon
> > them, the reason  is simple,
>
> > 50% 25% 25% is not precise and not constant for all the files you try
> > to resolve.
>
> > The differences need entropy and thus overwrite the savings.
>
> > Regards,
>
> > Fibonacci

Not always, as I mentioned

 50% 25% 25% is not precise and not constant for all the files you try
> to resolve.

It is very likely for high entropy file, eg densely packed.

So it won't work.


Cheers,

Fibonac

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

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

On Monday, April 30, 2012 5:58:38 PM UTC+1, Fibonacci Code wrote:
> On Apr 30, 11:34 pm, lawcouns...@gmail.com wrote:
> > On Monday, April 30, 2012 3:36:33 PM UTC+1, Fibonacci Code wrote:
> >
> > > Any very high entropy binary file when chopped to ternary trits will
> > > have close distribution of 50 percent 0, 25 percent 10 , 25 percent
> > > 11.
> >
> > am awful busy at the moment hardly time to spare .... can you kindly 1st help quick clear simple explain how arbitrary choosing any # of bits from a random binary file will ALWAYS give 50%  '0'   25% '10'    25%  '11' ?
> >
> > ... to proceed then : )
> >
> > BTW : are you  or anyone here fluent with C#  & leading edge combinatorics ( 'multinomial' enumerative lexicocographic rank Index etc , or can easy quick pick up ) ... am looking for a few more high calibre 'confidential' co-researchers developers on this unprecedented immensely rewarding profit-shares .
> >
> > email your short details private  to LawCounsels at aol dot com
> >
> >
> >
> >
> >
> >
> >
> > > Where reverse Huffman apply 0-A, 10-B, 11-C
> >
> > > So this is what law mean turning a random file to biases probability.
> >
> > > He is now try to ask this room to compress the reverse Huffman
> > > probability,
> >
> > > An attempt to create recursive compression
> >
> > > 0101100010101111000001111
> > > 0
> > > 10
> > > 11
> >
> > > Well, 3 million usd was nothing to this kind of feat, well until now
> > > luckily,
> >
> > > No one found the solution yet,  include me !
> >
> > > it won't work dear, I did work on the same bias 7 years ago.
> >
> > > I do have a few close to jackpot algorithms, but still I had abandon
> > > them, the reason  is simple,
> >
> > > 50% 25% 25% is not precise and not constant for all the files you try
> > > to resolve.
> >
> > > The differences need entropy and thus overwrite the savings.
> >
> > > Regards,
> >
> > > Fibonacci
> 
> Not always, as I mentioned
> 
>  50% 25% 25% is not precise and not constant for all the files you try
> > to resolve.
> 
> It is very likely for high entropy file, eg densely packed.
> 
> So it won't work.
> 


Agrees ! it certainly will not work as you correct said on any very high entropy binary file chopped to ternary trits ( since very likely will
have close distribution of 50 percent 0, 25 percent 10 , 25 percent
11 ).....

IMPORTANT TO NOTE your very same high entropy binary file chopped to ternary trits above IS VERY COMPLETE DIFFERENT from the 'constraint' present in the US$3M data compression sequences NAMELY EACH SEQUENCE WHICH IS COMPRESSABLE ENDS WITH EXACT 2 MORE 'C's  THAN # OF 'B's  within each sequence [ this is complete different & absent from merely 50% '0'  25% '10'  25% '11' probabilities  ] 
 


> Cheers,
> 
> Fibonac

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

#1222

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 * # OF SEQUENCES ENCODED )  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 

LawCounsels

NB should anyone wins I certainly recommends to opt for the US$3M ( this minimum of US$3M is GUARANTEED BY YOUR WINNING SOLUTION ITSELF ! )

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

#1226

On Apr 10, 3:29 am, LawCouns...@aol.com wrote:
> 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.zipold version
> > My Compression codehttp://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

  Well that partial clears it up.  It looks like you want to compress
say
1000 of these sequences to a single file of bits or bytes not sure
which
your looking for is it ok to output to a files of ascii 1 and 0 then
the total
number of bytes would represent the actual number of bits or what. You
have
not cleared that up.

  Second you keep talking about a generator would have a probability
model
of 25% : 25% : 100% You seem to ignore the fact that even for a
thousand
sequences that a model with say 30% : 30% : 40% could generate exactly
the
same 1000 sequences.  What I am saying here is that James could write
code
that wins based on his random set of 1000 sequences.  You could keep
generating
a so called set of random sequences such that in time you come with a
set that
causes his to fail.  To be fair you should add another constraint
example.
say in each 1000 so called sequences the 25% 25% 50% should be bound
to some
range such as (25 +/- .01)% (25 +/- .01)% (50 +/- .01)%  or somes
definable
fixed ranges of A B C. Just to say its generated by some probability
model
is not enough to pin it down.  Or do you really want to pin it down so
a
person could determine on there on if they won or not.

 Please clear this up if you want anyone to look at it seriously.

 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]

#1227

On Apr 10, 3:26 pm, biject <biject.b...@gmail.com> wrote:
>   Well that partial clears it up.  It looks like you want to compress
> say 1000 of these sequences to a single file of bits or bytes not sure
> which your looking for is it ok to output to a files of ascii 1 and 0 then
> the total number of bytes would represent the actual number of bits or what. You
> have not cleared that up.

YES THIS IS ACCEPTABLE ALLOWED
>
> To be fair you should add another constraint
> example.
> say in each 1000 so called sequences the 25% 25% 50% should be bound
> to some range such as (25 +/- .01)% (25 +/- .01)% (50 +/- .01)%  or somes
> definable fixed ranges of A B C. Just to say its generated by some probability
> model is not enough to pin it down.  Or do you really want to pin it down so
> a person could determine on there on if they won or not.
>
>  Please clear this up if you want anyone to look at it seriously.

YES AGREE ..... the .exe must satisfy such 4 out of 5 such  1,000
sequences you described above , 'random' generated
by someone in the forum ( Mark / Thomas / James / yourself ) .... in
addition needs also satisfy the published RULES

>  David A. Scott

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

#1232

On Apr 10, 9:10 am, LawCounsels <lawcouns...@gmail.com> wrote:
> On Apr 10, 3:26 pm, biject <biject.b...@gmail.com> wrote:
>
> >   Well that partial clears it up.  It looks like you want to compress
> > say 1000 of these sequences to a single file of bits or bytes not sure
> > which your looking for is it ok to output to a files of ascii 1 and 0 then
> > the total number of bytes would represent the actual number of bits or what. You
> > have not cleared that up.
>
> YES THIS IS ACCEPTABLE ALLOWED
>
>
>
> > To be fair you should add another constraint
> > example.
> > say in each 1000 so called sequences the 25% 25% 50% should be bound
> > to some range such as (25 +/- .01)% (25 +/- .01)% (50 +/- .01)%  or somes
> > definable fixed ranges of A B C. Just to say its generated by some probability
> > model is not enough to pin it down.  Or do you really want to pin it down so
> > a person could determine on there on if they won or not.
>
> >  Please clear this up if you want anyone to look at it seriously.
>
> YES AGREE ..... the .exe must satisfy such 4 out of 5 such  1,000
> sequences you described above , 'random' generated
> by someone in the forum ( Mark / Thomas / James / yourself ) .... in
> addition needs also satisfy the published RULES
>
>
>
>
>
>
>
> >  David A. Scott

 Look its hard to measure the savings for each file when its all
compressed to
one file.  Since you allow bits to be thought of as Ascii ones and
zero would
it be allowed to compress each sequence to separate files. That way
its easier to
count excess or saved bits.   IN order words could compress
aaacaaabcac to say
"O1100" which is 5 bytes of ascii your allowing to count as 5 bits for
that
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]

#1234

On Apr 10, 7:02 pm, biject <biject.b...@gmail.com> wrote:
> On Apr 10, 9:10 am, LawCounsels <lawcouns...@gmail.com> wrote:
>
>
>
> > On Apr 10, 3:26 pm, biject <biject.b...@gmail.com> wrote:
>
> > >   Well that partial clears it up.  It looks like you want to compress
> > > say 1000 of these sequences to a single file of bits or bytes not sure
> > > which your looking for is it ok to output to a files of ascii 1 and 0 then
> > > the total number of bytes would represent the actual number of bits or what. You
> > > have not cleared that up.
>
> > YES THIS IS ACCEPTABLE ALLOWED
>
> > > To be fair you should add another constraint
> > > example.
> > > say in each 1000 so called sequences the 25% 25% 50% should be bound
> > > to some range such as (25 +/- .01)% (25 +/- .01)% (50 +/- .01)%  or somes
> > > definable fixed ranges of A B C. Just to say its generated by some probability
> > > model is not enough to pin it down.  Or do you really want to pin it down so
> > > a person could determine on there on if they won or not.
>
> > >  Please clear this up if you want anyone to look at it seriously.
>
> > YES AGREE ..... the .exe must satisfy such 4 out of 5 such  1,000
> > sequences you described above , 'random' generated
> > by someone in the forum ( Mark / Thomas / James / yourself ) .... in
> > addition needs also satisfy the published RULES
>
> > >  David A. Scott
>
>  Look its hard to measure the savings for each file when its all
> compressed to
> one file.  Since you allow bits to be thought of as Ascii ones and
> zero would it be allowed to compress each sequence to separate files. That way
> its easier to count excess or saved bits.   IN order words could compress
> aaacaaabcac to say "O1100" which is 5 bytes of ascii your allowing to count as 5 bits for
> that file?


solution immediate becomes 'trivial' already solved should multiple
files be allowed .... think this was Patrick Craig's
solution attempt to AMillionRandomDigits

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

#1233

On 10.04.2012 11:29, LawCounsels@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%

Wait, you now define the probabilities of the symbols. What else do we 
know? Memoryless iid for example?

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

Once you compress multiple sequences, the only thing that you win by the 
"ending condition" on the b/c count is that you do not need to include a 
EOF symbol or a side information that tells you where the sequence 
terminates. You can simply concatenate the sequences and the decoder 
also knows where to truncate the parts. That also means that if you look 
as this scheme as a steam compressor, and you know nothing else about 
the probabilities of the symbols, you simply cannot compress. Otherwise, 
the compression gain of the ending condition allows you only to 
represent the sequence size a tiny bit more effectively than without 
that condition, i.e. the overhead of having to keep the file size in the 
filing system could be considered smaller. However, this is a 
diminishing return, i.e. the overhead *per symbol* becomes obviously 
zero for longer sequences, or more sequences.

Thus, there's nothing to gain as far as I see.

> 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 )

Wait a second, how do you count "bitslength"? The problem here is that, 
by allowing *finite* sequences, you can always push some side 
information into the filing system. Is the output required to be *a 
single file*?

> 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]

#1235

On Apr 11, 1:47 am, Thomas Richter <t...@math.tu-berlin.de> wrote:
> On 10.04.2012 11:29, 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%
>
> Wait, you now define the probabilities of the symbols. What else do we
> know? Memoryless iid for example?


Yes,  memoryless iid


> > 2. compresses these eg 1,000 generated sequences using your .exe ,&  must decode back to the same 1,000 sequences
>
> Once you compress multiple sequences, the only thing that you win by the
> "ending condition" on the b/c count is that you do not need to include a
> EOF symbol or a side information that tells you where the sequence
> terminates. You can simply concatenate the sequences and the decoder
> also knows where to truncate the parts. That also means that if you look
> as this scheme as a steam compressor, and you know nothing else about
> the probabilities of the symbols, you simply cannot compress. Otherwise,
> the compression gain of the ending condition allows you only to
> represent the sequence size a tiny bit more effectively than without
> that condition, i.e. the overhead of having to keep the file size in the
> filing system could be considered smaller. However, this is a
> diminishing return, i.e. the overhead *per symbol* becomes obviously
> zero for longer sequences, or more sequences.
>
> Thus, there's nothing to gain as far as I see.


Yes not from just knowing 1,000 sequences were compressed


> > 3. IF you compressed file bitslength  =<   1.5 * N   - ( 0.08 * # OF SEQUENCES  )  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 )
>
> Wait a second, how do you count "bitslength"? The problem here is that,
> by allowing *finite* sequences, you can always push some side
> information into the filing system. Is the output required to be *a
> single file*?


dont think this side-information 'gain' ever amounts to much to needs
concern here

Yes , must be in a single file ( multiple files NOT allowed for
obvious reasons )

should input 1,000 sequences generated contains N symbols , THEN the
input bitslength is taken to be = N * 1.5 bits long to measure your
compression bits savings against


> > 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]

#1236

On 11.04.2012 11:56, LawCounsels wrote:

>>> 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%
>>
>> Wait, you now define the probabilities of the symbols. What else do we
>> know? Memoryless iid for example?
>
>
> Yes,  memoryless iid

Well, but then what's the point? If the probabilities are as given, and 
the sequences are iid, and you want to compress *many* of these 
sequences (as in: number goes to infinity), and everything is considered 
to be one file, then there is nothing to gain. Entropy is, as one 
computes, 1.5 bits/sample, and this is the lower limit. The only thing 
the "truncation condition" provides you is that you are able to extract 
the sub-sequences from the common output, i.e. it provides you a EOF 
condition. That you cannot compress below 1.5bits/sample is the Shannon 
result of lossless channel coding.

Greetings,
	Thomas

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

#1237

On Apr 11, 9:26 pm, Thomas Richter <t...@math.tu-berlin.de> wrote:
> That you cannot compress below 1.5bits/sample is the Shannon
> result of lossless channel coding.

Yes, he already knows this much.  What you seem to overlook is
that he's refuted, both experimentally and theoretically,
Shannon's theory, the pigeonhole principle, and even the
Kraft's Inequality.  Naturally he's keeping details of his
method secret; wouldn't you?

I repeat my offer to OP.  If you supply an .exe which achieves
the guaranteed reduction you describe, I will supply an .exe
which invokes that .exe and wins the $1,000,000 prize for
MillionDigits.
Can we split the $1,000,000 fifty-fifty?

> Greetings,
>         Thomas

Hello yourself,
          James

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

#1238

On Wednesday, April 11, 2012 3:36:05 PM UTC+1, James Dow Allen wrote:
> On Apr 11, 9:26 pm, Thomas Richter <t...@math.tu-berlin.de> wrote:
> > That you cannot compress below 1.5bits/sample is the Shannon
> > result of lossless channel coding.
> 
> Yes, he already knows this much.  What you seem to overlook is
> that he's refuted, both experimentally and theoretically,
> Shannon's theory, the pigeonhole principle, and even the
> Kraft's Inequality.  Naturally he's keeping details of his
> method secret; wouldn't you?
> 
> I repeat my offer to OP.  If you supply an .exe which achieves
> the guaranteed reduction you describe, I will supply an .exe
> which invokes that .exe and wins the $1,000,000 prize for
> MillionDigits.
> Can we split the $1,000,000 fifty-fifty?
> 
> > Greetings,
> >         Thomas
> 
> Hello yourself,
>           James

YES ... 50/50 will do nicely 

.... gives this few more days if anyone gets to 0.08 bits savings per sequence 
     1st

will be in touch private email re signing

ALSO let me know if companies / compressions reseach Institute / prominent scientists acquaintances happy to collaborate co-develop for the markets

Cheers,
LawCounsels  

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

#1240

On 11.04.2012 16:36, James Dow Allen wrote:
> On Apr 11, 9:26 pm, Thomas Richter<t...@math.tu-berlin.de>  wrote:
>> That you cannot compress below 1.5bits/sample is the Shannon
>> result of lossless channel coding.
>
> Yes, he already knows this much.  What you seem to overlook is
> that he's refuted, both experimentally and theoretically,
> Shannon's theory, the pigeonhole principle, and even the
> Kraft's Inequality.  Naturally he's keeping details of his
> method secret; wouldn't you?

I wouldn't claim nonsense in first place, actually. (-: Initially, when 
I saw the problem my reaction was that there is potentially a chance for 
a very small improvement because the number of possible combinations for 
a string of given size is a tiny bit smaller than the number of 
combinations of all files. There are for example less than 3^3 = 27 
possible three letter strings with the given constraint, so you can 
compress them better because not all combinations are possible. The 
string "CCC" is, for example, not possible.

However, the way the problem is stated right now, namely compress a 
large number of strings of the same type simultaneously into one common 
file kills this advantage completely because then all you know is just 
where to separate strings again, and the advantage is going to zero for 
the total string size going to infinity.

So yes, there remains a possibility for an incredibly small improvement 
that tends to zero as N->infinity. How to take any advantage of it I do 
not see right now, i.e. without requiring infinite precision in an encoder.

Greetings,
	Thomas

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

#1241

On Apr 12, 1:27 am, Thomas Richter <t...@math.tu-berlin.de> wrote:
> On 11.04.2012 16:36, James Dow Allen wrote:
>
> > On Apr 11, 9:26 pm, Thomas Richter<t...@math.tu-berlin.de>  wrote:
> >> That you cannot compress below 1.5bits/sample is the Shannon
> >> result of lossless channel coding.
>
> > Yes, he already knows this much.  What you seem to overlook is
> > that he's refuted, both experimentally and theoretically,
> > Shannon's theory, the pigeonhole principle, and even the
> > Kraft's Inequality.  Naturally he's keeping details of his
> > method secret; wouldn't you?
>
> I wouldn't claim nonsense in first place, actually. (-: Initially, when
> I saw the problem my reaction was that there is potentially a chance for
> a very small improvement because the number of possible combinations for
> a string of given size is a tiny bit smaller than the number of
> combinations of all files. There are for example less than 3^3 = 27
> possible three letter strings with the given constraint, so you can
> compress them better because not all combinations are possible. The
> string "CCC" is, for example, not possible.

YOU'RE ON RIGHT TRACK HERE !

OBSERVANT

> However, the way the problem is stated right now, namely compress a
> large number of strings of the same type simultaneously into one common
> file kills this advantage completely because then all you know is just
> where to separate strings again, and the advantage is going to zero for
> the total string size going to infinity.

YES THE PROBLEM NEEDED TO & WAS  'SIMPLIFIED' ... now that some
understandings in place alreasdy I can now reveal the 'final' complete
details :

. each sequence's  distance to the start position of the next sequence
( ie from start of
present sequence TO start of the next sequence ) IS ALWAYS FIXED [ ie
ascertainable
# of bits ! ] .... FOR SIMPLICITY AT THIS STAGE can just assume this
to be constant fixed
513 bits throughout !!!

HINT : HOWEVER BUT STILL YES  , the present exact 1,000 sequence CAN
INDEED BE
COMPRESSED SMALLER

( not withstanding this said to be 'proven' to be 1,5 bits / symbol
entropy !!!  BUT as James
said I could not be at liberty to publicise this complete 'new' method
at this time ... INDEED they
were experimentally tested proven & mathematics proved )

> So yes, there remains a possibility for an incredibly small improvement
> that tends to zero as N->infinity. How to take any advantage of it I do
> not see right now, i.e. without requiring infinite precision in an encoder.
>
> Greetings,
>         Thomas

LawCounsels

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.compression

csiph-web