For Programmers: Free Programming Magazines  


Home > Archive > Compression > May 2004 > Re: Down Pillow Compression Algorithm -- Additional Information









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Re: Down Pillow Compression Algorithm -- Additional Information
Plato777

2004-05-12, 9:28 pm

evenuscinatus@yahoo.com (Plato777) wrote in message news:<39cccbf4.0404240700.58efedd6@posting.google.com>...
> To All:
>
> Well have more to talk about when I have made
> a successful prototype with which to work the
> theory.
>
> For every direct bit represented in the
> Beta Buffer there have to be released on
> average around 0.6 direct bits from the
> three independent piles. Using the
> running average as a guide I should be
> able to bit by bit produce a successful
> set of control codes.
>


Here is some info on how I am approaching the
creation of the control codes.

Once the groups are formed in the three piles
the piles are mixed into a grand pile and the
all the groupings are then indexed based on the
number of elements. The groupings are further
sub-indexed based on the locations--which
grouping order they belong--of each of
the three unique elements (same elements but
in different piles--same label location
pointer)within the Grand pile.

A register is created listing all the bit
positions of Buffer(A). The order of the
elements of this register is determined from
the Indexing of the Grand Pile.
This organizing will in effect "stack the deck"
in favor in determining which of the bits
in buffer(A)will be directly represented
in buffer(B).
The first entry on the register represents
when used as a direct bit in buffer(B) the
greatest liklihood that the groupings that
include that bit in its set of elements will
be located near the smallest-element groups
of the grouping spectrum. This will ensure
the greatest probability that more direct
bits will be released sooner than later.
The greater the number of direct bits
released sooner will greatly aid in the
success of the control code creation.
Every direct bit released from the grand
pile will have its entry removed from
the direct bit register, since these
direct bits were determined indirectly.
After all the direct bits have been
released from the grand pile the number
of entries in the register should equal
the number of direct bit needed in
Buffer(B).

Remember that each direct bit listed in
the register should release on average
about 0.6 bits from the grand pile.
The number of direct bits released by
each entry of the register should
be anywhere from zero to three.

There may happen to be times when an
inter-grouping substitution may be
to an advantage. For instance, when
two different elements share in two
different groupings.

-------------------

On further reflection of the algorithm:

The system could possibly be reset by
a simple bit-shift in the "FULL"
buffer(B). The first bit becomes the
last in the buffer and the second
bit becomes the first, etc.
The use of this techniques can also
be flaged using the six control bits
in the empty buffer in the subsequent
compression interation. Or of course,
specific instructions on how to
change buffer(B) to continue the
decompression interations can be
compressed as regular "fresh" data.

Even if one or two iterations can only
be achieved per control-code cycle
the evidence of random-iterative-
compression is proven.

One must accept the workings of the
magical "Black Box" if it is proven
to work on a macroscopic level.
If it works it works.
Don't claim that it can work because
you can't understand WHY it works.

One can easily see there is wide
latitute in the options available
to this algorithm.


Erik T. Evenson.
Paul Sc.

2004-05-12, 9:28 pm

>>> One can easily see there is wide latitute in the options available to
this algorithm.

Actually, there are exactly zero options available. There is a difference
between wishful thinking and mathematical reasoning.


Paul



"Plato777" <evenuscinatus@yahoo.com> wrote in message
news:39cccbf4.0404280602.7aa02a9b@posting.google.com...
> evenuscinatus@yahoo.com (Plato777) wrote in message

