| View previous topic :: View next topic |
| Author |
Message |
BitGenix
Guest
|
 Posted: Wed Aug 27, 2008 5:14 am Post subject: Re: The Harrington Compression Method (HCM) White Paper. |
 |
|
Disfruta las emociones que experimentas ahora, de creer haber
encontrado el algoritmo que cambiara nuestra era informatica. Muy
pronto experimentaras la desilusion mas profunda de tus terorias.
Solo te falta algo para no caer de verguenza en verguenza. Ser un
programador. Asi solo podras llevar tus teorias a la practica
absoluta, previniendo tus desilusiones.
El equivocarse es parte de nuestra evolucion, pero el ser testaduro es
parte de nuestra personalidad.
Suerte. |
|
| |
|
 Back to top |
Einstein
Guest
|
| Posted: Wed Aug 27, 2008 5:35 am Post subject: Re: The Harrington Compression Method (HCM) White Paper. |
|
|
Mi agradecimiento, si lo entiendo correctamente. Español no es mi
lenguaje más fuerte.
Creo que puedo evitar el problema de malentendidos en breve. Sus
argumentos son un círculo. Soy capaz de escribir algo hasta esta noche
Espero que, si bien en el trabajo, que les ayuden a entender mejor.
La suerte para ti. |
|
| |
|
| Back to top |
Thomas Richter
Guest
|
| Posted: Wed Aug 27, 2008 6:48 am Post subject: Re: The Harrington Compression Method (HCM) White Paper. |
|
|
Einstein schrieb:
| Quote: | Thomas you are trying to divert the actual make up.
It's a simple concept, a 50/50%, a 25/25/25/25%, a
12.5/12.5/12.5/12.5/12.5/12.5/12.5/12.5%, and so forth situation can
be made into a:
Three files with a 75/25% a 67/33% and a 50/50%.
|
All fine, but then again, for each data item, you need to index which
file to take the next item from. For that, you also need some bits. For
example, let's split things up such that we write the (00) combinations
into file A, (01) and (10) into file B and (11) into file C, making this
for IID data two files containing on average 25% of the data, and one
file containing the other 50%. That you use a huffman in advance doesn't
matter, the output of the ideal huffman for a given IID source will be
sufficiently close to IID. Then, obviously, we can simply strip file A
and file C completely since they are all zero or all one, and only need
to keep file B (whoa, what a compression, you might think!). We can even
do better in file B by encoding a 01 as 0 and a 10 as 1, making things
even shorter. But, we also need to identify in a separate file (or the
filing system) which file to use to read the next bits from on
decompression. Obviously, this information is a IID source on a
three-letter alphabet A,B,C with probabilities p(A) = p(C) = 0.25 and
p(B) = 0.5. Thus, an optimal huffman code for this would be
B -> 1
A -> 01
C -> 00
The average length of the output per symbol is then
1 * 0.5 + 2 * 0.25 + 2 * 0.25 = 0.5 + 0.5 + 0.5 = 1.5 bits per symbol
for this side-channel. For the overall file, you need to encode for:
00 :nothing in file A, two bits in the side information: 2 bits
11 :nothing in file C, two bits in the side information: 2 bits
01 :one bit in file B, one bit of side information : 2 bits
10 :one bit in file B, one bit of side information : 2 bits
Thus, you modified your input of 1 bit per symbol into an output using
two bits per two symbols.
Hubba hub, Mr. Marx! |
|
| |
|
| Back to top |
Willem
Guest
|
| Posted: Wed Aug 27, 2008 7:09 am Post subject: Re: The Harrington Compression Method (HCM) White Paper. |
|
|
Einstein wrote:
) 10 00 10 10 01 01 11 01 01 01 11 10 01 01 00 00 11 10 00 11 00 10 00
) 10 00 00 00 11 01 11 11 0
)
) First I divided it into chunks of 2 bits. I found a missing bit, so I
) add a 1 to the end (Command section identifies the missing bit by
) using a bit to say "add a bit to the end")
Yeah sorry, there should have been a 0 at the beginning but the software
cut the leading 0's. I should have checked. But anyways, this will work
just as well, so no real problem there.
NB: I got these from http://www.fourmilab.ch/hotbits/ who claim to be a
genuine source of random numbers.
) <snip>
)
) Note that statistically, since we do have command section issues, we
) have obtained compression, even after adding two bits to the whole.
What do you mean by 'statistically' ?
) Yes the command section requires knowing which swaps we will do per
) file, such as in file #1.2 we swap 00 for 10 in our make up so that it
) has a value length of 2 bits., and 01 in file #1.3 has the same
) happening.
)
) This has 63 bits + command section, for 64 bits. Now the command
) sections will come out to less than 350 bits total. I can even say a
) rounded 500 bits if you desire. Therefore if this statistical sample
) was 31500 bits or more we would have factual compression after the
) command section.
So, what you're saying, roughly, is that by showing that 64 bits can be
compressed to 62 bits plus a 'command section', you have proven that
64000 bits can be compressed to 62000 bits plus a 'command section' ?
And then you claim that the 'command section' has a maximum size.
You're wrong.
The big error you're making here is to assume that your measurement
of compression on a small file will scale up to keep the same ratio
for the bigger files. I see no proof or evidence of this.
It looks like all the compression gain you get is by making a few
choices along the way (such as the swapping of huffman table values)
so you get the best result.
But those choices give you a *constant* gain, not a percentual one.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT |
|
| |
|
| Back to top |
Pasi Ojala
Guest
|
| Posted: Wed Aug 27, 2008 8:50 am Post subject: Re: The Harrington Compression Method (HCM) White Paper. |
|
|
On 2008-08-27, Einstein <michaelhh@gmail.com> wrote:
| Quote: | THOSE FILES ARE TEMPORARY AND THE RESULTS END UP BEING ONE STRING
WHICH IS SMALLER THAN THE ORIGINAL STRING.
|
Why haven't you made them one string in your example then?
To combine the three strings you have to add size information
or otherwise make them prefix codes to make them uniquely
decodable. If you put them to files, the filesystem is
doing this for you. If you put them into one file, you have
to do this yourself.
Please continue your example by combining the strings.
-Pasi
--
"I for one have always found men to be sensible creatures who
only need to be shown the wisest path once to choose it."
-- Faile in The Wheel of Time:"The Shadow Rising" |
|
| |
|
| Back to top |
Guest
|
| Posted: Wed Aug 27, 2008 11:25 am Post subject: Re: The Harrington Compression Method (HCM) White Paper. |
|
|
Einstein wrote:
| Quote: | Your missing the entirety of the system
get past your biases, and just run the numbers as my post about file
#1 shows. It shows a perfect ability to compress data. Get past it man!
|
Shame, shame, shame on you.
You already gone thru this in the past. When making claims the burden
is on you to prove what you claim not others.
You claimed to have tested you idea. But so far you have not:
1) Shown all the steps used to compress the data. All the steps
includes all the control codes/bits. Instead you make claims about
about what the expect number of bits will be. DON'T CLAIM IT, SHOW
IT.
2) You have not shown what the final compressed file will look like,
just claims about what you expect it to be. DON'T CLAIM IT, SHOW IT.
3) And most important, shown that the decompression stage works by
using it on the compressed data and then getting the original data
back. Every con-artist and misled compression expert always seems to
mess up at this stage of the game.
So Einstein if you want people to believe you have something
worthwhile, why are you avoiding doing everything from start to finish? |
|
| |
|
| Back to top |
jacko
Guest
|
| Posted: Wed Aug 27, 2008 11:54 am Post subject: Re: The Harrington Compression Method (HCM) White Paper. |
|
|
On 26 Aug, 17:14, Willem <wil...@stack.nl> wrote:
| Quote: | Einstein wrote:
) Introduction:
) This is a lossless compression method which WILL work on random binary
) data and data considered Entropic.
snip
I'll jump right to the blatant error.
) File 1.1 = 1.05 bits
) File 1.2 = 1.04 bits
) File 1.3 = .75 bits
) File 2 = 2.83 bits
) File 3 = 2 bits
)
) Statistically speaking there are 7.67 bits for every original 8 bits.
And you have 5 files instead of 1. This represents extra information.
So much extra that it easily accounts for the 0.33 bits/byte you 'gained'..
) 5)Command Section
) We now need a command section to handle all the different files,
) changes, etc. Each file will have a specific number of bits. This can
) be easily represented with a simplistic counting system allowing for
) maximum space savings. If < 1 kilobyte then 00, if less than 1
) megabyte then 01, if less than 1 gigabyte then 10, if greater than 1
) gigabyte then 11.
I note that you fail to calculate how many bits this command section will
take, statistically.
) The claim of the pigeon hole problem naturally arises at this point.
) However, all the steps are reversible and lead IMMEDIATELY back to the
) same original code. No two results will be exactly the same. It is
) mathematically not possible. The HCM system completely leads to the
) data as inputted originally.
Note that the counting theorem has been proven true.
|
Or the bounds of the system used to prove the 'argument' have been
exceeded, by such a simplistic assumption that all compression must
work by direct mapping of 2^n bit state possibilities of n bits.
Nothing actually said anything about 1 of 2^n to another of 2^n being
in anyway informative. No mutual information calculation has been
shown. reduct6o-ad-OBSERDum has the right name. Apart from this you
are most probably right.
cheers
jacko |
|
| |
|
| Back to top |
Einstein
Guest
|
| Posted: Wed Aug 27, 2008 3:38 pm Post subject: Re: The Harrington Compression Method (HCM) White Paper. |
|
|
On Aug 27, 5:19 am, Jym <Jean-Yves.Moyen+n...@ens-lyon.org> wrote:
| Quote: | On Wed, 27 Aug 2008 04:39:28 +0200, Einstein <michae...@gmail.com> wrote:
It can take a serious programmer less than 8 hours to make this thing.
Hell it should take less than 4 hours even. I realize this little
fact, and instead will be forced to run figure after figure, all
compressing, until someone decides to make a system to test it through
larger random files.
OK. Then let's do the following bet.
******************************************
1/ The bet starts on Monday Spetember the first, 00:00 GMT.
2/ The bet pauses once you produce a program that implements HCM.
3/ The bet stops once a program implementing HCM has been checked to (for
a given n of your choice)
* Compress every n bits strings into a strictly less than n bits string
AND * Compress two different n bits strings in two different results.
4/ While the bet run and is not paused, you give me 1 euro each day.
5/ At the time the bet stops, I give you 1,000,000 euros.
******************************************
|
Dammit if I was a programmer... I would take that and walk away 1
million euro's richer.
I am looking for a programmer, I would take you up on that deal, if I
knew a programmer right now.
If you lived in Portland Oregon I would start handing you $1 a day,
with a signed contract, in a heart beat, til it was made, with this
sort of bet... |
|
| |
|
| Back to top |
Jym
Guest
|
| Posted: Wed Aug 27, 2008 5:19 pm Post subject: Re: The Harrington Compression Method (HCM) White Paper. |
|
|
On Wed, 27 Aug 2008 04:39:28 +0200, Einstein <michaelhh@gmail.com> wrote:
| Quote: | It can take a serious programmer less than 8 hours to make this thing.
Hell it should take less than 4 hours even. I realize this little
fact, and instead will be forced to run figure after figure, all
compressing, until someone decides to make a system to test it through
larger random files.
|
OK. Then let's do the following bet.
******************************************
1/ The bet starts on Monday Spetember the first, 00:00 GMT.
2/ The bet pauses once you produce a program that implements HCM.
3/ The bet stops once a program implementing HCM has been checked to (for
a given n of your choice)
* Compress every n bits strings into a strictly less than n bits string
AND * Compress two different n bits strings in two different results.
4/ While the bet run and is not paused, you give me 1 euro each day.
5/ At the time the bet stops, I give you 1,000,000 euros.
******************************************
Notice that I'm leaving you 4 days to write your code instead of the 8
hours you claim you need. And that you can easily aford to hire some
external programmer if you don't have the skills, you will have plenty of
money to hire him...
While the bet is on pause, we'll have to perform an exhaustive check on
all possible data for a given n of your choice, this may obviously take
some time, which is the reason why during the pause no one owes money to
anyone.
I don't think that an exhaustive checks would take much more than a few
months, so that there should be no problem...
The caracteristics of the program I've described in step 3 are the one I
understood you're claiming you can achieve with your algorithm.
The first one ensure that compression indeed occurs for each and every
input and the second one ensure that the algorithm is lossless and that
you can uncompress each string unikely.
So, if HCM works, this bet is actually very interesting for you...
And I guess that nobody here on usenet will be upset by you not answering
to messages if you're accepting the bet (and taking your time to actually
write the code instead of being "forced to run figure after figure").
Do you accept the bet ?
--
Hypocoristiquement,
Jym. |
|
| |
|
| Back to top |
biject
Guest
|
| Posted: Wed Aug 27, 2008 5:26 pm Post subject: Re: The Harrington Compression Method (HCM) White Paper. |
|
|
On Aug 27, 9:38 am, Einstein <michae...@gmail.com> wrote:
| Quote: | On Aug 27, 5:19 am, Jym <Jean-Yves.Moyen+n...@ens-lyon.org> wrote:
On Wed, 27 Aug 2008 04:39:28 +0200, Einstein <michae...@gmail.com> wrote:
It can take a serious programmer less than 8 hours to make this thing.
Hell it should take less than 4 hours even. I realize this little
fact, and instead will be forced to run figure after figure, all
compressing, until someone decides to make a system to test it through
larger random files.
OK. Then let's do the following bet.
******************************************
1/ The bet starts on Monday Spetember the first, 00:00 GMT.
2/ The bet pauses once you produce a program that implements HCM.
3/ The bet stops once a program implementing HCM has been checked to (for
a given n of your choice)
* Compress every n bits strings into a strictly less than n bits string
AND * Compress two different n bits strings in two different results.
4/ While the bet run and is not paused, you give me 1 euro each day.
5/ At the time the bet stops, I give you 1,000,000 euros.
******************************************
Dammit if I was a programmer... I would take that and walk away 1
million euro's richer.
I am looking for a programmer, I would take you up on that deal, if I
knew a programmer right now.
If you lived in Portland Oregon I would start handing you $1 a day,
with a signed contract, in a heart beat, til it was made, with this
sort of bet...
|
I an a programmer maybe not the best but trust me you are
wrong you would not win. Please stop and took a good look before
you go to far down this path. Its a mistake many make I don't think
any one can show you. You will not belive them. Yes it will work
for some files just not many. What are you going to do yell at
the programmer who can't get it to work. Because it will not work.
I think if you sit back and take a long hard look yourself you will
see its wrong. Go ahead and patent though the patent office may
grant you a patent anywhy since many software patents having
nothing to do with reality so no big deal.no fact someday you
can just laugh at it.
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" |
|
| |
|
| Back to top |
Einstein
Guest
|
| Posted: Wed Aug 27, 2008 7:19 pm Post subject: Re: The Harrington Compression Method (HCM) White Paper. |
|
|
Ok today is a busy day, went to an inventors assistance place, they
will be reaching some programmers to have me talk to.
Going to a University professor as well, and I will be presenting the
method to the statistician.
In person I seem to 100% communicate the whole thing, with no doubts
left behind, but online I seem to have communication issues. |
|
| |
|
| Back to top |
Jym
Guest
|
| Posted: Wed Aug 27, 2008 8:51 pm Post subject: Re: The Harrington Compression Method (HCM) White Paper. |
|
|
On Wed, 27 Aug 2008 17:38:59 +0200, Einstein <michaelhh@gmail.com> wrote:
| Quote: | On Aug 27, 5:19 am, Jym <Jean-Yves.Moyen+n...@ens-lyon.org> wrote:
On Wed, 27 Aug 2008 04:39:28 +0200, Einstein <michae...@gmail.com
wrote:
It can take a serious programmer less than 8 hours to make this thing.
Hell it should take less than 4 hours even. I realize this little
fact, and instead will be forced to run figure after figure, all
compressing, until someone decides to make a system to test it through
larger random files.
OK. Then let's do the following bet.
******************************************
1/ The bet starts on Monday Spetember the first, 00:00 GMT.
2/ The bet pauses once you produce a program that implements HCM.
3/ The bet stops once a program implementing HCM has been checked to
(for
a given n of your choice)
* Compress every n bits strings into a strictly less than n bits
string
AND * Compress two different n bits strings in two different results.
4/ While the bet run and is not paused, you give me 1 euro each day.
5/ At the time the bet stops, I give you 1,000,000 euros.
******************************************
Dammit if I was a programmer... I would take that and walk away 1
million euro's richer.
I am looking for a programmer, I would take you up on that deal, if I
knew a programmer right now.
|
I think sites such as sourceforge have some kind of "marketplace" where
you can place ads if you have a project and need a programmer.
or you can also learn to program yourself. Even if it takes you one year
(which would be a pretty long time), it is still worth it...
| Quote: | If you lived in Portland Oregon I would start handing you $1 a day,
with a signed contract, in a heart beat, til it was made, with this
sort of bet...
|
Well, if you lived in Paris, I would start going to fetch my daily euro...
We can still arrange this kind of thing via paypal or similar system.
--
Hypocoristiquement,
Jym. |
|
| |
|
| Back to top |
Guest
|
| Posted: Wed Aug 27, 2008 9:15 pm Post subject: Re: The Harrington Compression Method (HCM) White Paper. |
|
|
Einstein wrote:
| Quote: | In person I seem to 100% communicate the whole thing, with no doubts
left behind, but online I seem to have communication issues.
|
You mean you were able to convince people who knew little or nothing
about compression that you know what you are talking about. You just
can't convince anyone who knows anything about the pitfalls of
developing compression methods.
And still, you have refuse to go step by step and show all stages of
you compressing an example string, creating the single file that would
contain all the resulting output and control bits, then showing the
step by step decompression.
Why? What are you so scared of that you can't just show us step by
step how your system works?
If you had done that instead posting all the wordage you have done so
far the argument would be over. |
|
| |
|
| Back to top |
Jym
Guest
|
| Posted: Wed Aug 27, 2008 10:44 pm Post subject: Re: The Harrington Compression Method (HCM) White Paper. |
|
|
On Wed, 27 Aug 2008 19:26:07 +0200, biject <biject.bwts@gmail.com> wrote:
| Quote: | 3/ The bet stops once a program implementing HCM has been checked to
(for a given n of your choice)
* Compress every n bits strings into a strictly less than n bits
string
AND * Compress two different n bits strings in two different results.
I an a programmer maybe not the best but trust me you are
wrong you would not win. Please stop and took a good look before
you go to far down this path. Its a mistake many make I don't think
any one can show you. You will not belive them. Yes it will work
for some files just not many. What are you going to do yell at
the programmer who can't get it to work. Because it will not work.
|
Of course, it all boils down to the fact that whatever n is there are
exactly 2^n different strings of n bits while there are only 1 + 2 + 4 + 8
+ ... + 2^(n-1) = 2^n - 1 strings of strictly less than n bits.
So it is pretty trivial to see that there cannot be an injection from
strings of n bits to strings of stictly less than n bits and that any
compression method must either be non injective (ie send two differents
strings to the same result, hence there will be some lose in the process)
or not able to compress every single string of n bits (at least one of
them will be at best left the same size).
And no matter how statistical the method is, there will still be at least
one string that is left uncompressed. I'm not betting 1,000,000 euros if
I'm not sure to win...
| Quote: | I think if you sit back and take a long hard look yourself you will
see its wrong. Go ahead and patent though the patent office may
grant you a patent anywhy since many software patents having
nothing to do with reality so no big deal.no fact someday you
can just laugh at it.
|
On the other hand, if he is convinced enough that his thing is working to
be ready to dismiss a proof as simple as this one and to make the bet, I
don't see why I shouldn't take advantage of it. Maybe you can do the same
bet with him and maybe he's ready to accept it with several people...
I am not trying to steal some money from the guy, the conditions of the
bet are clear enough and the proof of the impossibility of his claim is
easy enough that I believe he is able to follow it (actually, given the
text of some of the other messages, I think he already know that proof but
somehow believe that his method can escape it -see what he says about
"pigeon hole principle" at some point).
If everytime someone came up with a "perfect compression" or a "deciding
the HALT" problem such a bet was made, maybe we could one day some doing
again and again the same undergraduate proof to people not listening to
them.
[actually, I've seen a similar bet stated on comp.theory some time ago
(during last year, I believe) by someone whose name I don't remember right
now and I'm just reusing the thing which I consider being a nice idea.]
--
Hypocoristiquement,
Jym. |
|
| |
|
| Back to top |
biject
Guest
|
| Posted: Wed Aug 27, 2008 10:55 pm Post subject: Re: The Harrington Compression Method (HCM) White Paper. |
|
|
On Aug 27, 1:19 pm, Einstein <michae...@gmail.com> wrote:
| Quote: | Ok today is a busy day, went to an inventors assistance place, they
will be reaching some programmers to have me talk to.
Going to a University professor as well, and I will be presenting the
method to the statistician.
In person I seem to 100% communicate the whole thing, with no doubts
left behind, but online I seem to have communication issues.
|
Its a mistake. The statistican will be of no help. You have to be
very careful because they will think your crazy. Your not crazy you
just want to so deeply do something of worth. that your mind is
playing tricks on you. I hope when and if this blows over that you
come back to the group and tell us what happened.
Take Care
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" |
|
| |
|
| Back to top |
|
