Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compression > #1339 > unrolled thread

this is Jules Gilbert

Back to article view | Back to comp.compression

Contents

  this is Jules Gilbert repeatable_compression@yahoo.com - 2012-06-15 03:59 -0700
    Re: this is Jules Gilbert repeatable_compression@yahoo.com - 2012-06-15 04:01 -0700
      Re: this is Jules Gilbert Jim Leonard <mobygamer@gmail.com> - 2012-06-20 12:31 -0700
        Re: this is Jules Gilbert Earl_Colby_Pottinger <earlcolby.pottinger@sympatico.ca> - 2012-06-20 13:31 -0700
        Re: this is Jules Gilbert oh_henry_oh <henry.olyer@gmail.com> - 2012-06-30 02:23 -0700
          Re: this is Jules Gilbert Jim Leonard <mobygamer@gmail.com> - 2012-07-02 12:13 -0700
    Re: this is Jules Gilbert Noob <root@127.0.0.1> - 2012-06-15 13:06 +0200
    Re: this is Jules Gilbert Kelsey Bjarnason <kbjarnason@gmail.com> - 2012-06-22 10:19 -0700
    Re: this is Jules Gilbert Fibonacci Code <anglikai@gmail.com> - 2012-06-24 09:57 -0700
      Re: this is Jules Gilbert Stephen Wolstenholme <steve@npsl1.com> - 2012-06-24 18:08 +0100
    Re: this is Jules Gilbert oh_henry_oh <henry.olyer@gmail.com> - 2012-06-30 02:31 -0700
      Re: this is Jules Gilbert SG <s.gesemann@gmail.com> - 2012-07-03 04:19 -0700
        Re: this is Jules Gilbert oh_henry_oh <henry.olyer@gmail.com> - 2012-07-13 20:47 -0700
          Re: this is Jules Gilbert SG <s.gesemann@gmail.com> - 2012-07-15 03:13 -0700

#1339 — this is Jules Gilbert

What is this nonsense people say, that a well compressed file can not
be recompressed!, foolishness.

In fact, people who follow my work know that all files can be
compressed down to about 3k bytes.  Ans sure they can be made smaller,
but the characteristic performance suffers.  A file of say 415k (such
as MN's test file,) first pass, is reduced by more than 4%.  (I agree,
that's not a lot, the thing is, IT'S FAST.)

But when it's dropped to around 3k, the compression performance is
down too, to about 0.5%, maybe .6% or even 1%, it varies.

But none of this is important, what's important are some of the
applications that are possible.

Has anyone a clue to what I'm referring to.

Oh, and about my program.  I'm looking for a buyer.  (Which is why I
feel a little like Diogenes...)

[toc] | [next] | [standalone]

#1340

On Jun 15, 6:59 am, repeatable_compress...@yahoo.com wrote:
> What is this nonsense people say, that a well compressed file can not
> be recompressed!, foolishness.
>
> In fact, people who follow my work know that all files can be
> compressed down to about 3k bytes.  Ans sure they can be made smaller,
> but the characteristic performance suffers.  A file of say 415k (such
> as MN's test file,) first pass, is reduced by more than 4%.  (I agree,
> that's not a lot, the thing is, IT'S FAST.)
>
> But when it's dropped to around 3k, the compression performance is
> down too, to about 0.5%, maybe .6% or even 1%, it varies.
>
> But none of this is important, what's important are some of the
> applications that are possible.
>
> Has anyone a clue to what I'm referring to.
>
> Oh, and about my program.  I'm looking for a buyer.  (Which is why I
> feel a little like Diogenes...)

Oh, I forgot.  The total elapsed time on a 3Ghz machine is about 1sec,
to go from 415k to 3k bytes.

[toc] | [prev] | [next] | [standalone]

#1349

On Jun 15, 6:01 am, repeatable_compress...@yahoo.com wrote:
> Oh, I forgot.  The total elapsed time on a 3Ghz machine is about 1sec,
> to go from 415k to 3k bytes.

How long does it take to reverse the process (ie. decompress the file)?