news:<39cccbf4.0404240700.58efedd6@posting.google.com>...
>
> Here is some info on how I am approaching the
> creation of the control codes.
>
> Once the groups are formed in the three piles
> the piles are mixed into a grand pile and the
> all the groupings are then indexed based on the
> number of elements. The groupings are further
> sub-indexed based on the locations--which
> grouping order they belong--of each of
> the three unique elements (same elements but
> in different piles--same label location
> pointer)within the Grand pile.
>
> A register is created listing all the bit
> positions of Buffer(A). The order of the
> elements of this register is determined from
> the Indexing of the Grand Pile.
> This organizing will in effect "stack the deck"
> in favor in determining which of the bits
> in buffer(A)will be directly represented
> in buffer(B).
> The first entry on the register represents
> when used as a direct bit in buffer(B) the
> greatest liklihood that the groupings that
> include that bit in its set of elements will
> be located near the smallest-element groups
> of the grouping spectrum. This will ensure
> the greatest probability that more direct
> bits will be released sooner than later.
> The greater the number of direct bits
> released sooner will greatly aid in the
> success of the control code creation.
> Every direct bit released from the grand
> pile will have its entry removed from
> the direct bit register, since these
> direct bits were determined indirectly.
> After all the direct bits have been
> released from the grand pile the number
> of entries in the register should equal
> the number of direct bit needed in
> Buffer(B).
>
> Remember that each direct bit listed in
> the register should release on average
> about 0.6 bits from the grand pile.
> The number of direct bits released by
> each entry of the register should
> be anywhere from zero to three.
>
> There may happen to be times when an
> inter-grouping substitution may be
> to an advantage. For instance, when
> two different elements share in two
> different groupings.
>
> -------------------
>
> On further reflection of the algorithm:
>
> The system could possibly be reset by
> a simple bit-shift in the "FULL"
> buffer(B). The first bit becomes the
> last in the buffer and the second
> bit becomes the first, etc.
> The use of this techniques can also
> be flaged using the six control bits
> in the empty buffer in the subsequent
> compression interation. Or of course,
> specific instructions on how to
> change buffer(B) to continue the
> decompression interations can be
> compressed as regular "fresh" data.
>
> Even if one or two iterations can only
> be achieved per control-code cycle
> the evidence of random-iterative-
> compression is proven.
>
> One must accept the workings of the
> magical "Black Box" if it is proven
> to work on a macroscopic level.
> If it works it works.
> Don't claim that it can work because
> you can't understand WHY it works.
>
> One can easily see there is wide
> latitute in the options available
> to this algorithm.
>
>
> Erik T. Evenson.



Plato777

2004-05-12, 9:29 pm

"Paul Sc." <paul_sc47@hotmail.com> wrote in message news:<c6q66p$19p0$1@news.wplus.net>...
> this algorithm.
>
> Actually, there are exactly zero options available. There is a difference
> between wishful thinking and mathematical reasoning.
>
>
> Paul


You think that it is impossible to convert a 1048576 bit buffer to
a 1048474 bit buffer and be able to convert back to the original
1048576 buffer using operations only on the bits of the
1048474 bit buffer? The ability of the algorithm to work hinges
on this one mapping and back-mapping to work.


It may be possible for the algorithm to work on
the following buffer sizes with associated empty
buffer sizes.

index buffer(A) size empty bits

12 24576 39
13 53248 42
14 114688 45
15 245760 48
16 524288 51
17 1114112 54

The ability to determine which direct bits
to include in the buffer(B) may be harder
to determine with these lower buffer sizes.
The lower the index implies that the
algorithm works faster since less operations
are needed on the bits.

There may be inefficiencies in the control
codes. The flow of each bit through
successive iterations should be analyzed to
detect problems with recycling. For example
a bit in buffer(A) may map to a certain bit
position in buffer(B) only to be mapped
again to the original bit position. The
bit recycles between the two bit positions
and never reaches an XOR operation. If the
beginning null buffer is all "zero", these
two bits positions are always "zero" no
matter how many iterations have passed.
The above situation represents a recycle
error of degree two. Higher degrees may
occur within the buffer mappings. One
can see that this "error" affects the
efficiency of the system. When these
recycle errors are identified the
grouping bits and direct bits can be
rearranged in mapping buffer(B) in the
control codes.


Erik T. Evenson.
Willem

2004-05-12, 9:29 pm

Plato777 wrote:
) You think that it is impossible to convert a 1048576 bit buffer to
) a 1048474 bit buffer and be able to convert back to the original
) 1048576 buffer using operations only on the bits of the
) 1048474 bit buffer? The ability of the algorithm to work hinges
) on this one mapping and back-mapping to work.

We not only think that, we have proven that to you numerous times, which
you blindly chose to ignore. The proof is very very simple, just count
the number of possible states of the two buffers.

