Re: Repeatable compression is possible and easy to do, here's how...

(sorry for the duplicate msg, Phil -- it was an accidental mouse
click.)

I realize (once again,) that you folks are not the right forum. I
have learned this in the past -- but then I wasn't willing to give
something away -- now I am, and I thought that would matter.

I was wrong. I'll get my files to Mark and won't go into anything
here. Again, sorry to have disturbed you folks.

Know this though, if someone in the 19th century claimed that it was
possible to fly, say to move one's self and even an entire family or
even a large group of people, within a few hours across the Atlantic
or the Pacific, they would not be believed. Any why? Because the
math and all human experience says otherwise (at least, in the mind of
a reasonable observer of the period.) Well, I don't disagree -- wrt
compression I agree that our natural laws prevent it.

(Hey, now, all we have to do is to solve the problem of Arab
terrorism... In fact, in the early 1800's, Jefferson had to negotiate
to obtain the release of Americans captured off the Barbary coast.)

Anyway, knowing this, I have designed and built a different kind of
compressor/decompressor. I don't try to "package up" the data, to
represent it in a smaller 'package', because even with an
extraordinarily good-quality compressor, I could only obtain a very
small gain, over say, bzip. As I have been saying, I do something
else. Ready for a shocker?: I chose a method that is immune to the
limits that all other methods (basically, two Huffman and arithmetic,)
suffer from.

In conversations (admitedly, not recently,) a few of you have asked me
for source code and wanted to collaborate -- the few times I did this
I came to regret my decision. So this time, I intend to do something
very different, I am publishing the kernel code and intend to allow
Mark to compress the file himself. He will soon have the complete
source code for my compressor. I need to make a few small changes to
protect the idea, but only a very few lines of code need to be changed
(so far, though I am taking the time to consider my edits -- three
lines seems to do it.)

And he and I will work on a means to validate the decompressor. For
example, besides a flight here or there, he may nominate a locally
available stand-in. As I say, he and I will work out something...

But looking over the past decade or so, you folks are neither kind or
polite -- and most definitely you are not scientists. Because a
scientist employs the scientific method but your conduct has made that
an impossibly difficult road for me. Don't agree? -- look at the past
postings here.

--jg




On Oct 23, 10:51 am, Phil Carmody <thefatphil_demun...@xxxxxxxxxxx>
wrote:
Jim Leonard <MobyGa...@xxxxxxxxx> writes:
On Oct 23, 7:23 am, jg <jules.sto...@xxxxxxxxx> wrote:
I do expect to use this method, as inefficient as it is, on Nelson's
MILLION-DIGIT file. In fact, because the compressor is public, it's
easy for Mark to run the compressor step himself. (Mark, I'll send
you the code to do this as soon as I get to the machine which has my
compressor work.)

We don't give a damn about the compressor. Anybody can write a
program that outputs garbage. We need to see a working *decompressor*
(ie. prove your transforms are reversible) before we'll take you
seriously.

I'd like to suggest the algorithm for the Jules Gilbert Compressor:

1) Add Jules Gilbert to your killfile - set to expunge, not just mark as read.
2) Wait until he next posts.
3) He's compressed down to nothing!

Note - this is _not_ lossy compression.

Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration


.

Relevant Pages