[toc] | [prev] | [next] | [standalone]

#1350

> On Jun 15, 6:01 am, repeatable_compress...@yahoo.com wrote:

> How long does it take to reverse the process (ie. decompress the file)?

Come on, you know he can't give a honest answer to that question.

[toc] | [prev] | [next] | [standalone]

#1374

On Jun 20, 3:31 pm, Jim Leonard <mobyga...@gmail.com> wrote:
> On Jun 15, 6:01 am, repeatable_compress...@yahoo.com wrote:
>
> > Oh, I forgot.  The total elapsed time on a 3Ghz machine is about 1sec,
> > to go from 415k to 3k bytes.
>
> How long does it take to reverse the process (ie. decompress the file)?


Hello Jim:

My method is based on a transform (yes, a lossless and reversible
transform,) that reformats and processes random data in such a way so
as to make it compressible.  The real limitation isn't in my
transform, it depends on the compressor/decompressor.

And although I've looked at other compressor's, I prefer zlib because
it's so fast, compared to other system's.  Make no mistake, the bz2
data compression library is very cool!, both zlib and bz2 are,
frankly, exceptional programs.

I have problems on my end, not technical problems  I know, you guys
think that because I don't show it, that I don't have it.  Well I do.
I have investors who are not prepared for me to change.  (I've been
trying.)   And to be sure, the US (here I speak of the PTO and the
judiciary,) doesn't have the capacity support and protect my "right"
to license my program and method.

Seeing how things work, well, unless I can arrange a buy-out, I don't
expect to license my program in the US.  Because the moment I did the
method would be slightly modified and used by industry (and, I assume,
many free-software advocates,) or simply used as is, and I would hear
"So, sue me!" over and over again.

My basic technical claim is this:  I have developed a reversible and
lossless transformation;  That can convert a list of random values
(ie,, a buffer,) such that a random buffer can be made to be non-
random, compressed, subsequently decompressed, and re-converted back
to random-appearing data when convenient.

Their are limits of course.  These limits relate to how the compressor
works, is it huffman based or arithmetic?, (these are all I've looked
at.)  With zlib I can take several GB's and produce a file, that can
be decompressed, of about 5k bytes.

For my email, use:

repeatable
underscore
compression
[reverse the ta character]
yahoo
dot
com

[toc] | [prev] | [next] | [standalone]

#1388

On Jun 30, 4:23 am, oh_henry_oh <henry.ol...@gmail.com> wrote:
> My method is based on a transform (yes, a lossless and reversible
> transform,) that reformats and processes random data in such a way so
> as to make it compressible.  The real limitation isn't in my
> transform, it depends on the compressor/decompressor.

What is the largest file you have successfully decompressed with this
method?  (By "successfully", I mean the decompressed file has exactly
the same content byte-for-byte with the original input file.)

[toc] | [prev] | [next] | [standalone]

#1341

repeatable_compression@yahoo.com wrote:

> What is this nonsense people say, that a well compressed file can not
> be recompressed!, foolishness.

Right...

Can you please stop trying to evade my bit bucket?

[toc] | [prev] | [next] | [standalone]

#1352

On Fri, 15 Jun 2012 03:59:10 -0700, repeatable_compression wrote:

> What is this nonsense people say, that a well compressed file can not be
> recompressed!, foolishness.
> 
> In fact, people who follow my work know that all files can be compressed
> down to about 3k bytes.  Ans sure they can be made smaller,
> but the characteristic performance suffers.  A file of say 415k (such as
> MN's test file,) first pass, is reduced by more than 4%.  (I agree,
> that's not a lot, the thing is, IT'S FAST.)
> 
> But when it's dropped to around 3k, the compression performance is down
> too, to about 0.5%, maybe .6% or even 1%, it varies.
> 
> But none of this is important, what's important are some of the
> applications that are possible.
> 
> Has anyone a clue to what I'm referring to.

Your apparent inability to do basic math?

[toc] | [prev] | [next] | [standalone]

#1359