Keep in mind that the larger buffer is equivalent to the smaller buffer
with some (102) extra bits of data added, which means that it must have
more possible states.


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
SuperFly

2004-05-12, 9:29 pm

On 7 May 2004 10:17:47 -0700, evenuscinatus@yahoo.com (Plato777)
wrote:

[snip]

>You think that it is impossible to convert a 1048576 bit buffer to
>a 1048474 bit buffer and be able to convert back to the original
>1048576 buffer using operations only on the bits of the
>1048474 bit buffer? The ability of the algorithm to work hinges
>on this one mapping and back-mapping to work.
>
>
>It may be possible for the algorithm to work on
>the following buffer sizes with associated empty
>buffer sizes.


If you are so sure, why not grab a compiler of choice, build yourself
a prototype coder and test your theory. There is really not much point
in repeatedly posting your imho flawed theory to this newsgroup.

Matt Mahoney

2004-05-12, 9:29 pm

The ongoing threads about universal, recursive or random data compression
remind me of the historical period where tinkerers would design all manner
of elaborate perpetual motion machines. They all looked like they would
work on paper, but when they actually built them, they would invariably
discover some flaw in the design.

The typical developer of these universal compression algorithms is not well
educated in mathematics. It does no good to explain that you cannot
uniquely encode all 2^n bit strings of length n using the 2^n - 1 strings
shorter than n. They simply will not comprehend your argument or understand
how it applies to their work.

There have been many spectacular failures - Web designs, Minc, Zeosync. I
don't believe these all started off as attempts to deceive investors. I
think the developers of these algorithms genuinely believed that they would
work if they could just get all the bugs worked out of them. Some, like
Jules Gilbert (see
http://www.faqs.org/faqs/compressio.../section-8.html ) have
invested the last decade of their lives toward this goal. You won't
convince them with a simple proof that it was all for nothing.

-- Matt Mahoney



Paul Sc.

2004-05-12, 9:29 pm

> You think that it is impossible to convert a 1048576 bit buffer to
> a 1048474 bit buffer and be able to convert back to the original
> 1048576 buffer using operations only on the bits of the
> 1048474 bit buffer? The ability of the algorithm to work hinges
> on this one mapping and back-mapping to work.


Yes, I do believe that a one-to-one mapping between a 1048576 bit buffer and
a 1048474 bit buffer is mathematically impossible. A one-to-one mapping
means that for each state of the 1048576 bit buffer you associate one and
exactly one state of the 1048474 bit buffer. There are 2 ^ 1048576 states of
the first buffer, and 2 ^ 1048474 states in the second buffer. Correct?

So, let's assume that there is a one-to-one mapping between these states as
you claim.
- This simply means that 2 ^ 1048576 = 2 ^ 1048474.
- Therefore 1048576 = 1048474 (if we take the discrete logarithm of base 2).
- Therefore 102 = 1048576 - 1048474 = 1048474 - 1048474 = 0 (if we subtract
1048474).
- Therefore 102 = 0. If we divide by 102, we get exactly 1 = 0.

To conclude, if your algorithm is correct, then 1 = 0 and there is no
mathematics. If mathematics is wrong then you algorithm is also wrong
anyway. In conclusion your algorithm is wrong regardless how you view it.

I guess you have serious trouble understanding this proof, right?


> It may be possible for the algorithm to work on
> the following buffer sizes with associated empty
> buffer sizes.


"It may be possible..." - this is wishful thinking.

>
> index buffer(A) size empty bits
>
> 12 24576 39
> 13 53248 42
> 14 114688 45
> 15 245760 48
> 16 524288 51
> 17 1114112 54
>
> The ability to determine which direct bits
> to include in the buffer(B) may be harder
> to determine with these lower buffer sizes.
> The lower the index implies that the
> algorithm works faster since .... [irrelevant blurb deleted]


Please note that "Harder" in this context means "impossible". This is again
wishful thinking. You WISH to give the impression that you have an algorihtm
but you IGNORE the fact that there is no such algorithm.

Every highschool student should get a homework which looks like this: Please
proof that NO MATTER what approach you choose, you CANNOT build a one-to-one
mapping between two finite sets that have different number of elements. What
would your homework look like?






Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com