Re: jacko

On Feb 23, 3:28 pm, "George Johnson" <matri...@xxxxxxxxxxx> wrote:
<industrial_...@xxxxxxxxxxx> wrote in message

news:1172253882.737360.237460@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
| On Feb 23, 9:12 am, "Matt Mahoney" <matmaho...@xxxxxxxxx> wrote:
| > Dudes, I don't mean to interrupt your flame war but the OP was about
| > Jacko's infinite recursive compression. The FAQ on random compression
| > was last updated in 1994. It is seriously outdated. You can find the
| > most up to date research athttp://endlesscompression.com/
| >
| > Anyway, as I understand jacko's method, it was originally implemented
| > as a hardware device consisting of a counter, a high speed oscillator
| > and a precise clock. The idea is to represent a file as a binary
| > number, then decrement the count at a constant rate and time how long
| > it takes to reach zero. Then you transmit the time it took. To
| > decompress, you need an identical device that counts upwards, and you
| > run it for exactly the same length of time to recover the original
| > data. (Since the OP flunked 9th grade math, I will be happy to
| > explain what a binary number is. It is a number where the only digits
| > are 0 and 1, like 1, 10, 11, 100, 101, 110, 111, 1000, 1001, etc).
| >
| > Jacko realized that the time was itself a number which could be fed
| > back into the machine to compress further. By repeating this
| > operation over and over, any arbitrarily large file could be
| > compressed down to a few bits. The exact number depends on the speed
| > of the oscillator, the size of the counter, and the accuracy of the
| > clock, but I believe it was around 77 bits in the device he built.

[clipped]

| > So be careful. You might make some money, but don't ask for too
| > much. These guys play rough.
| >
| > -- Matt Mahoney
|
| Damn, that is pretty messed up. A telecom company hired an assassin to
| kill that Jan guy? The next person should just publicly release his
| algorithm before those greedy corp sons of bitches can stop the
| distribution, however nobody in their right mind would give away a
| major discovery for free so... doubt that would happen. I hope you
| guys know about Nikola Tesla, he rejected a deal to get $12 TRILLION.
|
| About Jacko's idea: the hardware trick is pretty clever, but I doubt
| something like that can be turned into software. As far as I know he
| did release it (some project called "Squirt") but I couldn't figure
| out how to work the goddamn thing.

Since you are being less of a totally useless *** in this post I
shall comment with a basic level of respect that I give everyone.

I doubt there was any reason to kill off Jan Sloot aside from the fact
he couldn't deliver the goods for the $8 million invested in his product.
If he could deliver, well we'd see it in usage already because delivering a
less efficient product can result in extra profit from strung out
"upgrades". Delivering even a deliberate slight improvement on the top dog
compression routine would allow for locking up the current market and
freezing out the competition. Keeping a secret by murder is one thing, but
turning down higher profits by eliminating the compression routines
entirely? Fat chance. Rich people do not stay rich by being impulsive,
overtly lethal, and stupid.

The big problem with a "clock tick" compression routine should be
painfully obvious...
One tick = 1 bit out of the string length.
12 bit string composed of various bits --> "110101101011" = 12 bits = 12
clock ticks = 3435 in decimal
3435 clock ticks converted to binary base again = "110101101011"
Net compression savings = 0%
Saving the info that the file has 4 zero bits + 8 on bits results in
diddly squat for data reconstruction.
XOR-ing the file by "101010101010" clock ticks = "11111000001" = 12 bits
= 1985 in decimal
Net compression savings = 0% (despite a distinct improvement in
repetition factor for later compression)

Since this is no longer a secret on the basic concept, it isn't too hard
to reconstruct the discovery if it was indeed a valid result.
Creating a XOR remap table for certain bit string lengths could be
profitable despite required increase in the data compression / decompression
executable file(s). But this, is not a unique concept in and of itself.

Yeah, I never could get jacko's idea to work in software. But I found
another way. I had some ideas using Heuristic Univariate Recursive
Logic that I implemented using a Vector Optimized Matrix Inversion
Transform.

http://cs.fit.edu/~mmahoney/compression/barf.html

-- Matt Mahoney

.