Home > Archive > Compression > June 2004 > a peek under the hood of an actual perpetual-motion machine, well, a perpetual compre
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 |
a peek under the hood of an actual perpetual-motion machine, well, a perpetual compre
|
|
| Jules Gilbert 2004-06-25, 6:57 pm |
| NOTE TO EARL: If you are going to quote me, please take care to get
it right. Quote what follows in full paragraphs and we won't have any
problems:
This note is intended not for the Earl's here, but for the people who
have remained quiet, maybe skeptical, maybe even  at seeing this
constant fighting. (Don't blame me, I don't like what's happening one
bit. And I'm the only person who has been seriously and irreperably
harmed.)
So tonight I am writing to each of you... The quiet ones. I intended
some w s ago to fully disclose but this ongoing nonsense has caused
me to alter my direction.
Here, I am going to review what I have. In fact, I am going to
provide some mathematical substance. And while I have to leave out
enough to prevent some smart person from re-inventing my method, here
is a basic description of the limits of the method. Most of the
mathematically inclined people here will recognize the formula; in
fact all I've done is to adapt it to the 'machine' I have programmed.
(I would count it a personal favor from those of you who recognize the
formula if you don't share the underlying derivation publicly.) If
someone want's to discuss the discussion that follows, email me, see
my last three paragraphs.
Consider a list of random values. Let's agree we have to deliver the
contents to a remote location keeping the order of the values
unchanged when delivered.
First we want to ascertain whether we can predict future values of a
subset of this list, ie., given a left-most subset, can we (at least
partially) predict the rightmost values? Remember, we can be clever.
For instance, we can accept the cost of sending alternating elements
if we can thereby predict the remaining elements (this is not a
realistic scenario of course.) But the concept is critical. We want
to estimate the stationary-ness of the list. Is the list stationary?,
or does the list drift. Notice that a compression agent can use drift
to advantage. For example, if the drift increases from left to right,
we should send from right to left. Decreasing drift means lower
variance, which means better performance for a compressor, especially
if 'ir' expects a decreasing variance. And we can perform this step
recursively, AND this approach change doesn't cost exactly as much as
we gain (whereas most other techniques we could evaluate cost at least
as much as the gain obtained.)
We can write:
Y[i] := a + Y[i-1] + B*t + e(t)
where 'i' is an index, as the data is organized after processing and
't' is the list index at the send point. 'a' is the log of an offset
constant, 'B' is the log of the drift, and 'e' is the error function,
and should be considered to be the residual error of the process and
the end of each step. (Where a 'step' is a single process iteration.)
By making the list the entire file contents, each e(t) becomes
successively smaller buffer values which are designated to be sent
with each subsequent pass.
The above doesn't predict anything, it only characterizes the
differences in list values, measured at the point of reception.
Key point coming:
If we allow our 'container' (picky? call it a channel), to be smaller
than Shannel requires we can use the above drift equation to model the
information loss, and the next equation to model the information
transfer:
So now, the change in Y[i] can be expressed as:
(Y[i+1] - Y[i]) = a + (p - 1) * Y[i] + B*t + e(t).
To do this, we have to introduce a new value, 'p'. Unfortunately, all
I can safely tell you is that this value represents probability. More
than this I can not discuss. Oh yes, I can say that when the data is
bit-based (ie., not floating point,) the log2 of a multiple of 'p' is
proportional to the log2 of the next value of 'p', thus upper
bounding the magnitude of the instantanous error of e(t).
(By instantaneous error, I mean the actual value of an element
compared to the 'sent' value for that pass.)
The expression (Y[i+1] - Y[i]) is simply the change in value from one
list element to another. If I had a richer medium, I'd write a delta
followed by a 'y'.
A couple more things...
First, the process seems to improve (remember, each iteration is
delivered via "e(t)") faster than the square root of each iteration --
and this is the only communications formula I have ever observed for
which this is true.
Second, we are not talking floating point values here. This process
is purely integer based. In fact, the computation described uses
values that are log2 based.
EARL: as to my claims, I know I've never claimed to do the
mathematically impossible, in fact if it were impossible,
mathematically or otherwise -- I couldn't do it. Of course it is true
that I do say that my method is completely unlike other compression
methods, because it does not work by removing redundant text, but by
reproducing the input at the output point and it is not principally a
method for minimizing data prior to transfer WHICH ALL OTHER METHODS
ARE (at least, those I know about.)
How? that would be telling, and one thing for sure; any deal I make
will be structured to avoid the method becoming known to you and a few
others I've met on these pages. 'You' (here I mean not just you, but
several others as well,) may be aggravated with me for being so
proprietary and not sharing. But how do you think I feel about you.
Review what you've said about me.
One thing though, maybe others besides myself are researcher's; I can
believe that very easily. But the more vocal 'voices' I've seen here,
why no I don't think so...
I will be happy to correspond with students of all varieties and
descriptions. Also, people employed in the United States working in
an engineering capacity who are manager's or senior project leaders
involved in communications and/or compression issues.
My email is: julesg@financier.com (I also manage a stock predictions
community -- and everyday this method is used as part of a system
which predicts the price of 2500 large/most active US traded stocks.)
Check some past notes here, and check my predictions. (Better yet, ask
me for my notes.)
My prices are consistently accurate too. (Prediction is a science
quite closely related to compression.)
| |
| Dr Chaos 2004-06-25, 6:57 pm |
| On 20 Jun 2004 21:51:09 -0700, Jules Gilbert <julesg@financier.com> wrote:
> So now, the change in Y[i] can be expressed as:
>
> (Y[i+1] - Y[i]) = a + (p - 1) * Y[i] + B*t + e(t).
>
> To do this, we have to introduce a new value, 'p'. Unfortunately, all
> I can safely tell you is that this value represents probability. More
> than this I can not discuss. Oh yes, I can say that when the data is
> bit-based (ie., not floating point,) the log2 of a multiple of 'p' is
> proportional to the log2 of the next value of 'p', thus upper
>
> EARL: as to my claims, I know I've never claimed to do the
> mathematically impossible, in fact if it were impossible,
> mathematically or otherwise -- I couldn't do it. Of course it is true
> that I do say that my method is completely unlike other compression
> methods, because it does not work by removing redundant text, but by
> reproducing the input at the output point and it is not principally a
> method for minimizing data prior to transfer WHICH ALL OTHER METHODS
> ARE (at least, those I know about.)
Well, they aren't.
You described adaptive predictive sequential compression. It isn't
the technology of Lempel-Ziv string matching methods but it is the
technology of all the Markov-based modeling such as PPM et cetera.
The idea is all the same: given a model class, and stream of 'errors',
reproduce the input data, at the output device.
Jorma Rissanen (_Stochastic Complexity in Statistical Inquiry_, or Li
& Vitanyi, Introduction to Kolmogorov Complexity) describes
significant generalizations of this, in particular in attention to the
use in statistical model selection. The important point is that for
the compressor to be causally reversible the estimates of the
parameters have to be constructible given *only* the previously
decompressed data---or on the compression end, previously observed
data. (one-part sequential codes) Or, you need a prior on the
parameter values (which costs bits), so you transmit the peculiar
values and then the errors of data modeled by the predictor.
It is a general and powerful technique but it doesn't violate Shannon,
and the principles are now standard in compression research.
In fact Rissanen's theory can be seen as a generalization of the Shannon
coding theorems encompassing model classes rather than just _a priori_
probability distributions assumed to be true. Rissanen's theory
discusses the structure of the parameteric redundancy.
> My email is: julesg@financier.com (I also manage a stock predictions
> community -- and everyday this method is used as part of a system
> which predicts the price of 2500 large/most active US traded stocks.)
> Check some past notes here, and check my predictions. (Better yet, ask
> me for my notes.)
>
> My prices are consistently accurate too. (Prediction is a science
> quite closely related to compression.)
That it is indeed. Using compression-based metrics for validating
models without overfitting is a valuable and legitimate pursuit.
The related "Bayes factor" modeling methods (the integral form
of Rissanen's stochastic complexity is formally identical) are good too.
Nevertheless, truly i.i.d. data can't be compressed.
| |
| Jules Gilbert 2004-06-25, 6:57 pm |
| I didn't know about Rissanen, but you are characterizing my formula in
terms of what you know. Don't. I understand that you are exceedingly
skeptical -- and I know I have not tried to satisfy your curious
nature. BUT!, while I have experimented with methods that work based
on sending a generalized expectation of what's ahead, (ala PPM,) this
really is entirely different.
Why? Because I coordinate data pre-existing on the RCVE-side of the
channel with the 'signal' (data to be sent that is initially on the
SEND-side of the channel.)
So MBK, tell us more -- you are not describing my stuff but I am happy
to learn from you. About Rissanen, please...
Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message news:<slrncdcs9a.3la.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>...
> On 20 Jun 2004 21:51:09 -0700, Jules Gilbert <julesg@financier.com> wrote:
>
>
> Well, they aren't.
>
> You described adaptive predictive sequential compression. It isn't
> the technology of Lempel-Ziv string matching methods but it is the
> technology of all the Markov-based modeling such as PPM et cetera.
> The idea is all the same: given a model class, and stream of 'errors',
> reproduce the input data, at the output device.
>
> Jorma Rissanen (_Stochastic Complexity in Statistical Inquiry_, or Li
> & Vitanyi, Introduction to Kolmogorov Complexity) describes
> significant generalizations of this, in particular in attention to the
> use in statistical model selection. The important point is that for
> the compressor to be causally reversible the estimates of the
> parameters have to be constructible given *only* the previously
> decompressed data---or on the compression end, previously observed
> data. (one-part sequential codes) Or, you need a prior on the
> parameter values (which costs bits), so you transmit the peculiar
> values and then the errors of data modeled by the predictor.
>
> It is a general and powerful technique but it doesn't violate Shannon,
> and the principles are now standard in compression research.
>
> In fact Rissanen's theory can be seen as a generalization of the Shannon
> coding theorems encompassing model classes rather than just _a priori_
> probability distributions assumed to be true. Rissanen's theory
> discusses the structure of the parameteric redundancy.
>
>
> That it is indeed. Using compression-based metrics for validating
> models without overfitting is a valuable and legitimate pursuit.
> The related "Bayes factor" modeling methods (the integral form
> of Rissanen's stochastic complexity is formally identical) are good too.
>
> Nevertheless, truly i.i.d. data can't be compressed.
| |
| Matt Mahoney 2004-06-25, 6:57 pm |
| "Jules Gilbert" <julesg@financier.com> wrote in message
news:9c7d0936.0406202051.1c411c6a@posting.google.com...
> (Y[i+1] - Y[i]) = a + (p - 1) * Y[i] + B*t + e(t).
That's fine for predictable data, but still won't work on random data.
Here is a challenge. If you pass, I will accept that you can compress or
predict random data. You don't have to reveal anything about your
algorithm. The challenge is as follows.
1. I generate as much pseudo-random data as you want using sharnd.exe at
http://cs.fit.edu/~mmahoney/compression/#misc using a secret key.
2. You post your prediction of the next 1000 bytes in the sequence.
3. I reveal the key, and thus the actual sequence.
If you guess at least 2% of the bytes correctly, then I will admit that you
can compress random data.
-- Matt Mahoney
| |
| Matt Mahoney 2004-06-25, 6:57 pm |
|
"Matt Mahoney" <matmahoney@yahoo.com> wrote in message
news:fpBBc.8765$bs4.822@newsread3.news.atl.earthlink.net...
> "Jules Gilbert" <julesg@financier.com> wrote in message
> news:9c7d0936.0406202051.1c411c6a@posting.google.com...
>
> That's fine for predictable data, but still won't work on random data.
>
> Here is a challenge. If you pass, I will accept that you can compress or
> predict random data. You don't have to reveal anything about your
> algorithm. The challenge is as follows.
>
> 1. I generate as much pseudo-random data as you want using sharnd.exe at
> http://cs.fit.edu/~mmahoney/compression/#misc using a secret key.
>
> 2. You post your prediction of the next 1000 bytes in the sequence.
>
> 3. I reveal the key, and thus the actual sequence.
>
> If you guess at least 2% of the bytes correctly, then I will admit that
you
> can compress random data.
I posted a 100,000 byte file sharnd_challenge.dat at the above URL. If you
need more data, let me know.
-- Matt Mahoney
| |
| Jules Gilbert 2004-06-25, 6:57 pm |
| Sounds pretty fair to me. In fact I only have one or two changes...
First, make it worth my while financially.
Second, let's adopt a test based on numerical proximity.
Work with me wrt the second change and I will work with you wrt the
first change.
I think we can do business on this. While I have been very busy for
the past few ws and have about another month of work before I will
have finished my present project, and then I will put a couple of
machines to work and see what I can come up with.
This could be a lot of fun. I know someone who has posted here in the
past; I'll email you his identity and ask you to accept him as the
decider. Do you agree not to reveal his identity without his
permission (also, I have no idea whether he will accept! He may
decline.)
--jg
"Matt Mahoney" <matmahoney@yahoo.com> wrote in message news:<fpBBc.8765$bs4.822@newsread3.news.atl.earthlink.net>...
> "Jules Gilbert" <julesg@financier.com> wrote in message
> news:9c7d0936.0406202051.1c411c6a@posting.google.com...
>
> That's fine for predictable data, but still won't work on random data.
>
> Here is a challenge. If you pass, I will accept that you can compress or
> predict random data. You don't have to reveal anything about your
> algorithm. The challenge is as follows.
>
> 1. I generate as much pseudo-random data as you want using sharnd.exe at
> http://cs.fit.edu/~mmahoney/compression/#misc using a secret key.
>
> 2. You post your prediction of the next 1000 bytes in the sequence.
>
> 3. I reveal the key, and thus the actual sequence.
>
> If you guess at least 2% of the bytes correctly, then I will admit that you
> can compress random data.
>
> -- Matt Mahoney
| |
| Guenther von Knakspott 2004-06-25, 6:57 pm |
| julesg@financier.com (Jules Gilbert) wrote in message
news:<9c7d0936.0406202051.1c411c6a@posting.google.com>...
> NOTE TO EARL: If you are going to quote me, please take care to get
> it right. Quote what follows in full paragraphs and we won't have
any
> problems:
>
>
> This note is intended not for the Earl's here, but for the people who
> have remained quiet, maybe skeptical, maybe even at seeing this
> constant fighting. (Don't blame me, I don't like what's happening
one
> bit. And I'm the only person who has been seriously and irreperably
> harmed.)
>
> So tonight I am writing to each of you... The quiet ones. I
intended
> some ws ago to fully disclose but this ongoing nonsense has caused
> me to alter my direction.
>
> Here, I am going to review what I have. In fact, I am going to
> provide some mathematical substance. And while I have to leave out
> enough to prevent some smart person from re-inventing my method, here
> is a basic description of the limits of the method. Most of the
> mathematically inclined people here will recognize the formula; in
> fact all I've done is to adapt it to the 'machine' I have
programmed.
>
> (I would count it a personal favor from those of you who recognize
the
> formula if you don't share the underlying derivation publicly.) If
> someone want's to discuss the discussion that follows, email me, see
> my last three paragraphs.
Say Gilbert, won't you please stop making an ass of yourself in front
of everybody? People are really feeling embarassed on your account. By
now it has become quite obvious that you cannot cope with the fact
that no one here believes your claims. Paradoxically you refuse to
offer any proof of their veracity. You need to realise that you will
never be able to prove your claims. Not because of animosity towards
your person, but because you are claiming impossibilities. But even
apart from this, your attitude is ridiculous. Lately, you have started
to request financial remuneration in exchange for what you believe to
be a proof. Doesn't it strike you as very peculiar to believe that
anyone would be willing to pay You for giving You an opportunity to
prove your delusions? Think of it the other way around: Would you pay
anybody here to prove mathematical fact to you? Obviously not.
[snip void bulshit]
> I will be happy to correspond with students of all varieties and
> descriptions. Also, people employed in the United States working in
> an engineering capacity who are manager's or senior project leaders
> involved in communications and/or compression issues.
>
> My email is: julesg@financier.com (I also manage a stock predictions
> community -- and everyday this method is used as part of a system
> which predicts the price of 2500 large/most active US traded stocks.)
> Check some past notes here, and check my predictions. (Better yet,
ask
> me for my notes.)
>
> My prices are consistently accurate too. (Prediction is a science
> quite closely related to compression.)
Gilbert, shouldn't you be busy making millions at the stock exchange?
Why are you waisting your and our time posting ever more crap and
divesting yourself of any trace of dignity? Face it Gilbert, you don't
have a method for perpetually compressing, because no such method can
possibly exist. And you also have no method for accurately predicting
stock prices, otherwise you wouldn't be whining at everyone to give
you money. My guess is Gilbert, that at some point in your career, you
took a wrong turn. You must have started by hoping you could
effortlessly become rich by comming up with some  compression
algorithm worth millions. After realising the factual limits of what
is possible, you must have started deluding yourself into believing
that somehow you could circumvent those limits. And then, you became
obsessed with this idea, that instead of pursuing really profitable
goals you wasted your time away in a hopeless quest. By now, on
account of your warped perception of things, you have becomed
convinced that you are entitled to something, i.e. people paying you
so you will prove your ravings to them. This is all very  Gilbert
but there is still hope for you, if you will admit to yourself (you
don't need to debase yourself in front of everybody by public
confession) that you were wrong and that you need to get back on
track. This is something that no one can do for you. You should stop
trying to convince others and spend every effort in getting out of the
hole you have manouvered yourself into. Face it Gilbert, there is no
such thing as a free lunch.
regards.
| |
| Dr Chaos 2004-06-25, 6:57 pm |
| On 21 Jun 2004 05:33:18 -0700, Jules Gilbert <julesg@financier.com> wrote:
> I didn't know about Rissanen, but you are characterizing my formula in
> terms of what you know. Don't. I understand that you are exceedingly
> skeptical -- and I know I have not tried to satisfy your curious
> nature. BUT!, while I have experimented with methods that work based
> on sending a generalized expectation of what's ahead, (ala PPM,) this
> really is entirely different.
>
> Why? Because I coordinate data pre-existing on the RCVE-side of the
> channel with the 'signal' (data to be sent that is initially on the
> SEND-side of the channel.)
I don't know what that means. If you need to "coordinate" something
that the receiver didn't know before, and it depends on the data set
to be transmitted, then that costs bits, somewhere somehow.
PPM is purely sequential (as opposed to two-part, describing the
specific model and then data coded relative to that model) I believe,
but you can have (and I have made) hybrid codes where some structural
elements are transmitted first, and then other parameters are learned
on-line (sequentially).
question: is your compressor universal or not?
> So MBK, tell us more -- you are not describing my stuff but I am happy
> to learn from you. About Rissanen, please...
Jorma Rissanen, IBM. One of the inventors of practical arithmetic coding,
but that's fairly minor in the scheme of things.
You have to read the book, there's no way around it. It's not easy at
first, but there's alot of interesting stuff in there.
It is a major theme in modern statistical and engineering applications. Look
up "minimum description length principle", his biggest claim to fame,
though often people's application of it use the most simplistic (and sometimes
erroneous) version.
MDL is often a more principled and more general model selection
criterion than some other ones sometimes used (Aikake information
criterion? Schwartz information criterion?)
[color=darkred]
> Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message news:<slrncdcs9a.3la.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>...
| |
|
|
"Marco Al" <m.f.al@student.utwente.nl> wrote in message
news:cb7cva$5fk$1@netlx020.civ.utwente.nl...
> Jules Gilbert wrote:
>
>
> You have said you would leave the newsgroup. Why do you always lie? :(
Oh think how boring this newsgroup could be without a few Gilberts. I for
one am glad he and his types are around.
| |
| Paul Sc. 2004-06-25, 6:57 pm |
| Hi Jules,
You are assuming here a sequential information model. In other words
your approach assumes that the data is organized in a sequence of
chunks of data. Each chunk of data (a sequence of bits of a certain
size not necessarily fixed - say Y[i] in your terms) is somehow
related to some previous ones. If this is true, then yes, you can do
some sort of prediction to compress things.
But this is a pretty limited approach, when the relation between these
chunks of data are more complex to be expressed in a simple equation
like Y[i] = f(Y[i-1], Y[i-2], ... Y[i-k_i]) in other words the chunk
index i depends on the last k_i chunks. In this model the prediction
algorithm breaks down.
Still, of course compression is still possible but you have to look to
a more deep structural relation between elements. For example, take an
XML file which has a certain structure assuming XML conformance, and
possibly a validation to a certain schema. A prediction-based
compression algorithm will have no way to figure out that every
opening XML element (in the form <test> ) is paired witn an end element
of hteform </element>. Having this figured out, it would be able to do
a little more compression and associate a dictionary with all the
element names.
I can build a more complicated example, anyway, the general idea here
is that a prediction-based compression algorithm is applicable only in
a particular area. And it certainly cannot be used for perpetual
compression.
Thanks, Paul
julesg@financier.com (Jules Gilbert) wrote in message news:<9c7d0936.0406202051.1c411c6a@posting.google.com>...[color=darkred]
> NOTE TO EARL: If you are going to quote me, please take care to get
> it right. Quote what follows in full paragraphs and we won't have any
> problems:
>
>
> This note is intended not for the Earl's here, but for the people who
> have remained quiet, maybe skeptical, maybe even at seeing this
> constant fighting. (Don't blame me, I don't like what's happening one
> bit. And I'm the only person who has been seriously and irreperably
> harmed.)
>
> So tonight I am writing to each of you... The quiet ones. I intended
> some ws ago to fully disclose but this ongoing nonsense has caused
> me to alter my direction.
>
> Here, I am going to review what I have. In fact, I am going to
> provide some mathematical substance. And while I have to leave out
> enough to prevent some smart person from re-inventing my method, here
> is a basic description of the limits of the method. Most of the
> mathematically inclined people here will recognize the formula; in
> fact all I've done is to adapt it to the 'machine' I have programmed.
>
> (I would count it a personal favor from those of you who recognize the
> formula if you don't share the underlying derivation publicly.) If
> someone want's to discuss the discussion that follows, email me, see
> my last three paragraphs.
>
>
> Consider a list of random values. Let's agree we have to deliver the
> contents to a remote location keeping the order of the values
> unchanged when delivered.
>
> First we want to ascertain whether we can predict future values of a
> subset of this list, ie., given a left-most subset, can we (at least
> partially) predict the rightmost values? Remember, we can be clever.
> For instance, we can accept the cost of sending alternating elements
> if we can thereby predict the remaining elements (this is not a
> realistic scenario of course.) But the concept is critical. We want
> to estimate the stationary-ness of the list. Is the list stationary?,
> or does the list drift. Notice that a compression agent can use drift
> to advantage. For example, if the drift increases from left to right,
> we should send from right to left. Decreasing drift means lower
> variance, which means better performance for a compressor, especially
> if 'ir' expects a decreasing variance. And we can perform this step
> recursively, AND this approach change doesn't cost exactly as much as
> we gain (whereas most other techniques we could evaluate cost at least
> as much as the gain obtained.)
>
> We can write:
>
> Y[i] := a + Y[i-1] + B*t + e(t)
>
> where 'i' is an index, as the data is organized after processing and
> 't' is the list index at the send point. 'a' is the log of an offset
> constant, 'B' is the log of the drift, and 'e' is the error function,
> and should be considered to be the residual error of the process and
> the end of each step. (Where a 'step' is a single process iteration.)
>
> By making the list the entire file contents, each e(t) becomes
> successively smaller buffer values which are designated to be sent
> with each subsequent pass.
>
> The above doesn't predict anything, it only characterizes the
> differences in list values, measured at the point of reception.
>
>
> Key point coming:
>
> If we allow our 'container' (picky? call it a channel), to be smaller
> than Shannel requires we can use the above drift equation to model the
> information loss, and the next equation to model the information
> transfer:
>
> So now, the change in Y[i] can be expressed as:
>
> (Y[i+1] - Y[i]) = a + (p - 1) * Y[i] + B*t + e(t).
>
> To do this, we have to introduce a new value, 'p'. Unfortunately, all
> I can safely tell you is that this value represents probability. More
> than this I can not discuss. Oh yes, I can say that when the data is
> bit-based (ie., not floating point,) the log2 of a multiple of 'p' is
> proportional to the log2 of the next value of 'p', thus upper
> bounding the magnitude of the instantanous error of e(t).
>
> (By instantaneous error, I mean the actual value of an element
> compared to the 'sent' value for that pass.)
>
> The expression (Y[i+1] - Y[i]) is simply the change in value from one
> list element to another. If I had a richer medium, I'd write a delta
> followed by a 'y'.
>
> A couple more things...
>
> First, the process seems to improve (remember, each iteration is
> delivered via "e(t)") faster than the square root of each iteration --
> and this is the only communications formula I have ever observed for
> which this is true.
>
> Second, we are not talking floating point values here. This process
> is purely integer based. In fact, the computation described uses
> values that are log2 based.
>
> EARL: as to my claims, I know I've never claimed to do the
> mathematically impossible, in fact if it were impossible,
> mathematically or otherwise -- I couldn't do it. Of course it is true
> that I do say that my method is completely unlike other compression
> methods, because it does not work by removing redundant text, but by
> reproducing the input at the output point and it is not principally a
> method for minimizing data prior to transfer WHICH ALL OTHER METHODS
> ARE (at least, those I know about.)
>
> How? that would be telling, and one thing for sure; any deal I make
> will be structured to avoid the method becoming known to you and a few
> others I've met on these pages. 'You' (here I mean not just you, but
> several others as well,) may be aggravated with me for being so
> proprietary and not sharing. But how do you think I feel about you.
> Review what you've said about me.
>
> One thing though, maybe others besides myself are researcher's; I can
> believe that very easily. But the more vocal 'voices' I've seen here,
> why no I don't think so...
>
> I will be happy to correspond with students of all varieties and
> descriptions. Also, people employed in the United States working in
> an engineering capacity who are manager's or senior project leaders
> involved in communications and/or compression issues.
>
> My email is: julesg@financier.com (I also manage a stock predictions
> community -- and everyday this method is used as part of a system
> which predicts the price of 2500 large/most active US traded stocks.)
> Check some past notes here, and check my predictions. (Better yet, ask
> me for my notes.)
>
> My prices are consistently accurate too. (Prediction is a science
> quite closely related to compression.)
| |
| Earl Colby Pottinger 2004-06-25, 6:57 pm |
| guenther.vonKnakspott@gmx.de (Guenther von Knakspott) :
> julesg@financier.com (Jules Gilbert) wrote in message
>
> news:<9c7d0936.0406202051.1c411c6a@posting.google.com>...
> any problems:
When have I ever misquoted you? And no I refuse to quote you in paragraphs
only if I find individual sentences inside a paragraph are wrong. I will
still quote the single sentences and what are wrong with them. Tough to be
you, but you are the one who has said on more than once that you were going
posting here, and yet you keep coming back. Honestly Jules, if you don't
like it here just stop coming here. No-one is forcing you to.
Earl Colby Pottinger
--
I make public email sent to me! Hydrogen Peroxide Rockets, OpenBeos,
SerialTransfer 3.0, RAMDISK, BoatBuilding, DIY TabletPC. What happened to
the time? http://webhome.idirect.com/~earlcp
| |
| Dr Chaos 2004-06-25, 6:57 pm |
| On 22 Jun 2004 00:22:01 -0700, Paul Sc. <Paul_Sc47@hotmail.com> wrote:
> Still, of course compression is still possible but you have to look to
> a more deep structural relation between elements. For example, take an
> XML file which has a certain structure assuming XML conformance, and
> possibly a validation to a certain schema. A prediction-based
> compression algorithm will have no way to figure out that every
> opening XML element (in the form <test> ) is paired witn an end element
> of hteform </element>. Having this figured out, it would be able to do
> a little more compression and associate a dictionary with all the
> element names.
Actually prediction approaches estimate a conditional probability,
not just a predicted value. So the conditional probability of
</element> in a good model would be raised having seen <test>.
My own experience is that sequential updating is good for
re-estimating continuous parameters, where the alternative Bayesian or
stochastic complexity formulations would involve rather difficult
integrals.
With 'discrete' parameters, then the priors are more obvious and often
structure can be explicitly coded fairly well.
| |
| SuperFly 2004-06-25, 6:57 pm |
| On 21 Jun 2004 05:33:18 -0700, julesg@financier.com (Jules Gilbert)
wrote:
[snip]
>Why? Because I coordinate data pre-existing on the RCVE-side of the
>channel with the 'signal' (data to be sent that is initially on the
>SEND-side of the channel.)
Looks to me like you are forgetting to send information over this
channel, and are using it as a side-channel. Keep in mind that you
also need either a character or a stop marker for the no-information
state. You can't just skip those. Not if you want a key that can
(always) recreate the original file ..
[snip]
|
|
|
|
|