beyond http://1stworks.com much-acclaimed 'breakthrough'binomial QI : Enumerative Combinatorics multinomial UNLIMITED 'nested multiple constraints' lexicographic ranked index Lattice Paths
LawCo...@aol.com
www.wipo.org/pctdb/en/wo.jsp?wo=2007083157 ( entered US EU Australia
Canada pending ) says :
very simply in an arbitrary large binary file to be compressed ,
convert represent each successive runlengths therein of '0'/s or '1'/
s , ie represent runlength of 1 by bijective symbol '0' of same 1 bit
lengthy , represent runlength of 2 by bijective symbol '10' of same 2
bits length , represent runlength of 3 by bijective symbol '110' of
same 3 bits length , represent runlength of 4 by bijective symbol
'1110' by same 4 bits length ..... represent runlength of L-1 by
bijective symbol '111.....10' by same L-1 bits length ( where L is
the largest runlength in the file , of which there may be just 1 or
several instances ) BUT represent the 1 single latest ocurring
runlength of L in the file by bijective symbol '111....10' by same L
bits length
==> any input random binary file of length M can now always be
compressed converted represented by M-1 bits
this however is only just the very small tip of the iceburg of the
process .... in fact this is only a very small peekhole into the
incredulous process of achievimng near infinite data compression/
mankind's understanding near infinite numbers representation .... some
further 30 separate patents applications have since been filed .....
softwares produced demonstrating the needed essential components been
produced in conjunction with a very well known top US quantum
mathematician & U of Penn professor ( who has unequivocal confirmed
scientic merits in writing ) at a cost of US$20K monthly for a year
I have developed this even further mathematical solid intuitive common
sense every simple proven theorem , very easily understood by any
mathematicians under 15 minutes 'pigeonholes included'
Look forward to further joint research & developments collaborations
with top scientists mathematicians fundamental research institutes/
notable individuals in this field
Look forward,
Intellectual Properties Holding International Limited ( UK)
eFAX : 1 484 3464116
LawCo...@aol.com
with the world's topmost exponents theorist
they were real 'incredulous' helpful complete correct in 'pigeonhole
counting theorem' still applies ( but now proven during discussion for
bthe very 1st time this pigeonhole counting theorem exists as exactly
only 1 single instance of all the possible combinations of M bits
input ) , but this is groundbreaking at very least next very best
thing ever attained to , if not already , 'near' infinite ....
it also emerged during joint discussions this initial 'peekhole'
encodings is 'strangely' incidental very successful in
reducing any series/set of integers > 0 , encoded in elias omega or
'pure
runlength , in this it can reduce by 1 bit & with valid grounds
safely assume elias omega/ pure runlength representing random integer
series series always begin with '0'/s runlength .... this is
slightly
more restrictive than near 'infinite' but very good already
[ note : knowing given the initial filesize M bits can help further
forward from what has been achieved in this initial 'peekhole'
code ! ...]
it further arises during discussions knowing input binary filesize
M , it was common agreed by all exponent theorists invariable reduce
1 bit less , but as pointed out needs store 1 bit of input binary
file's very 1st runlength's binary value ...
then emerged can post-append this 1 bit ( either 0 or 1 doesn't
matter ) back
into compressed file ( now filesize M-1+1) if
input binary file's very 1st runlength's binary value is 0 ELSE
compressed file stays as is M-1 bits
==> if input binary file starts with '1'/s compressed file is 1 bit
less, OTHERWISE same M bits
gained compressions for some set of the files with M bits , without
having to have some files of M bits ended up needing more than M
bits
after same compression, is common accepted as 'impossiblity' ( next
to claim of compressibility always 1 bit less ) ....
seems this attained knowing the input filesize ( ? )
the real breakthrough is with enumerative combinatorics ( very
foundations of numbers ) lexicographic ranked index Lattice Path
nested 'multiple constraints' solution which is more successful ,
does not depend on
this initial 'peekhole' code which was just a 'peekhole' leading
to .... primarily computation of this ranked lexicographic index
lattice path of all possible
paths given contraints/ multiple constraints is inherently NP-
Complete non-linear time ....., we have overcome this NP-Complete
computation time hurdle ( software proven ) .... and with this near
linear time solutions to many existing unsolved NP-Complete problems
( may be not all ??? )
Tomic of Quantization Index ( http://1stworks.com ) recent fame
pioneered enumerative
lexicographic ranked index Lattice achieving hundered/ thousand
times
faster encoding/decoding .... and this utilises only very very de
minimis '0'/s & '1'/s
constraint
Thomas Richter
> 1st basics [ OUTLINE ONLY NOT IN DETALS ]
>
> www.wipo.org/pctdb/en/wo.jsp?wo=2007083157 ( entered US EU Australia
> Canada pending ) says :
>
> very simply in an arbitrary large binary file to be compressed ,
> convert represent each successive runlengths therein of '0'/s or '1'/
> s , ie represent runlength of 1 by bijective symbol '0' of same 1 bit
> lengthy , represent runlength of 2 by bijective symbol '10' of same 2
> bits length , represent runlength of 3 by bijective symbol '110' of
> same 3 bits length , represent runlength of 4 by bijective symbol
> '1110' by same 4 bits length ..... represent runlength of L-1 by
> bijective symbol '111.....10' by same L-1 bits length ( where L is
> the largest runlength in the file , of which there may be just 1 or
> several instances ) BUT represent the 1 single latest ocurring
> runlength of L in the file by bijective symbol '111....10' by same L
> bits length
>
> ==> any input random binary file of length M can now always be
> compressed converted represented by M-1 bits
You posted this nonsense before, and I'm sorry that you wasted now money
on this. You forget that you need to encode the first symbol (whether it
is one or zero), otherwise the run information cannot be decoded
uniquely. IOW, the files 010110 and 101001 are by your method compressed
to the same string. Too bad. Like everything else, it has been discussed
already. I have a simpler non-reversible data destructor (avoiding to
call it "compression") that reduces every random binary file by one bit:
Strip off the first bit.
> I have developed this even further mathematical solid intuitive common
> sense every simple proven theorem , very easily understood by any
> mathematicians under 15 minutes 'pigeonholes included'
You forget the counting argument which is a mathematical solid intuitive
common sense every simply proven theorem, very easily understood by any
mathematicians of age 15 or under.
> Look forward to further joint research & developments collaborations
> with top scientists mathematicians fundamental research institutes/
> notable individuals in this field
If *that* is how far your "top science" goes, I afraid you'll not be
able to find any.
So long,
Thomas
LawCo...@aol.com
consider an input binary file with specified 'binmomial' constraint of
of 50Million '0's & 50Million '1's , with Quantization Index (
http://1stworks.com Tomic's recent pioneered QI enumeration
lexicographic ranked index lattice path ) the complete range of all
possible lattice paths ranked index values requires up to 100Million
binary bits to completely cover the 2^100Million possible lattice
paths
whereas with 'multinomial' constraint if specifying 50Million '0'
runlengths of 1 & 50Million '1' runlengths of 1 the complete
range of all possible lattice paths ranked index values requires only
1 single binary bit to completely cover the 2 possible lattice paths
1st of only 2 possible lattice paths
=========================
(0, 50M) (50M, 50M)
_
|_
|_
|_
|_
|_
(0, 0) (50M, 0)
2nd of only 2 possible lattice paths
=========================
(0, 50M) (50M, 50M)
|_
|_
|_
_
|_
|
(0, 0) (50M, 0)
mathematics proven Near Infinite Numbers Representation [ ie
Enumerative Combinatorics nested 'multiple constraints' multinomial
Lexicographic Ranked Index Lattice Paths patents applications family ,
extendable completely to any general geometric/ graphs constructs not
needs be restricted to Lattice structures ] magnitudes orders enables
new magnitudes orders 'breakthrough' commercial implementations which
would invairiable guarantees provide expected on average very much
than 100s/1000s x smaller lossless compressed filesize, from any
possible total random input binary files of arbitrary large M bits
LawCo...@aol.com
No , Enumerative Combinatorics lexicographic ranked index Lattice
paths is totally complete detached not connected with the above
mentioned 'peekhole'
encodings 0->1 runlength 10->2 runlengths 110->3 runlengths .... 1111-
>latest occurring largest runlength ...... , extending http://1stworks.com
Tomic's much-acclaimed recent 'breakthrough' QI ( which Rissanen of
Arithmetic Codings been conciously searching for for 30 days )
this initial encoding scheme , powerful though it is , is only a
historic backdrop detailing how my reseach began with a powerful
simple encoding scheme above even though this encoding is of not very
much significance , BUT eventual further independent paths researches
led to mathematics proven Enumerative Combinatorics multinomial
'nested multiple paths' lexicographic ranked index Lattice paths .....
just as Tomic independently derived 'breakthrough' binomial QI Lattice
paths at the same time
LawCo...@aol.com
> paths is totally complete detached not connected with the above
> mentioned 'peekhole'
>
> Tomic's much-acclaimed recent 'breakthrough' QI ( which Rissanen of
> Arithmetic Codings been conciously searching for for 30 days )
>
> this initial encoding scheme , powerful though it is , is only a
> historic backdrop detailing how my reseach began with a powerful
> simple encoding scheme above even though this encoding is of not very
> much significance , BUT eventual further independent paths researches
> led to mathematics proven Enumerative Combinatorics multinomial
> 'nested multiple paths' lexicographic ranked index Lattice paths .....
> just as Tomic independently derived 'breakthrough' binomial QI Lattice
>
Enumerative Combinatorics multinomial 'nested multiple paths'
lexicographic ranked index Lattice paths is completely independent
does not require nor needs know nor make use of the mentioned initial
'peekhole' encodings ( 0->1 runlength 10->2 runlengths 110->3
runlengths ....
1111- >latest occurring largest runlength )
..... just like Tomic's QI Lattice paths was in no way related any
such encoding format , it was mentioned merely as a backdrop how my
research interest into numbers representations all began ....
this 'breakthrough' Enumerative Combinatorics multinomial 'nested
multiple paths' lexicographic ranked index Method has to do only with
Lattice Paths ( not the 0->1 runlength 10->2 runlengths 110->3
runlengths .... 1111- >latest occurring largest runlength
encodings) , just like 'breakthough' QI has to do Lattice Paths only
Unknown
Pete Fraser
news:4a2962b1$0$12655$ba4a...@news.orange.fr...
> is there any ".exe" somewhere to test it ?
Yes.
LawCo...@aol.com
> is there any ".exe" somewhere to test it ?
yes the latest finished software component .exe does the lexicographic
index value ranking / unranking for arbitrary large input binary file
in near linear time ( overcame common accepted to be inherent NP-
Complete computation time )
it uses Mathematica base
I will either needs get some guy to add limited time Trial Expiration
on top before making general public release sometime soon
or host the software on a dedicated server sometime soon .... like
the http://gridftp.co.uk which host completed softwares for one of my
other patents
Thomas Richter
*Sigh*. Post the output of the following input files using your "method":
0
1
00
01
10
11
000
001
010
011
100
101
110
111
Or rather, try to compress and decompress them with your "method", and
see your error yourself.
So long,
Thomas
Metatron
> You forget the counting argument which is a mathematical solid intuitive
> common sense every simply proven theorem, very easily understood by any
> mathematicians of age 15 or under.
May _that_ is the problem, they all over 15 with a lot of calcium
carbonate somewhere ... :)
I lately ask myself if the counting "argument" can't also be
explained by a physics analogy. With materia density, that you just
can't "compress" materia in an infinite way? At some point you loose
first molecular integrity then atomar integrity, and all just got to
hell? I don't know it's maybe a lame idea, but in physics there are
not much morons claiming to be able to "compress"/"decompress" materia
in inpossible ways (damn the entire oil-reserves transported in a
single tanker ;--) ), I guess.
Ciao
Niels
earlcolby...@sympatico.ca
> On 5 June, 19:23, "parent" <:-)> wrote:
>
> > is there any ".exe" somewhere to test it ?
>
> yes the latest finished software component .exe does the lexicographic
> index value ranking / unranking for arbitrary large input binary file
> in near linear time ( overcame common accepted to be inherent NP-
> Complete computation time )
In other words, no decoder.
And you want to insure that no-one can test your software
indepentantly to test if you are cheating with hidden files.
LawCo...@aol.com
its EC (emumerative combinatorics 'multinomial' lexicographic ranked
index Lattice paths Method , as in similar to but de minimis binomial
Tomic's QI , not even remotely connected to the mentioned non-
significant 'peekhole' codes )
.... really needs large enough filesize of M bits ( to sufficient
compensate allow for multiplicity table of runlengths storage ,
requiring similar to log(base2)M small number of bits to represent
which becomes insignificant trivial with larger M ) , not just 4
bits , to be able compress represent .... but will oblige but for
these too very small M bits example we will have to ignore the log
(base2)M multiplicity table of runlengths 'extra' storage costs
>
> 0 output is binary bit '0' ( together with , & based on > *Sigh*. Post the output of the following input files using your "method":
its EC (emumerative combinatorics 'multinomial' lexicographic ranked
index Lattice paths Method , as in similar to but de minimis binomial
Tomic's QI , not even remotely connected to the mentioned non-
significant 'peekhole' codes )
.... really needs large enough filesize of M bits ( to sufficient
compensate allow for multiplicity table of runlengths storage ,
requiring similar to log(base2)M small number of bits to represent
which becomes insignificant trivial with larger M ) , not just 4
bits , to be able compress represent .... but will oblige but for
these too very small M bits example we will have to ignore the log
(base2)M multiplicity table of runlengths 'extra' storage costs
>
> 0 output is binary bit '0' ( together with , & based on 'multinomial' Runlengths' Multiplicity Table specified '0' runlengths of 1 , ie '0' runlengths of 1=1 )
> 1 output is binary bit '1' ( together with , & based on 'multinomial' Runlengths' Multiplicity Table specified '1' runlengths of 1 , ie '1' runlengths of 1 =1)
'1' runlengths of 1=0)
> 00 output is 1 binary bit '0' ( together with , & based on 'multinomial' Runlengths' Multiplicity Table specified '0' runlengths of 2 , ie '0' runlengths of 2 =1 )
> 01 output is 1 binary bit '0' ( together with , & based on 'multinomial' Runlengths' Multiplicity Table specified '0' runlengths of 1 & '1' runlengths of 1 , ie '0' runlengths of 1 =1 & '1' runlengths of 1 =1 )
> 10 output is 1 binary bit '1' ( together with , & based on 'multinomial' Runlengths' Multiplicity Table specified '0' runlength of 1 & '1' runlengths of 1 , ie '0' runlengths of 1 =1 & '1' runlengths of 1 =1)
> 11 output is 1 binary bit '1' ( together with , & based on 'multinomial' Runlengths' Multiplicity Table specified '0' runlengths of 2 , ie '1' runlengths of 2 = 1 )
> 000 output is 1 binary bit '0' ( together with , & based on 'multinomial' Runlengths' Multiplicity Table specified '1' runlengths of 3 , ie total number of distinct disjoint '1' runlengths of 3 =1)
> 001 output is 1 binary bit '0' ( together with , & based on 'multinomial' Runlengths' Multiplicity Table specified '0' runlength of 2 & '1' runlengths of 1 , ie '0' runlengths of 2 =1 & '1' runlengths of 1 =1)
> 010 output is 1 binary bit '0' ( together with , & based on 'multinomial' Runlengths' Multiplicity Table specified '0' runlength of 1 & '1' runlengths of 1 , ie total number of distinct disjoint '0' runlengths of 1 =2 & total number of distinct disjoint '1' runlengths of 1 =1)
> 011 output is 2 binary bit '00' ( together with , & based on 'multinomial' Runlengths' Multiplicity Table specified '0' runlength of 1 & '1' runlengths of 2 , ie total number of distinct disjoint '0' runlengths of 1 =1 & total number of distinct disjoint '1' runlengths of 2 =1)
> 100 output is 2 binary bit '11' ( together with , & based on 'multinomial' Runlengths' Multiplicity Table specified '0' runlength of 2 & '1' runlengths of 1 , ie total number of distinct disjoint '0' runlengths of 2 =1 & total number of distinct disjoint '1' runlengths of 1 =1)
> 101 output is 1 binary bit '1' ( together with , & based on 'multinomial' Runlengths' Multiplicity Table specified '0' runlength of 1 & '1' runlengths of 1 , ie total number of distinct disjoint '0' runlengths of 1 =1 & total number of distinct disjoint '1' runlengths of 1 =2)
> 110 output is 1 binary bit '1' ( together with , & based on Multiplicity Table specified '0' runlength of 1 & '1' runlengths of 2 , ie total number of distinct disjoint '0' runlengths of 1 =1 & total number of distinct disjoint '1' runlengths of 2 =1)
> 111 output is 1 binary bit '1' ( together with , & based on 'multinomial' Runlengths' Multiplicity Table specified '1' runlengths of 3 , ie total number of distinct disjoint '1' runlengths of 3 =1)
> 1 output is binary bit '1' ( together with , & based on Multiplicity Table specified '1' runlengths of 1 , ie '1' runlengths of 1 =1)
'1' runlengths of 1=0)
> 00 output is 1 binary bit '0' ( together with , & based on Multiplicity Table specified '0' runlengths of 2 , ie '0' runlengths of 2 =1 )
> 01 output is 1 binary bit '1' ( together with , & based on Multiplicity Table specified '0' runlengths of 1 & '1' runlengths of 1 , ie '0' runlengths of 1 =1 & '1' runlengths of 1 =1 )
> 10 output is 1 binary bit '0' ( together with , & based on Multiplicity Table specified '0' runlength of 1 & '1' runlengths of 1 , ie '0' runlengths of 1 =1 & '1' runlengths of 1 =1)
> 11 output is 1 binary bit '1' ( together with , & based on Multiplicity Table specified '0' runlengths of 2 , ie '1' runlengths of 2 = 1 )
> 000 output is 1 binary bit '0' ( together with , & based on Multiplicity Table specified '1' runlengths of 3 , ie total number of distinct disjoint '1' runlengths of 3 =1)
> 001 output is 1 binary bit '0' ( together with , & based on Multiplicity Table specified '0' runlength of 2 & '1' runlengths of 1 , ie '0' runlengths of 2 =1 & '1' runlengths of 1 =1)
> 010 output is 1 binary bit '0' ( together with , & based on Multiplicity Table specified '0' runlength of 1 & '1' runlengths of 1 , ie total number of distinct disjoint '0' runlengths of 1 =2 & total number of distinct disjoint '1' runlengths of 1 =1)
> 011 output is 2 binary bit '00' ( together with , & based on Multiplicity Table specified '0' runlength of 1 & '1' runlengths of 2 , ie total number of distinct disjoint '0' runlengths of 1 =1 & total number of distinct disjoint '1' runlengths of 2 =1)
> 100 output is 2 binary bit '11' ( together with , & based on Multiplicity Table specified '0' runlength of 1 & '1' runlengths of 2 , ie total number of distinct disjoint '0' runlengths of 2 =1 & total number of distinct disjoint '1' runlengths of 1 =1)
> 101 output is 1 binary bit '1' ( together with , & based on Multiplicity Table specified '0' runlength of 1 & '1' runlengths of 1 , ie total number of distinct disjoint '0' runlengths of 1 =2 & total number of distinct disjoint '1' runlengths of 1 =1)
> 110 output is 1 binary bit '1' ( together with , & based on Multiplicity Table specified '0' runlength of 1 & '1' runlengths of 2 , ie total number of distinct disjoint '0' runlengths of 1 =1 & total number of distinct disjoint '1' runlengths of 2 =1)
> 111 output is 1 binary bit '1' ( together with , & based on Multiplicity Table specified '1' runlengths of 3 , ie total number of distinct disjoint '1' runlengths of 3 =1)
>
Pls TYPOs excepted , notify if seen
the bijective 'outputs' strings are clear , output strings here always
=< M bits ( even though M very insignificant small = 3 here ,
necessiting ignoring the similarly to log(base2)M runlengths
multiplicity table storage costs , which becomes increasingly
insignificant when M -> very large )
LawCo...@aol.com
ranking.exe is the encoder , unranking.exe is the decoder
I commissioned paid for & had myself checked encode & decode faithful
reconstructed original input file of M bits
LawCo...@aol.com
which is why it is at most 'near infinite numbers representations' ,
discussion topic NOT titled moron-like ' nfinite' something
... like matters can only be compressed upto Planck scales like only
exists in Blackholes ... not more
....like pre-E=MC^2 most powerful energy decompressor/ decoder we
have are dynamites , post E=MC^2 we have atomic scale energy
decompressor/ decoder
Pete Fraser
news:63e81aa7-1314-4106...@z19g2000vbz.googlegroups.com...
> I lately ask myself if the counting "argument" can't also be
> explained by a physics analogy. With materia density, that you just
> can't "compress" materia in an infinite way? At some point you loose
> first molecular integrity then atomar integrity, and all just got to
> hell? I don't know it's maybe a lame idea, but in physics there are
> not much morons claiming to be able to "compress"/"decompress" materia
> in inpossible ways (damn the entire oil-reserves transported in a
> single tanker ;--) ), I guess.
I think that analogy hinders.
The counting argument is absolute. No sane person could
conceive of it being wrong. It is not an imperfect description
of the physical world, but it is the application of logic.
Our understnding of physics is always advancing, and there
are many things we don't know and don't understand.
It's possible to compress material a lot (think
of neutron stars and black holes). Back when we didn't know
about neutron stars and black holes, I don't think we could
reasonably have said that they were impossible (unlikely, yes;
contrary to then current theories, yes).
The counting argument is different; it is absolute.
LawCo...@aol.com
> "Metatron" <spamt...@adsignum.com> wrote in message
>
> news:63e81aa7-1314-4106...@z19g2000vbz.googlegroups.com...
> I think that analogy hinders.
>
> The counting argument is absolute. No sane person could
> conceive of it being wrong. It is not an imperfect description
> of the physical world, but it is the application of logic.
>
yes I think & at this time believe this holds true so far as it says &
is truthful understood to mean ' there is always at least 1 single
instance of all possible combination of input filesize M bits that
cannot be compressed represented by 1 single bit less'
EC multinomial lexicographic ranked index Lattice paths however lives
perfect harmonious with 'pigeonholes' , in that it simply says there
can be 'maginutudes oders' more & more sets of total random possible
input files combinations of filesize M bits that can be 'magnitudes
orders' much more & much more invariable guaranteed on average , at
present commercial implementations expected at least > 100s / 1000 s
times compressed represented smaller than original input M bits
AT THIS TIME it is 100% believed there will always be occurs a very
single 'absolute' instance of 'pigeonhole counting theorem'
refutations to any claim to able compress any possible total random M
bits input combinations
LawCo...@aol.com
> > *Sigh*. Post the output of the following input files using your "method":
>
> its EC (emumerative combinatorics 'multinomial' lexicographic ranked
> index Lattice paths Method , as in similar to but de minimis binomial
> Tomic's QI , not even remotely connected to the mentioned non-
> significant 'peekhole' codes )
>
> .... really needs large enough filesize of M bits ( to sufficient
> compensate allow for multiplicity table of runlengths storage ,
> requiring similar to log(base2)M �small number of bits to represent
> which becomes insignificant trivial with larger M ) , not just 4
> bits , to be able compress represent .... but will oblige but for
> these too very small M bits example we will have to ignore the log
> (base2)M �multiplicity table of runlengths 'extra' storage costs
>
>
>
> Pls TYPOs excepted , notify if seen
>
> the bijective 'outputs' strings are clear , output strings here always
> =< M bits ( even though M very insignificant small = 3 here ,
> necessiting ignoring the similarly to log(base2)M runlengths
> multiplicity table storage costs , which becomes increasingly
> insignificant when M -> very large )
this particular initial 'Method' above ( particular chosen ranking
orderings ...etc ) can be further refined optimised improved upon ....
but the Method had been clear illustrated enough
Thomas Richter
No, I don't think there is anything to "ignore" here. If you state that
you can, and I'm quoting:
"==> any input random binary file of length M can now always be
compressed converted represented by M-1 bits"
then what stops you in applying this to M=3?
And, yes, if I count the output size, I do need to count the 'extra'
storage costs as well since those need to be stored in first place to be
able to reconstruct the stream.
Sorry if I wasn't clear enough. Your algorithm generates an output
string in binary. What is that output string - this is the question. I
do not care about the model details at this level. I only care about the
final output, the output that is sufficient to reconstruct the input by
your decompressor.
So what is the size of the "M" at which your compressor starts working?
Let's call it M_0. And will it succeed to make all bit streams of size
M>M_0 by at least one bit shorter?
If not, why are you claiming this? If so, what makes strings of size M_0
so special?
After all, you claim that you can compress any stream of size M>M_0 by
one bit, and hence recursively (by induction) back to M_0.
I hope you are aware that there are only 2^M_0 streams you can
represent, independent of M. If this does not convince you, it should at
least make you suspicious why M_0 is such a special number and where it
might come from.
Hint: There is no such M_0.
So long,
Thomas
Thomas Richter
> On 5 June, 23:29, "Pete Fraser" <pfra...@covad.net> wrote:
>> "Metatron" <spamt...@adsignum.com> wrote in message
>>
>> news:63e81aa7-1314-4106...@z19g2000vbz.googlegroups.com...
>> I think that analogy hinders.
>>
>> The counting argument is absolute. No sane person could
>> conceive of it being wrong. It is not an imperfect description
>> of the physical world, but it is the application of logic.
>>
>> The counting argument is different; �it is absolute.
>
> yes I think & at this time believe this holds true so far as it says &
> is truthful understood to mean ' there is always at least 1 single
> instance of all possible combination of input filesize M bits that
> cannot be compressed represented by 1 single bit less'
No, it's quite the reverse. *Most* inputs are not compressible. Anyhow,
there is a precise answer as "how much" is compressible by any
compressor (no matter whether statistical or not), and that is the Kraft
inequality:
http://en.wikipedia.org/wiki/Kraft's_inequality
In your case, let the alphabet be all M-bit inputs, and let l_i be the
(compressed) size of the input #i (of all 2^M possible inputs), then:
\sum_i 2^{-l_i} <= 1
specifically, the "identity compressor" with l_i = M for all i makes the
sum to one. The other extreme case is the "lena compression" algorithm
with l_0 = 1 and l_i = M+1 for all other M. In this case, the sum is
also one, and this compressor is also "ideal" (i.e. it doesn't waste
codespace). Any *other* compressor is between those extremes.
As you can see, if "some" of the l_i's are shorter than M, then the
terms of those i already contribute *exponentially* to the sum, which
means that either many terms must be *a lot* longer, or *a lot of terms*
must be somewhat longer. In either event, there is no silver bullet, and
you need to pick wisely what to compress and what to expand. You cannot
just make one of the l_i's shorter without investing some length otherwise.
Note that the Kraft inequality is not a statistical argument (we don't
need entropy for it, or a probability space). It's just a result of
"counting more precise than the counting argument", and also follows
from elementary logic.
Compression comes into play as soon as we want to pick *which* l_i's
make larger and which to make smaller, i.e. as soon as we want to
estimate *how* my source might look like.
> EC multinomial lexicographic ranked index Lattice paths however lives
> perfect harmonious with 'pigeonholes' , in that it simply says there
> can be 'maginutudes oders' more & more sets of total random possible
> input files combinations of filesize M bits that can be 'magnitudes
> orders' much more & much more invariable guaranteed on average , at
> present commercial implementations expected at least > 100s / 1000 s
> times compressed represented smaller than original input M bits
And the point is, exactly not that. See above.
> AT THIS TIME it is 100% believed there will always be occurs a very
> single 'absolute' instance of 'pigeonhole counting theorem'
> refutations to any claim to able compress any possible total random M
> bits input combinations
You need to set the quantors correctly:
The following is correct:
"For any (random) input there is a compressor that compresses that input".
while the following is false:
"There is a compressor that compresses any (random) input".
Both claims are very different. In fact, it is easy that even the stronger
"For any random input, there is a compressor that compresses that input
to one bit"
is true. And in fact, within limits, Kraft's inequality allows you
*which* inputs you want to compress, at free, *provided* you compensate
a lot by making others longer. Either many by a lot, or a lot by a bit.
So long,
Thomas
Jim Leonard
> I commissioned paid for & had myself checked encode & decode faithful
> reconstructed original input file of M bits
Then what does your system do to the random million digits file? Does
it compress? Does it decompress to a file identical to the original
input? (Don't assume it does -- test it yourself, or make your .exes
available to us for testing)
Unknown
Ok, where may I found these 2 .exe and test them by myself ?
Metatron
> "Metatron" <spamt...@adsignum.com> wrote in message
Well the tiny little detail with the physics-idea is that you
obviously want to have the entire oil-reserves _back_ out of your
tanker. It's not much use if you just end up with ... oil-plasma would
it be then. For sure not what it was :)
I mean you can compress something real a little, not much (relative).
That's what we can do with data too. If you go too far you just destoy
it. Just like with data.
But, ah, it's just trying to make a picture that can be possibly
easily grasped. If it just would not be necessary ...
Ciao
Niels
LawCo...@aol.com
this 1st working prototype proof-of-concept version limits max number
of distinct possible multinomial input symbols to 128 ( ie all ASCII
only ) & max total number of symbols to 1,000
[ you may want to first convert the Million Random Digit File into
their runlengths , represent these runlengths as series of 1,000
integer numbers > 0 & then represent these integer numbers in many
BLOCKS each of series of 1,000 ASCII characters ( each ASCII represent
different runlengths from 1 to 128 ) , then run encode.exe on a BLOCK
at a time then decode.exe will auto-extract from encoded rank +
internal stored multinomial multiplicity table from datasets
generated by encode.exe ]
here are the accompanying notes from my colleagues :
" both the ranking and unranking for N=1000 and L=128. Again just as
the ranking the unranking is based on the robust mathematical
algorithm that we have developed in house and as expected the
unranking is even faster than the ranking since it only involves
simple comparisons.
Keep in mind that when you are playing with these codes you can keep
both the deconding and encoding windows open so that you can easily
compare the input of the encoding with the output of the deconding.
Obviously, they are in perfect agreement. We are very happy with this
expected result and are ready to move to the next step which is
pushing the limit of N. "
LawCo...@aol.com
> > yes I think & at this time believe this holds true so far as it says &
> > is truthful understood to mean ' there is always at least 1 single
> > instance of all possible combination of input filesize M bits that
> > cannot be compressed represented by 1 single bit less'
>
> No, it's quite the reverse. *Most* inputs are not compressible. Anyhow,
> there is a precise answer as "how much" is compressible by any
> compressor (no matter whether statistical or not), and that is the Kraft
> inequality:
>
> terms of those i already contribute *exponentially* to the sum, which
> means that either many terms must be *a lot* longer, or *a lot of terms*
> must be somewhat longer. In either event, there is no silver bullet, and
> you need to pick wisely what to compress and what to expand. You cannot
> just make one of the l_i's shorter without investing some length otherwise.
>
Thanks for your very valuable theoretic input comments to discussions
BUT needs backtrack a little to day's practicalities [ to reconcile
both ends ] : with binomial QI Lattice Walk on 50M '0's & 50M '1's ,
it needs only ( not more ) at most upto 100M binary bits to cover all
possible approx 2^100M ( to be accurate 100M ! / ( 50M! 50M! ) )
Ranked Index values ranges .... some may have index value 1 or 2 so
these requires only a single binary bit ..... some may have index
value 3 or 4 so these requires only 2 binary bits .... worst case
index values requires only max 100M - 1 binary bits [ note 2^
(100M-1) + 2^(100M-2) + 2^(100M-3) .....+ 2^1 + 2^0 = 2^100M
ie SUM of all 2^(N) s N < 100M gives 2^100M -1 and likely this
'-1' term is the earlier mentioned single 'pigeonhole counting
theorem' refutation ]
knowing constant original filesize 100M binary bits , needs only store
the surplus 'extra' '1's over '0's which is even much less than log
(base2)100M in fact most often needs 1 single binary bit to record
50M 50 M or 50M+1 50M-1 ..... does not seems like there occurs any
Ranked Index value requiring > 100M binary bits to represent ....
also there would not be any use to do any compress whatsoever if one
ends up more often with exponential much larger filesizes than the
rarer small compressions gains on some minority
needs reconcile both ends here....
LawCo...@aol.com
encode.exe decode.exe [ or Rank Unrank ] downloads :
http://www.box.net/shared/static/gsj4371123.zip
LawCo...@aol.com
knowing the constant filesize = 100M binary bits , if any sets of
possible input combinations of 100M bits when compressed would require
filesize > 100M , one could just send the original filesize as is &
receiver on receiving file of 100M bits long would know how to
reconstruct ( these which would otherwise be > 100M bits ) without
needs to do anything ..... whereas now can receive mamy many files
from 100M-1 bits 100M-2 bits 2bits 1 bits 0bit(NULL file) ( or
even NO FILE at all)
> needs reconcile both ends here....- Hide quoted text -
>
> - Show quoted text -
Unknown
we try ?
I can't verufy anything else than your works simply is useless.
LawCo...@aol.com
you type on screen , or copy paste from pre-processed file of symbols
ASCII s each corresponding to successive runlengths in original input
binary file
you can try hand compute small file , tally check with the
computations
you can copy onto clipboard the encoded outputs from screen & use in
place of file output
you can windows search for the all encode.exe 's generated datasets
verify their sizes , or you can hand construct the 'multinomial'
runlengths multiplicity table store on paper to then tally check with
the dataset's own table storage size
LawCo...@aol.com
> you can windows search for the all encode.exe 's generated datasets
> verify their sizes , or you can hand construct the 'multinomial'
> runlengths multiplicity table store on paper to then tally check with
> the dataset's own table storage size
BTW : Colleagues also mentioned they have not worked on optimize small
sizing the internal datasets' generated Multiplicity Table , their
effort then was focused on attaining Near Linear time overcame
multinomial rank/unrank NP-Complete computation time
... its easy enough knowing the runlengths' multiplicity table
distribution to thumb estimate quite accurate required minumum storage
size ( similar to O(log(base2)M) )
, tends towards very insignificant as M -> very large
LawCo...@aol.com
> encode.exe decode.exe �[ or Rank �Unrank ] �
downloads �:http://www.box.net/shared/static/gsj4371123.zip
>
>
>
> > this 1st working prototype proof-of-concept version limits max number
> > of distinct possible multinomial input symbols to 128 ( ie all ASCII
> > only ) & max total number of symbols to 1,000
encode.exe produced output datasets lexTable.txt ( in decimal
digits , you may want to copy paste this to a decimal->binary
converter & check the number of binary digits required to represent
the Ranked Index value ) & symbolTable ( showing total # of
occurrences of each of 128 ASCII characters ( numbered 0 - 127 ? )
NOTE : encode.exe may have a different Rank ordering schemes than
Tomic's own or your own preferred ordering scheme [ eg Ranking Index
value starts with 0 , not 1 .... higher numbered ASCII characters
have more weights , not less ......etc
you may if you wish treats encoder.exe as pure binomial 'binary'
encoder , by using only ASCII characters '0's & '1's only
LawCo...@aol.com
> digits , you may want to copy paste this to a decimal->binary
> converter & check the number of binary digits required to represent
> the Ranked Index value ) �& symbolTable ( showing total # of
> occurrences of each of 128 ASCII characters ( numbered 0 - 127 ? )
>
USAGE GUIDE :
============
copy paste encode.exe decode.exe into DoS default folder directory
( usually its C:\ ) , brings up DoS box type in " encode " enters
ASCII strings ( lexIndex.txt & symbolTable.txt now appears in same
DoS default directory folder ), now brings up another DoS type in
"decode.exe"
LawCo...@aol.com
>is true. And in fact, within limits, Kraft's inequality allows you
>*which* inputs you want to compress, at free, *provided* you compensate
>a lot by making others longer. Either many by a lot, or a lot by a bit.
DISCUSSIONS TOPIC ( reconcile both ends )
===================================
consider binary input constant known filesize M bits , M sufficient
large to absolve any 'extra' costs of eg 'surplus' of '1's over '0's
or similar to log(base2)M runlength multiplicity table storage costs
when encoded can be represented by 2^(M-1) possible combinations all
of M-1 bits + 2^(M-2) possible combinations all of M-2 bits filesize
+ 2^(M-3) possible combinations all of M-3 bits filesize ...... +
2^2 possible combinations of 2 bits filesize + 2^1 possible
combinations of 1 bit filesize + 2^0 possible combinations of 0 bit
(NULL) filesize
SUM( 2^N ) N=M-1 to 0 gives 2^M -1 possible combinations ie its
possible encode any M bits input filesize into smaller M-1 bits M-2
bits M-3 bits ..... 2 bits 1 bit 0 bit EXCEPT there is always
exactly 1 instance of 'pigeonhole counting theorem refutation' among
2^M possible combination of M bits ( making this exact particular
single instance can't be reduced by 1 bit less , unlike all other 2^M
-1 possible combinations )
if as enumerated above being correct , Krafts inequality stating
"there must be some combinations when same encoded requires more bits
to represent" now no longer holds TRUE ( was somehow mistaken
applied / misused ? )
..... comments ?
LawCo...@aol.com
> "there must be some combinations when same encoded requires more bits
> to represent" �now no longer holds TRUE �( was somehow mistaken
> applied / misused �? )
>
> ..... �comments ?
the illusions/ fallacies arises from early compressions 'mistaken'
attempts to reduce every possible input combinations filesize M bits
to eg a smaller fixed # of bits ....
.... in which case Pigeonholes/ Counting Theorem/ Krafts inequality
always invariable holds TRUE you can't encode all possible
combinations of M bits into a fixed smaller number of bits ( only
morons would dispute )
biject
...
> attempts to reduce every possible input combinations filesize M bits
> to eg a smaller fixed # of bits ....
>
....
Actually its much stronger trying to compress every
combination to some fixed number of bits
take 4 bits for example.
that is 16 possible strings
you can map 8 to every 3 bits
you can map 4 to every 2 bits
you can map 2 to every 1 bits
you can even map 1 more to the NULL case or empty file
but that still only adds up to 15 sadly you are stuck
with one case that has no where to go. I also
don't think its fair to use the Null case but
what the heck.
Worse yet if you want to be able to compress
4 bits and 5bits each to a lower string you
still have one exta case at 4 bits that has
not been taken care of so then your stuck with
that and many more from the 5 bits case since
they have been used when trying to make the
4 case smaller.
compression at its best it nothing more than
reordering strings. Some map to smaller some
map to longer strings. We only call it compression
based on the hope that the transformation
we use is good for the small subset of files
that people find useful.
When testing general compressors. If the code
can actually compress some files to a smaller
size. You can always find a larger number
files it will expand to a larger size.
So a test could be rigged to make any compressor
look bad
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"
LawCo...@aol.com
>
> �Actually its much stronger trying to compress every
> combination to some fixed number of bits
>
> take 4 bits for example.
>
> that is 16 possible strings
>
> you can map 8 to every 3 bits
> you can map 4 to every 2 bits
> you can map 2 to every 1 bits
> you can even map 1 more to the NULL case or empty file
>
> but that still only adds up to 15 sadly you are stuck
> with one case that has no where to go.
yes the earlier mentioned exact 1 single instance 'pigeonhole counting
theorem refutation' of all 2^M -1 possible combinations of known
constant fixed M bits input
as mentioned this one EXITS case can be assigned to all '1's ie
'111...11' which could very convenient be transmitted conveyed as M #
of '1's with log(base2)M bits costs , or even just send as '111...11'
M bits costs ( not even > M bits costs )
days practicalities common useful to know of expects fixed constant M
filesize transmissions ( different people may use different value of
M ), for repeat many many multiple use even if includes this log(base2)
M bits fixed costs initially , this costs -> infinitesimal small over
repeated use over & over again ..... theoretics wise is an entirely
different matter altogether
a very large filesize R ( R multiples of M ) can be split into R/M #
of BLOCKS of M bits
>
> Worse yet if you want to be able to compress
> 4 bits and 5bits each to a lower string you
> still have one exta case at 4 bits that has
> not been taken care of so then your stuck with
> that and many more from the 5 bits case since
> they have been used when trying to make the
> 4 case smaller.
>
as mentioned theoretics wise much of what been said are right ....
(?) but think here if compresses 5 bits it doesn't matter what earlier
4 bits does with the 3 bits 2 bits 1 bit 0 bit , 5 bits will EXIT on
exception's all 5 '1's otherwise will continue compresses uses 4 bits
3bits 2bits 1 bit 0 bit ( here again smaller 4 bits if all 4 '1's
will EXIT , smaller 3 bits if all 3 '1's will EXIT , smaller 2 bits if
all 2 '1's will EXIT , smaller 1 bits if all 1 '1' will EXIT )
> compression at its best it nothing more than
> reordering strings. Some map to smaller some
> map to longer strings. We only call it compression
> based on the hope that the transformation
> we use is good for the small subset of files
> that people find useful.
theoretics wise perfect TRUE
days practicalities ( knowing frequent usage filesize/ block size M )
if mapped to longer strings > M can just send original input M
instead
>
> �When testing general compressors. If the code
> can actually compress some files to a smaller
> size. You can always find �a larger number
> files it will expand to a larger size.
>
> �So a test could be rigged to make any compressor
> look bad
yes
however for days practicalities ( knowing frequent usage filesize/
block size M ) if mapped to longer strings > M can just send original
input M instead
earlcolby...@sympatico.ca
This to be the standard BS to me.
So presently we have three people posting to comp.compression that
they have "working" magic compressor, but not a single working example
can be shown.
Yep, the same old BS as always.
Unknown
>they have "working" magic compressor, but not a single working example
>can be shown.
Sorry, but your compressor is one of the "magic" one.
I need a BINARY file in input and other in OUTPUT.
I need a .EXE able to pack any kind of data
at this time, I can't say if your compressor compress something.
LawCo...@aol.com
>
> Sorry, but your compressor is one of the "magic" one.
not TRUE
this initial encode.exe decode.exe was commissioned developed as a
'ground-breaking' proof-of-concept to attain near Linear Time
'multinomial' enumerative combinatorics lexicographic Lattice paths
ranked index representation of binary input file ( 1st converted to
represent the successive runlengths , in form of 128 ASCII characters'
associated number 1 - 128 ) ..... overcame inherent NP-Complete
computation time hurdles was the focus & this we did , Frank Ruskey &
Tomic ( top exponents in this field ) & likely Thomas Richter David
Scott knows this very well
this is the real achievements & they were never meant to showcase
anyone enter into ' goaded 'competitions debates about 'magic
compressors'
> I need a BINARY file in input and other in OUTPUT.
> I need a .EXE able to pack any kind of data
this is the real achievements & they were never meant to showcase
anyone enter into any ' goaded 'competitions debates about 'magic
compressors'
took all combined focus to have this 'groundbreaking' near Linear
Time thing .... there this is 'barest no-frills' uses only on screen
type/ copy paste from file inputs ( in place of input file ) ....
there are output files named lexIndex.txt ( computed ranked index
value in decimal format ) also symbolsTable.txt ( runlengths
multiplicity table )
However they can already show if requires ( unintended when
commissioned ) computed 'multinomial' lexicographic Lattice ranked
index values ( in decimal format , but easily copy this computed
decimal index value , put through decimal -> binary converter utility
on Internet to observe much reduced # of bits than original input
binary file )
yes most Forum authors here can easily accomplish this already .... or
to write own 'all frills' front-end input file processors in an hour
>
> at this time, I can't say if your compressor compress something.
not TRUE .... see above comments
the computed Lattice path index values ( when converted from decimal
into binary ) invariable smaller than original input file but pls add
the bits costs for runlengths multiplicity table ( in most concise
format possible ..more on this next )
IN FACT you can already type only 'pure' binary or copy paste from
original 'pure' binary input file to screen , convert decimal
lexIndex.txt output file -> binary .... should already observe
invariable shorter # of binary bits than original input binary file
( added the runlengths multiplicity table # of bits costs
LawCo...@aol.com
> original 'pure' binary input file to screen , convert decimal
> lexIndex.txt output file �-> binary �.... should already observe
> invariable shorter # of binary bits than original input binary file
> ( added the runlengths multiplicity table # of bits costs
possible , & likely , there is an exact 1 single instance
'exception' , when added the runlengths multiplicity table # of bits
costs, requires exact same # of bits as original input binary file
originial inputs must not be very trivial small # of bits , should
EXITS if so
LawCo...@aol.com
> original 'pure' binary input file to screen , convert decimal
> lexIndex.txt output file �-> binary �.... should already observe
> invariable shorter # of binary bits than original input binary file
> ( added the runlengths multiplicity table # of bits costs
Unknown
>> I need a .EXE able to pack any kind of data
> IN FACT you can already type only 'pure' binary or copy paste from
> original 'pure' binary input file to screen , convert decimal
> lexIndex.txt output file -> binary .... should already observe
> invariable shorter # of binary bits than original input binary file
> ( added the runlengths multiplicity table # of bits costs
I've not any time for playing.
If you want to submit your compressor to professional (i'm a professional
people able to pay to have a strong compressor, i've bought the right to use
one very recently), please, accept to respect some rules.
Phil Carmody
>>So presently we have three people posting to comp.compression that
>>they have "working" magic compressor, but not a single working example
>>can be shown.
Who wrote that? Please learn to attribute correctly.
Checking, I see it's the respected poster Earl.
> Sorry, but your compressor is one of the "magic" one.
Earl doesn't have a compressor, and if he did, it wouldn't be
one of the "magic" ones, as he's not a loon.
Please learn how usenet works, you're currently failing horribly.
Phil
--
Marijuana is indeed a dangerous drug.
It causes governments to wage war against their own people.
-- Dave Seaman (sci.math, 19 Mar 2009)
earlcolby...@sympatico.ca
wrote:
> Earl doesn't have a compressor, and if he did, it wouldn't be
> one of the "magic" ones, as he's not a loon.
In his defense, years ago I did write a near-magical compressor, it
infact was designed to compressed usenet threads that have lots of
quoting of previous messages. My Amiga 1000 only had 2.5 meg of
memory and 800K floppies so space was important then.
Did some quick tests of compressing and decompress some large text
files that were compressing at a 14 to 1 ratio. I read the start of
the threads and the ends as well, and all was good with the world.
So I boasted about my great compressor!
Then I tried to read entire usenet threads that I had compressed for
later reading. ---- They were all garbage in the middle! ---- With
lots of work I fixed the bug in my code and the compression ratio
dropped to 4 to 1. PKZIP for the Amiga was giving me 3.8 to 1.
I learnt my lesson then. ALWAYS TEST THE DECOMPRESSOR's OUTPUT BYTE
BY BYTE!
Pete Fraser
news:e915390b-454a-458f...@21g2000vbk.googlegroups.com...
> years ago I did write a near-magical compressor, it
> infact was designed to compressed usenet threads that have lots of
> quoting of previous messages
I've been toying with writing a usenet compressor that
would remove apostrophe's in plural's. I think I could
save lot's of space that way.
Jim Leonard
> I learnt my lesson then. ALWAYS TEST THE DECOMPRESSOR's OUTPUT BYTE
> BY BYTE!
More importantly, you learned a lesson, which is exactly why I try to
help these people realize the flaw in their ideas. You can salvage
any bad idea by learning from it.
Unfortunately, the magic compression people don't want to believe
their idea is wrong, and as such will never learn.
spor...@gmail.com
> IN FACT you can already type only 'pure' binary or copy paste from
> original 'pure' binary input file to screen , convert decimal
> lexIndex.txt output file -> binary .... should already observe
> invariable shorter # of binary bits than original input binary file
> ( added the runlengths multiplicity table # of bits costs
It do not accept random binary data for example HEX 00 it do not like
and it only support 999 bytes maximal as input.
When I input 501 bytes random input (where HEX 00 is replaced by HEX
88 and HEX 0D is replaced by HEX 77) I can encode it but when I try to
decode it, it use one core 100% but never finish decoding:
lexIndex.txt:
15596087472593621145834480881186637964391967836592543845756501129538021\
757561290864190476405562408059389456138786498828691307247413421312219027\
569469299770745793724799121614380209649955129557609229629161393999979734\
572169626758818113149888644972139974160442143945654426774609154786645535\
139807625913696423095043338470927071684705833308060570474623945935450890\
061612142478150183866777177393971751392758489050247689715817786792304551\
695859743833142196002185750764991548730072602089971663010535704603449098\
539260501304848805771758756885468654227982803864627500306183769485555502\
813415115292756467867463256460704720113398547430607516429952431626844574\
328758700262330156584767087376016937929628374870635529881765531813223001\
279569626485566174970506517190782023827775398124429913769802885218164687\
316331482746428753239743108829072330915184980891002005511969888211401189\
726711885442452631870686407750647798261818477456262409590034465575738865\
024803133001174121433616092253552849307823063254113039455035292903062284\
303732581458725741489981
symbolTable.txt:
106
1 1
2 2
3 2
4 2
5 3
6 3
7 2
9 3
11 1
12 1
14 1
15 2
18 1
22 4
23 1
24 1
25 1
26 1
28 2
30 4
31 2
32 2
33 1
34 4
36 2
37 3
38 2
39 16
40 2
41 3
42 2
44 3
45 4
46 8
47 2
49 2
51 3
52 2
53 1
54 1
55 5
56 1
57 1
58 2
60 7
61 2
62 3
63 19
64 5
65 4
67 2
68 4
69 1
71 2
72 1
73 3
74 2
75 2
76 2
77 2
78 1
79 3
80 2
81 1
82 2
83 9
84 3
85 1
86 2
87 2
88 1
89 5
90 2
91 5
93 3
94 6
95 4
96 3
97 2
98 1
99 2
100 2
101 4
102 1
104 2
105 3
106 3
107 2
108 2
109 3
110 1
111 1
112 3
113 3
115 7
116 4
117 2
118 1
119 2
120 1
121 2
122 3
123 4
124 1
125 2
126 4
stan
> On 9 June, 09:18, "parent" <:-)> wrote:
>> Sorry, but your compressor is one of the "magic" one.
>
> not TRUE
Have to agree here; what you've demonstrated isn't magic.
<snip great quantity of nonsense buzwords randomly strung together>
An opservation.
With the counting argument you get one output for one input. With idiots
you get nearly infinite output with any one input. Maybe the kooks have
found a escape clause in the couting argument after all?
On the other side of the coin, I suspect if you could compress all
nonsense into one single idiot then that one idiot would be completely
indistinguishable form any other idiot.
LawCo...@aol.com
> On Jun 9, 12:48�pm, LawCouns...@aol.com wrote:
>
> > IN FACT you can already type only 'pure' binary or copy paste from
> > original 'pure' binary input file to screen , convert decimal
> > lexIndex.txt output file �-> binary �.... should already observe
> > invariable shorter # of binary bits than original input binary file
> > ( added the runlengths multiplicity table # of bits costs
>
> It do not accept random binary data for example HEX 00 it do not like
> and it only support 999 bytes maximal as input.
>
> When I input 501 bytes random input (where HEX 00 is replaced by HEX
> 88 and HEX 0D is replaced by HEX 77) I can encode it but when I try to
> decode it, it use one core 100% but never finish decoding:
>
you have now confirmed this proof of concept Linear Time 'proto' for
most 'strings' , not all , needs debug
I entered '00000000' alone ( Hex 00 ) it encodes decodes OK
yes decode.exe for this particular input ASCII s takes forever .....
(???)
yes this initial 'proto' still needs debugs, not bug free as yet
pls post original binary input file to examine 'debug' , also idea how
such 'bug/s' arise ?
will forward source if helps
LawCo...@aol.com
I found this the program 'bug' (?) :
I removed all the 'extra' end-of-line ' \ ' characters in
lexIndex.txt & decode now works to completion ( no longer never
finishes )
like to know more encode.exe not accept not like Hex '00' input , I
tried eg '11110000000011001110' & encodes decodes OK
pls post original binary input file
thanks
spor...@gmail.com
> pls post original binary input file to examine 'debug' , also idea how
> such 'bug/s' arise ?
I tried to encode the first 999 bytes of this random bytes file:
http://www.random.org/files/2009/2009-06-04.bin
After copy and past the first 999 bytes from hex editor to encode
command prompt, encode only saw 62 bytes as input, then I replaced HEX
00 by HEX 88 and did the same but now encode saw 91 bytes as input,
then I replaced HEX 0D by HEX 77 and did the same and now encode saw
501 bytes as input. Then I tried decode and got that endless loop.
spor...@gmail.com
> I removed all the 'extra' end-of-line ' \ ' characters in
> lexIndex.txt & decode now works to completion ( no longer never
> finishes )
If I remove that backslashes then decode give a string back but
different then the original input string:
☺☻☻♥♥♦♦♣♣♣♠♠♠ ♂♀♫☼☼↕▬▬▬▬↨↑↓→∟∟▲▲▲▲▼▼ !""""$$%%
%&&''''''''''''
''''(()))**,,,----........//
1133344567777789::<<<<<<<==>>>???????????????????@@@
@@AAAACCDDDDEGGHIIIJJKKLLMMNOOOPPQRRSSSSSSSSSTTTUVVWWXYYYYYZZ[[[[[]]]
^^^^^^____`
``aabccimjfj{dexeshlw~vw~}ushtpzz{{lpdpqsseyq|kztstqim}yniesj~tmko~u{s
It must look like something as this:
ÌÌ<Y¯Â^?,^E¡[^^^õæ [£sLtËZìéÕ^V8w×ßPºïÆ^F$eÑ·mú)S¡Gq¥ñ^?Gm ´à?iä
¢©SSÕÕ╬Ì·'
¡ª±©/{<à'¼?÷p©`|:I¨äWYuÐLtñ"Tµ3çó? ^NSî.A üElhW? ¤?)Ì~ÎàÇ]=IÍÁ
¤Ç?[ü.ÙJA¹·
{Îs'¿@<pØ1Ò^Rõß^D?Ü]yT@ÂD)^L^C5%Üøá@/dü'-?oO¿ó¢ølT^?Ä_Ó^^«se
¿^V^O3@^Y¾¹×<<Vzs«Y^
╬¼%¥╬SS>^j©P7÷f-Ü'^VÚ*¸¥dî<^WèC¸Õ^E?u•®._KôY~sjbè̦SôOYËÓ3õî@A>±w
{Iû^V'^^½t]Ã,R'
Ú'Ë¿ÅÎ^C^_¿^^hD(ßóx.>ø.&º!¶üþ1¿y^AXÄK^B?vj4Á_`°Õ»^E?Á.¦mzi$~%É
¤_âÞD7'"??z<'6'êt^
ÆÃ'^O^D*«k¡ÕiÁN¬.Ò7^F^V,?~ÈØ¡HDó²'e¸^Kßþê':ÆU¦ùaú^Fsä´Ü}°ñ^Xõ.ö`É-û¬¯=
[Ì ÚÁqJ÷
n}Qpîï?ý{³4╬^GƒSaAÎ7æe'ËÇÓ¼7̦÷ºSÃ"s-CcMq╬&O(^\k'äµRƒ^_Z[ºÖ9c?
MÔ"^Z"é©ôÂY¯ñå╬OéÑ
wû┼R&©Áã>^wæF.zm^L¡D¡^E^ÝUï6]±Tý-r^VW½c•^DÝ' zVÜN÷^CS3¤W³H^QÖ^YaÄ
\^Kß<iznQ¸[Ñ
ô^Vr^]•ï"FY"lp'\¥Ú¶ûä^Z?Nÿ¬POTÚb^E)?\&>˧Íjƒ6> 8ƒ¼V¶o^Vð^AÓ?^Q
´É9Ç^^EÆÈéµ÷D^W»¡
7n7dJÁqVPû^R'J-bk^_ƒþ¶qþßÏ
LawCo...@aol.com
>
> I removed all the 'extra' end-of-line �' \ ' characters in
> lexIndex.txt & decode now works to completion ( no longer never
> finishes )
pls ignore above posted superflous 'manual edit' fix , really
continues not finished decode forever ..... and how did you chanced by
such 'fortuitous' input combinations decode.exe now reverts to NP-
Complete computation times never finishes , this will help a lot re
purport to linear time algorithms design ( at present its near
linearvtime for most bits combinations ... but you have somehow
'fortutious' (?) chanced upon bits combinations that needs NP-Complete
computations time (?) )
LawCo...@aol.com
> such 'fortuitous' input combinations decode.exe now reverts to NP-
> Complete computation times never finishes , this will help a lot re
> purport to linear time algorithms design ( at present its near
> linearvtime for most bits combinations ... but you have somehow
> 'fortutious' (?) chanced upon bits combinations that needs NP-Complete
> computations time (?) �)
>
>
>
>
>
> > like to know more encode.exe not accept not like Hex '00' input , I
> > tried eg '11110000000011001110' & encodes decodes OK
>
> > pls post original binary input file
>
got it .... there are indeed non-ASCII ( associated numbered 1-128 )
in the 999 bytes input file : )
pls try copy paste from some of own .txt file , or if prefers own
'pure' binary '0' '1' only .txt file
LawCo...@aol.com
>
> - Show quoted text -
OR you may convert 999 bytes of this random bytes file:
http://www.random.org/files/2009/2009-06-04.bin
into 'pure' binary copy paste on encode.exe screen then run
decode.exe
LawCo...@aol.com
> in the 999 bytes input file �: )
>
> pls try copy paste from some of own .txt file , or if prefers own
if copy paste to screen needs removes all input <carriage-return>
concatenate text characters/ binary string into one single long string
( not sepate lines )
LawCo...@aol.com
> concatenate text characters/ binary string into one single long string
> ( not sepate lines )
SIMPLEST PRIMER ('runlengths multinomial' lex rank index value
requires magnitude less # of binary bits to represent, compared to
'pure binomial ' binary index value)
===============
in encode.exe screen type in binomial binary
"111110000011110000111000110010" gives index value 152026365 ( around
28 binary bits to represent , 30 original input binary bits )
decodes back to same "111110000011110000111000110010"
BUT in encode.exe screen type in the corresponding multinomial
runlengths "5544332211" ( ASCII 5 means runlength of 5 , 4 means
runlength of 4 .....) gives index value 113399 ( only 17 binary bits
to represent , compared to 28 binary bits needed using only original
input 30 bits binomial binary string )
decodes back to same "5544332211"
LawCounsels
> Worse yet if you want to be able to compress
> 4 bits and 5bits each to a lower string you
> still have one exta case at 4 bits that has
> not been taken care of so then your stuck with
> that and many more from the 5 bits case since
> they have been used when trying to make the
> 4 case smaller.
the decades long established 'theories pillars' now needs updates
amends
======================================================
( persisted because all present existing compressions algorithms
implemented today ALL falls under Kraft inequality categories, no
none has yet managed so far to proper come up with design a proper
algorithm to do this as yet )
can compress some combinations of M binary bits to less bits while
some possible combinations remained compressed represented in M bits
WITHOUT any combination of M bits after compression requires > M bits
to represent , even without knowing the original input filesize M at
all ( M > 1 ) :
This new method opens up a whole new fields allowing whole new kinds
of new data compressions methods yet to be designed implemented
All possible combinations M bits remained represented as is in M bits,
EXCEPT the combination of M bits of all ‘1’ which compressed to M-1
bits of all ‘1’s & the combination of M bits of all ‘0’s which
compressed mapped to M-1 bits of all ‘0’s .
Thus if compressed file is M-1 bits of all ‘1’s or all ‘0’s it will
decompress to M bits of all ‘1’s or all ‘0’s , whereas all other
compressed file decompresses to as is same M bits combinations
==> Kraft Inequality , which states if some combination/s of a file
of M bits can be compressed smaller then there must be some
combination/s of the file of M bits that will require more bits > M to
represent after same compression applied , no longer holds true for
this new method of data compression
Another example , among many many possibilities , if knowing constant
fixed input filesize M binary bits ( M > 1 ) :
All combinations of M bits compressed represented in same M bits as
is , EXCEPT combinations of M bits of all ‘1’s or all ‘0’s gets
compressed to 1 single binary bit of ‘1’ or ‘0’
==> Counting Theorem which states there must be at least 1 combination
of M bits that cannot be compressed by 1 bit less , is now ‘narrowed
down’ more accurate updated amended defined to be “ there are exactly
2 combinations of M bits ( exactly 1 combination , if NULL empty set
utilised ) that cannot be compressed represented by 1 bit less” in
this new data compressions method/s
the discussions focus should be now focus on how much lossless
compressions is achievable .... likely not 'infinite' , perhaps 'near
infinite' (?) ........ most likely next best thing to 'near
infinite' (?)
LawCounsels
there is very 'striking' similarity here :
there is also a new 'variable length ' binary numbers notation :
normal binary numbers always starts with a '1' at MSB ( most
significant bit' ) this restrict eg using 3 & 2 & 1 binary bits to
represent at most 7 numbers ( all integers > 0 ) ie 1 bit->{1, 2}
2bits->{3,4} 3bits->{4,5,6,7}. Also the range of numbers
representable by N=3 bits is 4 { 4,5,6,7} ie 2^(N-1)
we now use 'variable length' notation where MSB can be '0' or '1' thus
( assuming to represent integers > 1 ) '0'->1 '1'->2 '00'->3 '01'-
>4 '10'->5 '11'->6 '000'->7 '001'->8 '010'->9 '011'->10 '100'-
>11 '101'->12 '110'->13 '111'->14 '0000'->15 ....so forth
note 3 & 2 & 1 bits can now represent 15 numbers instead of 7
numbers , ie the # s representable by up to N variable length binary
is 2^(N+1) -2 and the range [ NOTE the ' -2 ' here similar to the 2
EXCEPTIONS of all '0's & all '1's ] & the range representable by
exactly N bits is 2^(N)=8 instead of 4
Pls have a simple sub-routine ready to easy convert a number ( integer
> 0) to variable length format , & to reverse convert variable length
format to a number ( integer > 0 ), for use in 2nd part
Earl_Colby_Pottinger
This has to be the most complex input method anyone has come up with
on this usenet group for a so-called compressor.
It seems custom made so that the original author can always claim that
it is the tester's fault that the compress/decompress cycle will fail.
IE. He never has to prove that he has working code because it is
always the user's fault that input has invalid characters.
Why was this pre-processing not included in the original executable?
Probably, to hide the failure of the compressor to meet that author's
claim's I believe.
Unknown
> on this usenet group for a so-called compressor.
> Why was this pre-processing not included in the original executable?
> Probably, to hide the failure of the compressor to meet that author's
> claim's I believe.
I'm completly agree with you.
And of course, the packer can't pack any kind of data (no binary) and can't
pack any size of data too.
The output is only "text" too, you can't verify if the output is smaller
than the input. You can't verify anything.
Earl_Colby_Pottinger
> I'm completly agree with you.
> And of course, the packer can't pack any kind of data (no binary) and can't
> pack any size of data too.
> The output is only "text" too, you can't verify if the output is smaller
> than the input. You can't verify anything.
A thought also came to me after I had posted before. If this
compressor only allows a *limited* number of possible character
sequences to be used, then it is automaticly limiting the possible
range of inputs and thus insuring a binary output is compressable
compared to the original input.
IE. If all inputs are in Hex format but if 11 symbols (of the
possible 256 sequences) are not allowed in an input stream, then it
becomes a snap to insure the a 4-5% compression of the output if it is
outputted as a binary file.
This call for limits on the input looks more like a cheat the more I
look at it.