If you are using AI neural network of any kind, make sure that the Neural Network synapse itself is saved too. The output is useless without the network, because without the network, you cannot reverse it.

--Fibonacci code

[toc] | [prev] | [next] | [standalone]

#1360

On Sun, 24 Jun 2012 09:57:45 -0700 (PDT), Fibonacci Code
<anglikai@gmail.com> wrote:

>If you are using AI neural network of any kind, make sure that the Neural Network synapse itself is saved too. The output is useless without the network, because without the network, you cannot reverse it.
>
>--Fibonacci code

That's not true. The synapse only exists for a finite time period and
it does not need to be saved. The connections on either side of the
synapse need to be saved.

Steve

-- 
Neural Network Software.                     http://www.npsl1.com
EasyNN-plus. Neural Networks plus.           http://www.easynn.com
SwingNN.     Forecast with Neural Networks.  http://www.swingnn.com
JustNN.      Just Neural Networks.           http://www.justnn.com

[toc] | [prev] | [next] | [standalone]

#1375

On Jun 15, 6:59 am, repeatable_compress...@yahoo.com wrote:
> What is this nonsense people say, that a well compressed file can not
> be recompressed!, foolishness.
>
> In fact, people who follow my work know that all files can be
> compressed down to about 3k bytes.  Ans sure they can be made smaller,
> but the characteristic performance suffers.  A file of say 415k (such
> as MN's test file,) first pass, is reduced by more than 4%.  (I agree,
> that's not a lot, the thing is, IT'S FAST.)
>
> But when it's dropped to around 3k, the compression performance is
> down too, to about 0.5%, maybe .6% or even 1%, it varies.
>
> But none of this is important, what's important are some of the
> applications that are possible.
>
> Has anyone a clue to what I'm referring to.
>
> Oh, and about my program.  I'm looking for a buyer.  (Which is why I
> feel a little like Diogenes...)

About this remark.  I'm experimenting with an application that is
outside the IT community.  It has to do with sending messages in a
very unconventional manner.  So far, all communicating, as well as all
data processing requires change at the physical level.  Quite
accidentally, experimenting with random compression, I may have
something else.

A few of you know I use state tools and genetics to look at what's
feasible.  Well, I found something.  (Or, if you like, one of my
computers did...)

[toc] | [prev] | [next] | [standalone]

#1391

On Jun 30, 11:23 am, oh_henry_oh wrote:
> [...]
> My basic technical claim is this:  I have developed a reversible and
> lossless transformation; That can convert a list of random values
> (ie,, a buffer,) such that a random buffer can be made to be non-
> random, compressed, subsequently decompressed, and re-converted back
> to random-appearing data when convenient.

Let us try to express your claim in a more mathematical way:

Basics, terms, definitions:
- your "transform" is a function that maps byte sequences to other
byte sequences, let's call it t
- your function t is injective (otherwise there would be no inverse)
- by compressed and decompressed here you refer to some lossless
general-purpose compressor/decompressor. The compressor is also just a
function that maps byte sequences to other byte sequences. Let's call
it c, By definnition, c is also injective (otherwise it wouldn't be
lossless).
- There is a subset of byte sequences you call "random appearing",
Let's call it R.
- Let's use "len" to refer to a function which counts the number of
bytes in a byte sequence.

Claim ?
Please help me with this. Apparently, you think that t and c have some
nice properties. What properties are those besides injectivity? If I
understand you right, you are "claiming":

  len(c(t(x))) < len(x)   for every element x of R

But since you havn't yet properly defined what R is -- let's face it,
"random-appearing" is not well-defined -- this is not really a claim
at all. ... Wait a minute! ... How about defining R in terms of that
inequality? So, instead of saying "random appearing", we could just as
well say that R contains all elemements x for which this inequality is
true:

  R := { x | len(c(t(x))) < len(x) }

That way we have an easy definition of R we can work with. "random
appearing" is pretty vague in comparison, don't you think? Ok, so, we
have some injective functions t and c and we've defined a set R and we
know that in case some x is part of R, len(c(t(x)))<len(x). Are you
still with me? Are you okay with this?

