Good day everyone,

I've been programming a technique that allows most, if not all files
to be reduced in size.  It is done using cyclic roots and high-degree
polynomials where the total information content of the coefficients is
smaller (sometimes much smaller) than the original text.

The FAQ has been pointed out to me where it "proves" that not all
files can be compressed by any algorithm, but it seems to me that it
has some mistakes.  They aren't serious, but they are oversights that
prevent it from applying to fractal bits, permutations and sorting the
bytes of the original file.

The gist of this algorithm is that when certain polynomials are
iterated over the complex plain (e.g., like the Mandelbrot set),
information can be encoded in the "ragged" edges of the curve.  I'm
afraid this may have been done before, and I don't want to waste any
work.  Does it ring a bell to anyone?

If someone would like to look at my pseudocode, I would be grateful.

CheeriO,
Ash

Well it was a good day...

You have not.

No it's not.

It's not just *called* a proof. It *is* a proof. If you think it's
not a proof, then you are a loon.

Ergo you are a loon.

Yes. I call it "compression by coincidence". You're about the
thousandth loon to pretend its got any merit at all. You won't
be the last.

I wouldn't.

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

Hello again,

Phil, you are jumping to conclusions.  It turns out that if you place
the bytes to be compressed on a square grid and then iterate a complex
polynomial you can show the fractal edges will naturally follow a
significant number of bytes, allowing those to be removed from the
original entropy.  This is the secret to it working for _all_ files,
not just some special form.  I know the mathematical establishment is
slow to embrace change (and wisely so), but Phil, please don't be
ridiculous.

The difficult part is extracting the roots of high-order polynomials,
but this can be done classically using Newton's method adapted for the
complex plane (I'm working on an extension for quarternions, but
Python is not my strength :( ).  Obviously, fractals only carry as
much information as is in the coefficients of their generating
polynomial, but you might be assuming that they carry infinite
information.  Let me know if this is your mistake.

Here's the twist, fractional bits can be extracted from the _exact_
(or nearly so) value of the roots of the polynomials.  This is the
chief error of the Pigeonhold Principle "proof" of impossibilty.  Of
course, the Pigeonhold Principle is very useful in general, but it is
a mistake to apply it to non-integer sets such as fractional bits.

Any data generated from a deterministic process has a Kolmogorov
Complexity that must be lower than the size of the data as the number
of bits to model goes to infinity.  However, in practice it is
impossible to find this optimal Turing machine in general.  However,
the set of strings that are stochastic or contain purely random
elements are themselves bound to fractal models.

But it is not necessary for you to agree, I've shown the proof to a
number of people and none have succeeded in finding any mistakes in
it.  I'm not doing it for the money, but to help the world.

Best,
Ash

One of the better posts this year!.
Phil's post i mean...  ;)

I would also like to nominate this sentence : 'the set of strings that
are stochastic or contain purely random elements are themselves bound
to fractal models'  :)

Thanks Fulcrum.  It's good that someone can appreciately respond to a
challenge to conventional thinking without taking the easy way out.

On Aug 10, 7:35 pm, Fulcrum <werner.bergm...@gmail.com> wrote:

On Aug 10, 5:23 pm, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
wrote:

Yes you have.

Yes it is.

I won't argue with you there.

Yup.

Two words: fuck you.

On Aug 10, 8:01 pm, industrial_...@hotmail.com wrote:

I don't think I understand what you mean industrial_...@hotmail.com
but you are being unfair to Phil.

I think it's best if people would evaluate my ideas on their merits.
You can show fractal convergence using criteria known for decades and
at that point, enough accuracy has been achieved.  My implementation
uses 1 nybble for the main coefficient, and builds from that using a
doubly-linked list.  Each block is stored using offsets as follows.
This is from the README file I'll be distributing with my source
code.  I apologize but fixed-width format is needed to properly read
it.

         +---+---+---+---+---+---+---+---+---+---+
         | SEQUENCE  |HD |     COEF      | BYTE  | (ctd.)
         +---+---+---+---+---+---+---+---+---+---+
         | MAIN NUMBER   |   POWER EXP   | MODE  | (ctd.)
         +---+---+---+---+---+---+---+---+---+---+
         | TY| X | Y | Z | TIME  | PERF  | PRIME |
         +---+---+---+---+---+---+---+---+---+---+

With this key:
HD = head
TY = type
X, Y, Z = codes for which roots of -1
TIME = timestamp
PERF = performance characteristic to optimize
PRIME = base of polynomial (not Galois)

The high-precision root extractions can be done in 33 lines of
assembly, or so it seems: I don't have the resources to test this as
well as I'd like.  One other way to model it is to use a network flow
system (or a shortest distance one, which is easily solved with
Dijkstra's algorithm).  I hope you guys wouldn't disagree with
Dijkstra's algorithm... :)

Cheerio,
Ash

On Aug 10, 7:46 pm, Ashley Labowitz <sporecoun...@gmail.com> wrote:

He was obviously trolling, and I was in a "wanna-see-blue-blood-bleed-
red" mood so I think I officially clunked his ass outta this thread
where he can regurgitate his bullshit on some other forum if he has
nothing to add worth reading to the topic.

To be fair, your idea is kinda vague to me, I don't get the exact
mechanics of your algorithm. Put it in a nutshell: how do you expect
to compress *most* of all possible files? By how much? Are there any
limits, if so, what?

Each block contains part of the target file, right?

If you really have the source code, I guess you can work on your idea
with more experienced peoples around this newsgroup, but I doubt
you're covering any new ground (not saying this to be nasty but unless
you can specifically prove any flaws in the counting argument, I don't
think yer gonna get anywhere.) How do you enumerate 4 combos with only
2? A.K.A: How do you compress 00 01 10 or 11 to 0 or 1 (compress all 2
bits to 1) When 0 or 1 can only represent 2 out of the 4 possible
combos?

My theory around this (see posts from 6 months ago) was based on the
nature of "random-appearing data" and that it should have some
distinct feature that "normal, practical" data doesn't and thus should
be able to be comrpessed. But then I realized that "random-appearing
data" makes about 99.99% of all possible files and that the data we
see everyday is a painfully tiny portion (0.0001%) so logically it's
impossible.

The only remaining possible way out of this would be to store data as
"time ticks" where one tick would be an extremely tiny fragment of
time (e.g. 10^-30th of a second.) Simon Jackson I heard is working on
this.

But I'm up for a civilized discussion about your idea, but I request
that you explain with eloquence and simplicity in mind since math
isn't my strength (ironic, isn't it?)

You are a crank, a loon, a babbling drunk baboon.

Help comp.compression by turning your computer off.

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