The Chaotic Braid Compression Method, Cont'd
- From: "Erik Evenson" <erikXevensonX2000@xxxxxxxxx>
- Date: Sun, 31 Jul 2005 05:00:45 GMT
The Chaotic Braid Compression Method, Cont'd.
My source of inspiration:
The form of a natural-fiber rope gave me
the idea for a new method.
Consider the fiber in the rope. There is no
uniformity in the indivdual fibers. But taking
all the thread fibers as a whole a uniform shape
is formed along the rope's length.
Within the rope there are weak fibers, thin fibers,
strong fibers, thick fibers of different lengths.
As the fibers twist around each other the differences
amongst them become unimportant. It is through the
concerted effort of all the fibers, in effect
normalizing individual properties, that the
uniform shape of the rope is created.
So the many unite into one.
Many weak, short-lengths of fiber are made into a
long shape of uniform size and length.
Some initial parameters:
My test data to be compressed will have 65536 bits
of any kind of data.
A Database of random values is created.
Given a value 0 thru 255 as an input value (counter-index),
the database will return 4 exclusive values from 1 to 32
and a sigle bit, 0 or 1, for each of those values as an output.
This data is permanent and can be used for compression
and decompression of any data.
I am setting my method up for a 12.5% compression rate.
That means that for the pre-decompression data of length
57,344 bits the method will return 65,536 bits.
My method is iterative. Compression occurs one bit at a
time per cycle.
The central part of my method uses the Thread module,
named after the rope example above. There are 1,792
individual thread modules of 32 bits each. The bits in
the modules are changed during each iteration cycle.
There is controlled lossy compression during each cycle
since the module is always maintained at 32 bits.
I will talk more about the module later.
These modules are the only data represented in the
compressed buffer. In total there are 32*1792=57,344 bits
in the compressed data before any decompression begins.
Now each of those module threads have been chosen during
compression because of a counter-index value the module
had at the end of its last iteration cycle. All the 1,792
modules have the same counter-index value of zero. Since
the counter-index value can range from 0 to 255 there have
been about 458,752 sample threads tested more or less to
find the 1,792 threads needed for the compressed output
buffer.
For decompression the 57,344 bits in the compressed buffer
is divided into the individual 1,792 thread modules of
length 32 bits. To each module is added the neccessary
counter-index value of 0.
So, for decompression each thread module has 32 bits of
information plus 8 bits of counter-index information.
At final count there are 1,792 thread modules containing
40 bits of information before decompression begins.
1,792 x 40 = 71,680 bits of information.
These 71,680 bits of information is used to find the
65,536 bits of the original test pre-compression data.
The Counting Principle is not violated.
My method is possible but maybe a little impractable.
Erik T. Evenson
.
- Follow-Ups:
- Re: The Chaotic Braid Compression Method, Cont'd
- From: George Johnson
- Re: The Chaotic Braid Compression Method, Cont'd
- From: Erpy
- Re: The Chaotic Braid Compression Method, Cont'd
- Prev by Date: Re: Where is Stac LZS patent/details?
- Next by Date: Re: Zlib: how to have a header and compressed data
- Previous by thread: Found LZS data
- Next by thread: Re: The Chaotic Braid Compression Method, Cont'd
- Index(es):
Relevant Pages
|