The big questions now are: How is this useful? How would anybody
benefit from t and c? Where is this "repeatable compression" you are
talking about? Suppose I want to build a "super compressor" that uses
t and c internally as often as necessary so that I only have to invoke
this super compressor once per file which I'd like to compress and I
don't what this super compressor to be limited to "random-appearing"
files. How would I go about doing it?

Cheers!
SG

[toc] | [prev] | [next] | [standalone]

#1424

On Jul 3, 7:19 am, SG <s.gesem...@gmail.com> wrote:
> On Jun 30, 11:23 am, oh_henry_oh wrote:
>
> > [...]
> > My basic technical claim is this:  I have developed a reversible and
> > lossless transformation; That can convert a list of random values
> > (ie,, a buffer,) such that a random buffer can be made to be non-
> > random, compressed, subsequently decompressed, and re-converted back
> > to random-appearing data when convenient.
>
> Let us try to express your claim in a more mathematical way:
>
> Basics, terms, definitions:
> - your "transform" is a function that maps byte sequences to other
> byte sequences, let's call it t
> - your function t is injective (otherwise there would be no inverse)
> - by compressed and decompressed here you refer to some lossless
> general-purpose compressor/decompressor. The compressor is also just a
> function that maps byte sequences to other byte sequences. Let's call
> it c, By definnition, c is also injective (otherwise it wouldn't be
> lossless).
> - There is a subset of byte sequences you call "random appearing",
> Let's call it R.
> - Let's use "len" to refer to a function which counts the number of
> bytes in a byte sequence.
>
> Claim ?
> Please help me with this. Apparently, you think that t and c have some
> nice properties. What properties are those besides injectivity? If I
> understand you right, you are "claiming":
>
>   len(c(t(x))) < len(x)   for every element x of R
>
> But since you havn't yet properly defined what R is -- let's face it,
> "random-appearing" is not well-defined -- this is not really a claim
> at all. ... Wait a minute! ... How about defining R in terms of that
> inequality? So, instead of saying "random appearing", we could just as
> well say that R contains all elemements x for which this inequality is
> true:
>
>   R := { x | len(c(t(x))) < len(x) }
>
> That way we have an easy definition of R we can work with. "random
> appearing" is pretty vague in comparison, don't you think? Ok, so, we
> have some injective functions t and c and we've defined a set R and we
> know that in case some x is part of R, len(c(t(x)))<len(x). Are you
> still with me? Are you okay with this?
>
> The big questions now are: How is this useful? How would anybody
> benefit from t and c? Where is this "repeatable compression" you are
> talking about? Suppose I want to build a "super compressor" that uses
> t and c internally as often as necessary so that I only have to invoke
> this super compressor once per file which I'd like to compress and I
> don't what this super compressor to be limited to "random-appearing"
> files. How would I go about doing it?
>
> Cheers!
> SG

really, you know I'm not going to give you enough to help you.

I have developed an algorithm which can process (presumably RAD,) and
transform it to a different format which can be reversed, is lossless,
and is, with one pass, hundreds of times less random than the original
input.

Now all I need to do is to sell it.

[toc] | [prev] | [next] | [standalone]

#1425

Am Samstag, 14. Juli 2012 05:47:20 UTC+2 schrieb oh_henry_oh:
> really, you know I'm not going to give you enough to help you.

*I* actually tried to help *you* by assisting you in formulating a *proper* *mathematical* claim.

> I have developed an algorithm which can process (presumably RAD,) and
> transform it to a different format which can be reversed, is lossless,
> and is, with one pass, hundreds of times less random than the original
> input.

If this is all you can do with respect to writing claims then it casts a really bad light on your technical skills. "RAD" is not well-defined and I'm sure that the meaning you attatch to the word "random" is rather unique. This meaning should also be clarified. Unless you are more clear about what's supposed to be cool about your development sane people won't give a sh!t.

> Now all I need to do is to sell it.

Good luck with that.

Cheers!
SG

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compression

csiph-web