Re: Repeatable compression is possible and easy to do, here's how...
- From: Providence <psionic81@xxxxxxxxx>
- Date: Mon, 29 Oct 2007 12:30:47 -0000
On Oct 28, 10:06 am, jg <jules.sto...@xxxxxxxxx> wrote:
These remarks are for 'erpy' and Lance.
First, when I first gave someone (two people who post here,) my three
line code segment, I was expecting that they would do some experiments
and get back to me, and that over a few days or weeks, some good
things would happen, compression wise. (I have the system already --
I was trying to help someone learn.)
The other person (at that time,) I specifically asked to do nothing
with the material. Since then I have made a disk (a CD-ROM,) and have
to take it to my local post office tomorrow (I am in receipt of an NDA
-- and in fact I trust the addressee, who shall remain nameless.)
The first person (let's call person #1 -- the STUDENT and person #2
FRIENDLYSKEPTIC.) Originally, although I had copied my three line
opus to FRIENDLYSKIPTIC I was expecting, that at my request, nothing
would happen. With STUDENT I was hoping for some educational fun.
Moving along, I spend hours -- not every single day, but most --
experimenting with what I hope are novel systems to do compression (I
have other projects, too,) About half of my work day is taken up with
experiments, well managing experiments, my computers do the actual
work of course.
Before I get too specific about my three line kernel, let's cover the
topic of machine learning and machine managed experiments.
First, generally, all machine learning seems to be based on three
things:
a) Human creativity, backed up by mathematical insight (where someone
might, for example, see a relationship between two curves describing
different parts of the same problem or related problems. For example,
remember my first system, I've published the details here.) It
involved least-squares curve fitting of client data pushed to the left
(think of a list of registers,) to make room for index keys, then sort
and curve-fit. Well, the error curve (produced by subtracting out the
sorted values from the guessed values,) has a characteristic that can
be predicted. (And remember -- others said this first, if you can
compress you can predict. And the same is true in reverse, if you can
predict you can compress.) Not that I think much of this method today
-- I wouldn't touch it, it is a perfect example of fool's gold!
About human creativity, it's not something that "you have or don't
have." Everyone is creative, and everyone has sufficient insight to
do this kind of work. Everyone has the same laboratory (ie.,
nature.)
Sidebar: One more thing before I leave this subject -- when you guys
are not bashing me, several of you are discussing math issues that
relate to compression, On occasion I have learned a few things.
(Just giving credit where credit is due.) And I keep trying to
partner with one or two smart folks who seem to perfer to beat me up
(write awful things about me -- and I have to pause, because your
statements are false.) Also I have lived a number of years and I have
known some very ugly people -- who hasn't -- and I know that the
people who do these sorts of things almost certainly have terrible
lives -- whereas because the God of the Bible is faithful -- I have
quite a good life. Thus I continue to ignore such folks and hope for
change in the future.
b) Machine learning can also be based on physical experiments; I have
developed a set of tools that make it possible for me quickly describe
something and run an experiment. In fact that small three line kernel
was produced in such a way -- lot's of blades spent many hours. The
result was that small snippet! More to the point though, if anyone in
this group expects to experiment, you need machine support -- lot's of
computer power.
I'm sorry, sometimes I get angry because of your nastyness and on
occasion have mislead you folks -- when I said that the simple three
line kernel could be represented because it's obviously only 256
states. Well, yes, I know it looks pretty simple. And 4 X 4 X 4 X 4
does equal 256. All true, but trust me here, that tiny snippet
requires hundreds of blade hours (I have 15 3Ghz i386 machines, each
with 3 or 4 Gb, and most of these machines have half a terabyte
apiece,) so when I say that this problem consumes lots of machine time
-- trust me, yes, I know it looks simple, but it's not. And if you'd
simply sit down with a PC, a C compiler, an editor, and perhaps a
candy bar, you'd get somewhere.
c) Machine learning can also be based on natural experiments; Not
only must one do physical experiments, one also has to do the math,
Symbolic math. If your lab doesn't provide you with Maxima, change
schools or find another employer.
By the way, everyone keeps telling me that sign bit can't be
recovered. Wrong! Now I know that 'if' statements can not be
evaluated (because they represent a point of discontinuity,) but this
is my technique for not letting if-logic interfere with symbolic
analysis:
ifeq(a,b,c,d)
means:
if (a == b) then c else d;
You can figure out the others...
Obviously this doesn't do the analysis, but it does permit the
analysis to proceed, whereas otherwise an 'if' statment terminates the
mechanical evaluation. Not on my computers.
But I am hoping to find some colleages and so I am not going to
provide any more hints. (Originally I intended to give this away, but
because it's been blown up, my goal changed.)
What have I told you that might help you?
That this "little" problem is not what it seems, and that it does in
fact work, that the code is part of a real program which is part of a
problem environment ('environment' wrt the RCVE side of the channel,)
and that it is possible -- even easy -- to infer the sign bit. And
infering the sign bit is sufficient to recover the correct two bit
data value.
If you 'get' this, email me please, don't publish the answer here.
What I said is true, this little system is just that, "little" -- it's
not exceptional, two bits in, two bits out. The compression comes
from subsequent compression. All I ever got from it is 1% to 2%. I
ran Mark's 415k million-digit file as input and found (again,) that
repeatable compressors that don't drop down fast enough *sometimes*
get into a bind because, after a while, the target result file can't
be compressed. In fact, this happens to Mark's 415k file, it is all
done at about 37k (I think that's the number -- I sent Mark a listing
of the directory sizes.)
I am hoping to be the first recipient of the prestigious Nelson
award. And unless someone can do better than 10:1 on that file, I
should get it. And I expect everyone reading this note to contribute
$10 bucks, too! Just send it to Mark.
On Oct 28, 3:40 am, Industrial One <industrial_...@xxxxxxxxxxx> wrote:
On Oct 27, 10:09 pm, erpy <i...@xxxxxxxxxxxxxxxx> wrote:
Like, because recovering sign bit of "abs(z) = z1-z2"
is..."impossible"...and you admit that you have some "superfantastic"
human-like AI system that allows you to reconstruct it - and you're not
giving it ?
No one would ever try and start to code something that tries to recover
the sign bit. (1- because it's impossible, 2- because you said you can
do it but it's very complicated to do)
That's why nobody is trying anything on your 3 lines. Sounds quite
common sense to me.
Best,
E.
He says the sign bit can be deduced from the context of surrounding
bits, much like if I would remove the 'e' from "the" you would know
when I meant to add the 'e' and when I didn't. But in respect to RAD
-- data where any combo is possible I doubt such a context would
exist. If I consider all possible 3-bit combos, how would I know which
sign bit goes where when anything is an equal possibility?
Hopefully he responds to my last post and gives a demonstration by
hand.- Hide quoted text -
- Show quoted text -
hey man, i've done a lot of programming with today's graphics
processors, they're definitely the fastest parallel processors these
days and if you have proper algorithms you can use nvidia's gpgpu code
on winxp machines to do way more than you could 6 months ago.. if
you're ever interested in gpu conversions of your routines let me
know.
chris.
.
- References:
- Repeatable compression is possible and easy to do, here's how...
- From: jg
- Re: Repeatable compression is possible and easy to do, here's how...
- From: Thomas Richter
- Re: Repeatable compression is possible and easy to do, here's how...
- From: jg
- Re: Repeatable compression is possible and easy to do, here's how...
- From: Jim Leonard
- Re: Repeatable compression is possible and easy to do, here's how...
- From: jg
- Re: Repeatable compression is possible and easy to do, here's how...
- From: Jim Leonard
- Re: Repeatable compression is possible and easy to do, here's how...
- From: jg
- Re: Repeatable compression is possible and easy to do, here's how...
- From: Jim Leonard
- Re: Repeatable compression is possible and easy to do, here's how...
- From: jg
- Re: Repeatable compression is possible and easy to do, here's how...
- From: Jim Leonard
- Re: Repeatable compression is possible and easy to do, here's how...
- From: jg
- Re: Repeatable compression is possible and easy to do, here's how...
- From: erpy
- Re: Repeatable compression is possible and easy to do, here's how...
- From: Industrial One
- Re: Repeatable compression is possible and easy to do, here's how...
- From: jg
- Repeatable compression is possible and easy to do, here's how...
- Prev by Date: Re: Repeatable compression is possible and easy to do, here's how...
- Next by Date: Re: Repeatable compression is possible and easy to do, here's how...
- Previous by thread: Re: Repeatable compression is possible and easy to do, here's how...
- Next by thread: Re: Repeatable compression is possible and easy to do, here's how...
- Index(es):
Relevant Pages
|
|