| View previous topic :: View next topic |
| Author |
Message |
mcjason
Guest
|
 Posted: Mon Jul 28, 2008 1:18 pm Post subject: Re: compression type |
 |
|
On Jul 26, 1:42 am, stan <smo...@exis.net> wrote:
[quote]mcjason wrote:
On Jul 23, 1:37 pm, Jim Leonard <MobyGa...@gmail.com> wrote:
On Jul 23, 12:14 am, mcjason <mcja...@gmail.com> wrote:
and i bet though that what>s compressed is able to be compressed again
the same way.. i mean, there should be any reason why there isn>t
patterns to find like this in how you say curved lines and sphere
areas...
We>re done here. I think your next course of action is to stop
ranting and program an LZ77 compressor so that you gain actual
experience writing a compressor. Here>s a few links to help you get
started:
http://datacompression.dogma.net/index.php?title=FAQ:Intro_to_Data_Co....
http://www.fadden.com/techmisc/hdc/index.htm
Read these completely, and if you don>t understand the LZ77 portions,
find a different hobby.
I can put everything you said into a smaller program and make it run
to say the same if it were trying to be the simplest way to program a
rejection letter servant with no manners and takes only a keyword as a
hint, and it would also serve the purpose of answering any post that
tries to be better than there isn>t to think about.
does that compress you? I found it saying alot more than one thing.
You don>t seem to believe conventional thinking is correct and that you
have a totally new idea.
Can you actually code this up? Or maybe show some pseudo code
explanation? Are current computers capable of executing your idea?
Failing any of that can you show a specific original file and a complete
compressed file? You have repeatedly mentioned uncompressed examples and
shown some reorganizations but you havent shown how to represent the
geometry that is needed to rebuild the original text. You method of
compression can repoduce the original information I hope.
How about showing:
1. An uncompressed string.
[/quote]
Ok, so in idea....
"my cat walks on my living room floor"
m:y:cat:wa:l:ks:on:living:r:oo:fl:r
or a few other ways to say
so that>s what>s kept in the file.. right...
so say for that in the file, but the way it>s in a sphere or
something, like where there>s just a point in the sphere to mean each
block, i guess each point in the sphere
would be like starting from the center and some kind of spiral outward
where nothing can be a problem as much for how you get from one point
to the next if you draw a curved line through it.
so then as a token a math spiral line connecting parts together
right...
so, it>s to see the spiral how it draws across each point in the
geometry. then those are the parts together that become the original
content.
so however big that would be.
even for a spiral to not be mixed with regular file data, where
token>s have big business about being something not like anything
else.
right... so file format: (GEOMETRY AREA)(SPIRAL)
see... not even a pigeonhole problem, because tokens aren>t mixed with
real information.
so I tried explaining what I saw a tradeoff be that might remark on
random>s compressability.
so.. as file untouched except in format I guess..
(ALL FILE CONTENTS AS ONE BLOCK)(SPIRAL JUST OF POINT OF BLOCK)
ehem.. ok, so just to say, nothing at all bigger really...
so.. since it says nothing now about the file being bigger just to say
nothing different, what is it to say any detail of file size
shrinkink...
so each block takes space to say... it can be said one block after
another like not where it goes but how each after another spirals from
a center point,
so I guess each block can be said as just what the block is and how it
seperates.
so blocks would be in a different part than tokens, because it>s to
think doing it the other way where it>s like saying at least one token
means the whole file as the whole file is a big block in the geometry,
or many blocks with a token saying how they are together.. because
tokens don>t have to mix with real file data, like where it>s a
problem to say a token and the real data.
so it>s to see nothing bigger to just say one block, and a spiral that
goes nowhere but at the location of the block for the whole content.
so it>s no bigger really...
now, it>s to say only better with size.
so what now says smaller?
if anywhere in the whole file is just "ab", 2 letters, and it>s more
than once, it>s to do this each time:
say for the block before and after "ab", is a seperate block, so it>s
a pattern to organize.
say "ab" only once.. right. the point :)
then a spiral that organizes the pattern together.
so the spiral is from first block, to "ab" block, to next block, to
"ab" block, and so on...
so that>s a spiral right... in a geometry area like a sphere, where
each block is to say just a point in the sphere somehow.
so right now... if for each time "ab" is found, it>s a block
seperation and the spiral getting more complicated, then is it worth
it?
so a spiral to say more complicated to connect more points together as
how it comes together, and a block seperation, to be all there
is to say more to size, for every "ab" there is...
see how the file is allowed to be any size though, for the way that
for all of it, you can see this tradeoff for how it is to find "ab"
only once ?
see how that is at par though, see the idea that>s at par with? it>s
even odds of working this way, it>s an even tradeoff..
especially to notice how token idea is a spiral seperate from file
content.
so that>s just to say 2 bytes, as pretty much even probably, with what
seperating a block is at expence and a spiral being more complicated.
see how this figure would play in any way, and it>s just to say ONLY
ONE recurring string for a file ANY SIZE, is to reduce it>s size.
mostly because of how a token isn>t mixed with real data, but also
because it>s pattern organization the way it can work further even..
because it>s to say better than 2 bytes now, but now 2 bytes found the
same ANYWHERE is only a block seperation and spiral more complicated
for each if that>s worth it.. maybe not 2 bytes, but in arbitrary
sized data, any size bigger, even more bytes together in all of it to
say the size reduced? because in geometry for plotpoint of blocks to
connect together it can be anything like how you say one block after
another for how the spiral works at being able to put it together.
see how that>s a tradeoff though that says _even_ for a file any size
of a recurring string that it>s always worth it.. especially how it>s
a spiral that puts it together as not a token mixed with file data? <-
see though
see how that has to be right to think about it... because to seperate
a block is only to say one block seperate from another, if one block
after another just says from the center out or something, and then
after all that a spiral putting them together in order... see how from
now on for any size it>s just that?
do I make as much sense?
[quote]
2. The complete results of applying your idea to 1.
The reorganized parts and the geometry required to uncompress
the reorganized parts.( The information needed to map the
reorganized parts back to the original data. )
Maybe I>m not clearly seeing your idea. You>re basically saying that in
your head, even random data can be compressed. Can you make the idea
concrete?
See in my head I can imagine that perpetual motion works, gas is cheap,
and teenagers aren>t the least bit annoying. Then I wake up and, oh
well.- Hide quoted text -
- Show quoted text -[/quote] |
|
| |
|
 Back to top |
mcjason
Guest
|
| Posted: Mon Jul 28, 2008 2:59 pm Post subject: Re: compression type |
|
|
On Jul 28, 9:18 am, mcjason <mcja...@gmail.com> wrote:
[quote]On Jul 26, 1:42 am, stan <smo...@exis.net> wrote:
mcjason wrote:
On Jul 23, 1:37 pm, Jim Leonard <MobyGa...@gmail.com> wrote:
On Jul 23, 12:14 am, mcjason <mcja...@gmail.com> wrote:
and i bet though that what>s compressed is able to be compressed again
the same way.. i mean, there should be any reason why there isn>t
patterns to find like this in how you say curved lines and sphere
areas...
We>re done here. I think your next course of action is to stop
ranting and program an LZ77 compressor so that you gain actual
experience writing a compressor. Here>s a few links to help you get
started:
http://datacompression.dogma.net/index.php?title=FAQ:Intro_to_Data_Co...
http://www.fadden.com/techmisc/hdc/index.htm
Read these completely, and if you don>t understand the LZ77 portions,
find a different hobby.
I can put everything you said into a smaller program and make it run
to say the same if it were trying to be the simplest way to program a
rejection letter servant with no manners and takes only a keyword as a
hint, and it would also serve the purpose of answering any post that
tries to be better than there isn>t to think about.
does that compress you? I found it saying alot more than one thing.
You don>t seem to believe conventional thinking is correct and that you
have a totally new idea.
Can you actually code this up? Or maybe show some pseudo code
explanation? Are current computers capable of executing your idea?
Failing any of that can you show a specific original file and a complete
compressed file? You have repeatedly mentioned uncompressed examples and
shown some reorganizations but you havent shown how to represent the
geometry that is needed to rebuild the original text. You method of
compression can repoduce the original information I hope.
How about showing:
1. An uncompressed string.
Ok, so in idea....
"my cat walks on my living room floor"
m:y:cat:wa:l:ks:on:living:r:oo:fl:r
or a few other ways to say
so that>s what>s kept in the file.. right...
so say for that in the file, but the way it>s in a sphere or
something, like where there>s just a point in the sphere to mean each
block, i guess each point in the sphere
would be like starting from the center and some kind of spiral outward
where nothing can be a problem as much for how you get from one point
to the next if you draw a curved line through it.
so then as a token a math spiral line connecting parts together
right...
so, it>s to see the spiral how it draws across each point in the
geometry. then those are the parts together that become the original
content.
so however big that would be.
even for a spiral to not be mixed with regular file data, where
token>s have big business about being something not like anything
else.
right... so file format: (GEOMETRY AREA)(SPIRAL)
see... not even a pigeonhole problem, because tokens aren>t mixed with
real information.
so I tried explaining what I saw a tradeoff be that might remark on
random>s compressability.
so.. as file untouched except in format I guess..
(ALL FILE CONTENTS AS ONE BLOCK)(SPIRAL JUST OF POINT OF BLOCK)
ehem.. ok, so just to say, nothing at all bigger really...
so.. since it says nothing now about the file being bigger just to say
nothing different, what is it to say any detail of file size
shrinkink...
so each block takes space to say... it can be said one block after
another like not where it goes but how each after another spirals from
a center point,
so I guess each block can be said as just what the block is and how it
seperates.
so blocks would be in a different part than tokens, because it>s to
think doing it the other way where it>s like saying at least one token
means the whole file as the whole file is a big block in the geometry,
or many blocks with a token saying how they are together.. because
tokens don>t have to mix with real file data, like where it>s a
problem to say a token and the real data.
so it>s to see nothing bigger to just say one block, and a spiral that
goes nowhere but at the location of the block for the whole content.
so it>s no bigger really...
now, it>s to say only better with size.
so what now says smaller?
if anywhere in the whole file is just "ab", 2 letters, and it>s more
than once, it>s to do this each time:
say for the block before and after "ab", is a seperate block, so it>s
a pattern to organize.
say "ab" only once.. right. the point :)
then a spiral that organizes the pattern together.
so the spiral is from first block, to "ab" block, to next block, to
"ab" block, and so on...
so that>s a spiral right... in a geometry area like a sphere, where
each block is to say just a point in the sphere somehow.
so right now... if for each time "ab" is found, it>s a block
seperation and the spiral getting more complicated, then is it worth
it?
so a spiral to say more complicated to connect more points together as
how it comes together, and a block seperation, to be all there
is to say more to size, for every "ab" there is...
see how the file is allowed to be any size though, for the way that
for all of it, you can see this tradeoff for how it is to find "ab"
only once ?
see how that is at par though, see the idea that>s at par with? it>s
even odds of working this way, it>s an even tradeoff..
especially to notice how token idea is a spiral seperate from file
content.
so that>s just to say 2 bytes, as pretty much even probably, with what
seperating a block is at expence and a spiral being more complicated.
see how this figure would play in any way, and it>s just to say ONLY
ONE recurring string for a file ANY SIZE, is to reduce it>s size.
mostly because of how a token isn>t mixed with real data, but also
because it>s pattern organization the way it can work further even..
because it>s to say better than 2 bytes now, but now 2 bytes found the
same ANYWHERE is only a block seperation and spiral more complicated
for each if that>s worth it.. maybe not 2 bytes, but in arbitrary
sized data, any size bigger, even more bytes together in all of it to
say the size reduced? because in geometry for plotpoint of blocks to
connect together it can be anything like how you say one block after
another for how the spiral works at being able to put it together.
see how that>s a tradeoff though that says _even_ for a file any size
of a recurring string that it>s always worth it.. especially how it>s
a spiral that puts it together as not a token mixed with file data? <-
see though
see how that has to be right to think about it... because to seperate
a block is only to say one block seperate from another, if one block
after another just says from the center out or something, and then
after all that a spiral putting them together in order... see how from
now on for any size it>s just that?
do I make as much sense?
2. The complete results of applying your idea to 1.
The reorganized parts and the geometry required to uncompress
the reorganized parts.( The information needed to map the
reorganized parts back to the original data. )
Maybe I>m not clearly seeing your idea. You>re basically saying that in
your head, even random data can be compressed. Can you make the idea
concrete?
See in my head I can imagine that perpetual motion works, gas is cheap,
and teenagers aren>t the least bit annoying. Then I wake up and, oh
well.- Hide quoted text -
- Show quoted text -- Hide quoted text -
- Show quoted text -- Hide quoted text -
- Show quoted text -
[/quote]
Do you see how it>s exactly the same as redundancy reduction too, how
it>s to say once for multiple occurances, but has a better idea too
for having less to regard more information?
because it doesn>t have the problem of finding how it>s to say a token
for
"platapus" "plank" as pla but then tapus and nk, but maybe pl is the
better idea and atapus ank , for how pl is given a token for more too,
for everything else.
but that>s not really the point...
for example "record sale" and "reorder" is like "re:c:ord:sal:e:r :"
as always good if a spiral can say across 6 places and 4 places like
it>s smaller than 10 bytes + spiral + 6 block seperations to say
instead of 18 bytes.. probably not, but because there' to say more
without a problem the way now "reader" is to add "ade" block, and to
say spiral slightly more complicated, but to say reader now by
"re:e:r:" already there.... so right, "re:e:r" but "re" because it
pieces as together for the size of the spiral or something. so more to
add as "recall" is to maybe only say "call" as a new block, or maybe
to say "sal" block as "s:al" but add "l" block too, for "recall".
I>m having a hard time trying to say what I think the way it works...
it>s like having a big sphere, where word parts for example are spaced
close together and apart where a curve can always connect the parts
together. but then it>s for words that have the same prefixes and
suffixes for example to be the same part for the prefix/suffix but
near in the sphere are the other parts of words where a curve draws
through a few parts to put the word parts together in order to make
the word, then say that as the token.
but like pattern parts right... because better yet than redundancy of
recurrances is redundancy of patterns rearrangeable... but is
redundancy of recurrances anyways.
see how patterns rearrangeable is different though? the way backwards
of forwards is like to hold "wards:back:for" but now back and forth is
"back:th"?
see how in different order though, parts that can be any order..
see _MOST IMPORTANTLY_ though, how putting big and small parts
together as a pattern to organize, is like saying the parts only once
and making a spiral only somewhat more complicated? besides how it
already is to say the content so far? see how that can be? see how
that has a tradeoff besides what it>s worth to keep a token for a part
that recurs for example... because a 1 byte small part for example
might always be worth it in saying how the spiral crosses to put other
parts together another way? because the spiral is not like saying each
token for where the spiral goes is not the point, that>s not what.
it>s a spiral that works better at what is already there and has
ultimate reach at what a token has problems referring to maybe? I
think I say it wrong, there>s a better way to think of it..
it>s like how you can never escape being able to use a part already as
together with other parts to be part of other parts together, to put
together. like, a token is to just say one thing usually right? match/
length offset? so that>s like where a token is good for something if
it>s smaller than something it says, and so with how a token can be
said too. but a token like that never makes better the idea of
"cinder" and "cider" for "ci" and "der" except to say a token each..
but that>s fine because to say it this way would be "ci:n:der" and a
spiral like through ci-der-ci-n-der like it>s no better for size. but
then to say more as what has parts "ci", "n", or "der" in it is not
the problem with finding out if the rest is more, like "citadel", but
there>s also "citrus" and "recite", then maybe a token for "cit"
instead.. nah, that>s not it.. it>s something else about how this
would work.
it>s how with "th:er:ch:amb:und:gh:gn:at" a spiral as a token can say
in any order together better than a bunch of tokens for each part, if
they are together another way... nah, that>s not _exactly_ the
point... but is kinda.
like how a spiral can say "thunder", "chamber", "thunder", "gnat",
"chat"... whatever, but a spiral so big to put it together a way like
smaller than each token for parts, where sometimes with tokens it>s
other parts to be better at saying tokens too or something... nah,
it>s not really that but yah...
it>s how it conglubulates altogether somehow in a sphere that it>s to
think about how to say a spiral too but not, it>s how "chat" and
"attenuate" are what curves in the same area can put together, but how
curves can also put together "attention" and "wallpaper" like where
"pappa" is what can come together too with curves.
but that>s not it I guess to say... it>s how from far in the sphere
across the other side cuts across a middle portion or something... not
really to think about though...
it>s how altether though pretty much everything that>s said forwards
can be said backwards... like how close together in a sphere there>s
every single way to form an html tag with value/attributes, where
every value name and attribute type is a data block only once, and how
a curve connects the pieces of how an html tag is formed one way or
another.
but instead other ways, and not even comparable mostly, would say
sometimes "<h1 space=" is to have a token for, but so is "<h1 indent="
if that>s a better way.
so can you see how a sphere might work like that? like, it>s to say
all parts of html tags like "H1:Width:Height:HR:H2:Redisplay" are
seperate blocks, that piece together as a full tag the way a curve
connects the pieces together?
then all you say for all the html is where a big spiral or something +
all the data blocks like that, is what becomes it all, but to say so
small maybe? |
|
| |
|
| Back to top |
mcjason
Guest
|
| Posted: Mon Jul 28, 2008 3:51 pm Post subject: Re: compression type |
|
|
On Jul 28, 10:59 am, mcjason <mcja...@gmail.com> wrote:
[quote]On Jul 28, 9:18 am, mcjason <mcja...@gmail.com> wrote:
On Jul 26, 1:42 am, stan <smo...@exis.net> wrote:
mcjason wrote:
On Jul 23, 1:37 pm, Jim Leonard <MobyGa...@gmail.com> wrote:
On Jul 23, 12:14 am, mcjason <mcja...@gmail.com> wrote:
and i bet though that what>s compressed is able to be compressed again
the same way.. i mean, there should be any reason why there isn>t
patterns to find like this in how you say curved lines and sphere
areas...
We>re done here. I think your next course of action is to stop
ranting and program an LZ77 compressor so that you gain actual
experience writing a compressor. Here>s a few links to help you get
started:
http://datacompression.dogma.net/index.php?title=FAQ:Intro_to_Data_Co...
http://www.fadden.com/techmisc/hdc/index.htm
Read these completely, and if you don>t understand the LZ77 portions,
find a different hobby.
I can put everything you said into a smaller program and make it run
to say the same if it were trying to be the simplest way to program a
rejection letter servant with no manners and takes only a keyword as a
hint, and it would also serve the purpose of answering any post that
tries to be better than there isn>t to think about.
does that compress you? I found it saying alot more than one thing.
You don>t seem to believe conventional thinking is correct and that you
have a totally new idea.
Can you actually code this up? Or maybe show some pseudo code
explanation? Are current computers capable of executing your idea?
Failing any of that can you show a specific original file and a complete
compressed file? You have repeatedly mentioned uncompressed examples and
shown some reorganizations but you havent shown how to represent the
geometry that is needed to rebuild the original text. You method of
compression can repoduce the original information I hope.
How about showing:
1. An uncompressed string.
Ok, so in idea....
"my cat walks on my living room floor"
m:y:cat:wa:l:ks:on:living:r:oo:fl:r
or a few other ways to say
so that>s what>s kept in the file.. right...
so say for that in the file, but the way it>s in a sphere or
something, like where there>s just a point in the sphere to mean each
block, i guess each point in the sphere
would be like starting from the center and some kind of spiral outward
where nothing can be a problem as much for how you get from one point
to the next if you draw a curved line through it.
so then as a token a math spiral line connecting parts together
right...
so, it>s to see the spiral how it draws across each point in the
geometry. then those are the parts together that become the original
content.
so however big that would be.
even for a spiral to not be mixed with regular file data, where
token>s have big business about being something not like anything
else.
right... so file format: (GEOMETRY AREA)(SPIRAL)
see... not even a pigeonhole problem, because tokens aren>t mixed with
real information.
so I tried explaining what I saw a tradeoff be that might remark on
random>s compressability.
so.. as file untouched except in format I guess..
(ALL FILE CONTENTS AS ONE BLOCK)(SPIRAL JUST OF POINT OF BLOCK)
ehem.. ok, so just to say, nothing at all bigger really...
so.. since it says nothing now about the file being bigger just to say
nothing different, what is it to say any detail of file size
shrinkink...
so each block takes space to say... it can be said one block after
another like not where it goes but how each after another spirals from
a center point,
so I guess each block can be said as just what the block is and how it
seperates.
so blocks would be in a different part than tokens, because it>s to
think doing it the other way where it>s like saying at least one token
means the whole file as the whole file is a big block in the geometry,
or many blocks with a token saying how they are together.. because
tokens don>t have to mix with real file data, like where it>s a
problem to say a token and the real data.
so it>s to see nothing bigger to just say one block, and a spiral that
goes nowhere but at the location of the block for the whole content.
so it>s no bigger really...
now, it>s to say only better with size.
so what now says smaller?
if anywhere in the whole file is just "ab", 2 letters, and it>s more
than once, it>s to do this each time:
say for the block before and after "ab", is a seperate block, so it>s
a pattern to organize.
say "ab" only once.. right. the point :)
then a spiral that organizes the pattern together.
so the spiral is from first block, to "ab" block, to next block, to
"ab" block, and so on...
so that>s a spiral right... in a geometry area like a sphere, where
each block is to say just a point in the sphere somehow.
so right now... if for each time "ab" is found, it>s a block
seperation and the spiral getting more complicated, then is it worth
it?
so a spiral to say more complicated to connect more points together as
how it comes together, and a block seperation, to be all there
is to say more to size, for every "ab" there is...
see how the file is allowed to be any size though, for the way that
for all of it, you can see this tradeoff for how it is to find "ab"
only once ?
see how that is at par though, see the idea that>s at par with? it>s
even odds of working this way, it>s an even tradeoff..
especially to notice how token idea is a spiral seperate from file
content.
so that>s just to say 2 bytes, as pretty much even probably, with what
seperating a block is at expence and a spiral being more complicated.
see how this figure would play in any way, and it>s just to say ONLY
ONE recurring string for a file ANY SIZE, is to reduce it>s size.
mostly because of how a token isn>t mixed with real data, but also
because it>s pattern organization the way it can work further even..
because it>s to say better than 2 bytes now, but now 2 bytes found the
same ANYWHERE is only a block seperation and spiral more complicated
for each if that>s worth it.. maybe not 2 bytes, but in arbitrary
sized data, any size bigger, even more bytes together in all of it to
say the size reduced? because in geometry for plotpoint of blocks to
connect together it can be anything like how you say one block after
another for how the spiral works at being able to put it together.
see how that>s a tradeoff though that says _even_ for a file any size
of a recurring string that it>s always worth it.. especially how it>s
a spiral that puts it together as not a token mixed with file data? <-
see though
see how that has to be right to think about it... because to seperate
a block is only to say one block seperate from another, if one block
after another just says from the center out or something, and then
after all that a spiral putting them together in order... see how from
now on for any size it>s just that?
do I make as much sense?
2. The complete results of applying your idea to 1.
The reorganized parts and the geometry required to uncompress
the reorganized parts.( The information needed to map the
reorganized parts back to the original data. )
Maybe I>m not clearly seeing your idea. You>re basically saying that in
your head, even random data can be compressed. Can you make the idea
concrete?
See in my head I can imagine that perpetual motion works, gas is cheap,
and teenagers aren>t the least bit annoying. Then I wake up and, oh
well.- Hide quoted text -
- Show quoted text -- Hide quoted text -
- Show quoted text -- Hide quoted text -
- Show quoted text -
Do you see how it>s exactly the same as redundancy reduction too, how
it>s to say once for multiple occurances, but has a better idea too
for having less to regard more information?
because it doesn>t have the problem of finding how it>s to say a token
for
"platapus" "plank" as pla but then tapus and nk, but maybe pl is the
better idea and atapus ank , for how pl is given a token for more too,
for everything else.
but that>s not really the point...
for example "record sale" and "reorder" is like "re:c:ord:sal:e:r :"
as always good if a spiral can say across 6 places and 4 places like
it>s smaller than 10 bytes + spiral + 6 block seperations to say
instead of 18 bytes.. probably not, but because there' to say more
without a problem the way now "reader" is to add "ade" block, and to
say spiral slightly more complicated, but to say reader now by
"re:e:r:" already there.... so right, "re:e:r" but "re" because it
pieces as together for the size of the spiral or something. so more to
add as "recall" is to maybe only say "call" as a new block, or maybe
to say "sal" block as "s:al" but add "l" block too, for "recall".
I>m having a hard time trying to say what I think the way it works...
it>s like having a big sphere, where word parts for example are spaced
close together and apart where a curve can always connect the parts
together. but then it>s for words that have the same prefixes and
suffixes for example to be the same part for the prefix/suffix but
near in the sphere are the other parts of words where a curve draws
through a few parts to put the word parts together in order to make
the word, then say that as the token.
but like pattern parts right... because better yet than redundancy of
recurrances is redundancy of patterns rearrangeable... but is
redundancy of recurrances anyways.
see how patterns rearrangeable is different though? the way backwards
of forwards is like to hold "wards:back:for" but now back and forth is
"back:th"?
see how in different ...
read more »- Hide quoted text -
- Show quoted text -
[/quote]
right.. like for HTML
so to think all parts of HTML tags put in a sphere, and parts of the
contents like words only once, but mostly word parts I guess.
then one big spiral that connects the parts together, then going the
same place for the same part to use again...
so to just say as data to store plain and simple... each block like it
becomes a point in a sphere, then just a spiral as one big token
though, not tokens mixes with real data... so not even a pigeonhole
problem with having a way to say the token.
so each block, block seperation, and a spiral. as the whole file.
especially the token that isn>t mixes, so just the blocks, and a
spiral like math for a spiral. connecting the parts together.
see how the better idea it might have though is to keep "redo" as
"re:do" because there can/is also "donut" and "relapse" like
"nut:lapse" are kept too, because a single curve line is the token to
saying it? but it>s not worthwhile or worthless because "re" to have a
token but maybe "don" and "do" if there>s also "donna", but not with
how most probably work... not well explained i guess, I>m having
trouble saying a way to think of it where the proportion of how it
would work is explained well.
it>s like.. never a problem somewhere where saying a token for a
string part is, but that>s not it, but kinda...
it>s like, having another way in thinking about it for how it>s always
about making a pattern that organizes another way with a curve for how
it organizes another way still with another curve.. but how that is
altogether instead.
for how it is to explain what might be done overall this way.
it>s like taking every word there is and breaking off prefix/suffix/
etc. parts of the words, and keeping base words and such, and just
saying for any word a curve line in the sphere to connect the prefix/
suffix/base word... but how even a bigger curve is worth saying easier
than a smaller curve for much more together maybe.. but not.
it would probably, but it>s how patterns can organize another way that
keeps it a way different than saying how repeat occurances are
respected with a token.
i guess it>s like how "abracadabra" "brass" "homeplate" can be said
like "a:bra:c:d:s:homeplate", instead of "aBRAcadaBRA" "BRAss"
"homeplate" like for repeat occurances only maybe... for what>s worth
it. because "a" is worth saying seperate in one way, but maybe not
another.. like, it>s always worth it if a curve draws through it as
small but draws through what>s bigger too to say what a curve can be
altogether as a token for what it says... not exactly though.. not
exactly.
but kindof.... but with more like where "a" is a middle part of what
comes together and stuff... where a curve always says together one way
or another is something different... because if you think everything
like blocks that come together another way, and reorganize anyway, but
say blocks but how they organize different ways, and how you use the
same blocks but not the same for different organizations but usually
always the same for the parts that organize as part...
it should have another ratio to it... it works by being with a
different benefit of reducing datasize.
it>s how it>s all packed together to say what can be organized in a
different way for what comes together, and how you say for it to come
together...
it>s how things can be so small it>s worthless for a token to say it
usually, but is worth it to be part of 2 bigger parts for example a
curve can say is what comes to being bigger than the curved line.
it>s not that though but yeah....
it>s how I bet with what>s compressed, by how a sphere and spiral is
even said, it can reduce it yet again just because, not even with any
idea of being good or bad to start with of how it was compressed, but
by how this tries to be about any data..
it>s like saying, for all data altogether to be compressed, the only
thing that doesn>t compress some is where altogether you can>t find 3
characters or so that recur even once.. because it>ll work like that
with how it is to not mix tokens with real data... because it>s
instead to say sphere area of points that say blocks, but then say
spiral of points together in order, like where the spiral goes back
and forth between the same points to put it together.
it>s how for what that would work on... it>s like impossible for
something to not be much a way like this.
but see how even once to say 3 characters that recur more than once,
it>s good to say once only the 3 characters...
because it>s instead to say this...
plain data: "ndfnnBBBefnnnBBBdsf98hfwennBBB"
is
compressed: "ndfnn:efnnn:dsf98hfwenn:BBB":SPIRAL("ndfnn" - "BBB" -
"efnnn" - "BBB" - "dsf98hfwenn" - "BBB")
so is it less to say that compressed like that? if the SPIRAL in math
to describe is no more than 6 bytes right... but block seperation too.
but if there was infinite more BBB... no matter what it>s to say
forever worth saying less information if BBB is always to take away
and add what always works... like, take away BBB but add block
seperation and make the spiral go one place more.
so then it>s any size anyways besides 3 characters that say the same
right?
but there>s no extra overhead... no pigeonhole idea at all.. see how
it>s no pigeonhole idea at all? see how that>s never a problem?
because the spiral is on it>s own to put data blocks together? see
what that says about how forever for everything that makes this
tradeoff is to say less.. but it>s to say nothing more to start with,
but it>s never more with size except how the spiral connects more
points.. like the points can>t be arranged a way that works well...
and how there can be any number of blocks.. see how no range extent/
reach/facinity problem?
see what block seperation.. it>s what>s between BBB and another BBB to
seperate, to say are blocks that organize together... like from one
BBB to another, is what>s inbetween, as blocks connected together..
right.... BBB the same block to visit.
so forever "jsdflskdjfBBBsdflsdjflBBBsdfdsdfsdBBB" but so forever...
chance of BBB showing up again but maybe not.. but forever
is to say less size for any BBB if block seperation and spiral being
made more complicated is less size than BBB.
see how that>s forever though? see how that works forever to say
that>s the tradeoff?
what is it to say random is compressable when you should only find
what is bigger than saying a block seperation and spiral being made
more complicated as what matters, for any data size? like, it should
be thinking about how this is... to say that. maybe? |
|
| |
|
| Back to top |
mcjason
Guest
|
| Posted: Mon Jul 28, 2008 5:48 pm Post subject: Re: compression type |
|
|
On Jul 25, 5:05 am, Thomas Richter <t...@math.tu-berlin.de> wrote:
[quote]mcjason schrieb:
Second point above. Please state what "random" means. You haven>t done
so yet. Please do your homework - it>s really about helping you, not
about annoying you. Nobody can do that for you, you must learn it yourself.
data where the trend tends to be few repeat occurances of a length of
data, where it>s usually not a worthwhile tradeoff to say one
occurance of what repeats, for there to be a token, for how tokens
have a limited way of being said for what else is said. Beause in
random data the allocation space for a token is usually too exhausted
for
there to be a worthwhile way of saying what a token is for what else
is said, for how a repeat occurance of a length of data can be said
once with a token otherwise.
Not a very reasonable definition, but for the time being, let>s take
this. According to this definition, the following string
1234567891012131415161718191202122232425262728293031323334353637383940...
[/quote]
see for each 2 numbers together for that like...
12 23 34 45 56 67 78 89 91 10 01 12 21 13 31 14 41 15 51 16 61 17 71
18 81 19 91 12 20 02 21 12 22 22 23 32 24 42 25 52 26 62 27 72 28 82
29 93 30 03 31 13 32
23 33 33 34 43 35 53 36 63 37 73 38 83 39 94 40
so say this...
say each 2 numbers the same once only.
put a point in a sphere for each 2 numbers.
draw a spiral inside the sphere connecting the points together the way
it is to say all numbers in order, so go to the same place in the
sphere for the same 2 numbers right...
so then that can be stored as a file saying just the sphere with the
points for each 2 numbers, and a spiral right?
so the file ... to seperate each 2 numbers as on they>re own.. say one
after the other in the order they are go in the sphere, like start at
the center of the sphere for the first and draw around the center plot
points for each 2 numbers, plot points say for example that make it
easy to draw a spiral back and fourth between them. and the math of a
spiral loop.
get it.. how a spiral loop connects the parts together like one after
the other where the spiral touches points in the sphere?
see how the spiral around would be numbers by 2 numbers at a time one
way, and opposite the other way and stuff... see how you can connect-
the-dots of the whole number that comes together?
so i mean for the spiral to say the numbers by the 2 in order that
reconstructs the file content... like to say parts that organize in
another way.
so it>s just to say what goes in a sphere.. and a spiral loop that
draws inside the loop.. then where the spiral goes is what is next...
like to make the spiral start somewhere and the way it spirals is to
say the numbers any way they can be put together.
[quote]
is random, (nothing repeats, provably) though still a ten-year old can
see its construction algorithm.
Hint: You seem to believe that "random" is an attribute that you can a
apply to a sequence you can point at. "Random" is the property of a
process, not of a specific string in particular. Depending on the
process, the string
1111111111111111111111111111111111111111111111111111111111111....
is as likely as the above.
I understand perfectly why this can be seen as a problem when it comes
to compressing with the technique of saying what repeats once with a
token for other occurances.
I>m not saying this. *You* say this.
It>s intuititive to think of this the way
the problem is well described. But I can>t find anywhere the say so of
random being hard to compress isn>t connected with the idea of only
working the way that repeat occurances are made fewer, with tokens
taking a naming allocation.
It>s very limited to think that>s the only way to compress, I gave A
PERFECT analagy of how this is VERY WRONG.
*Sigh* You gave a non-working example. What makes you believe that I
think in "patterns"? I don>t. My field is *image compression*, yet you
can compress them even though there are no patterns, and the algorithms
used there do not look for matched patterns. Hence, please do not try to
tell me what I do and do not know - I think it>s the time for you to
deepen your research.
it>s to say this proves how random is compressable, take it whatever
way you want I know it>s right.
Using a definition of "random" that makes sense (your definition
doesn>t, I wouldn>t call either of the strings random), you cannot
compress random strings.
say for every length of data there can be a shape, a shape where it>s
a shape different for everyway the data is different.
given perfect math it would be a shape the same size as the data,
because of that making a different shape for everyway data is
different.
That>s a "data model"; the question is "is this data model" reasonable
to compress data? And the answer is: For every model one can construct
data that cannot be successfully modeled by it (IOW, cannot be
compressed, using an optimal entropy coding algorithm on the output of
the model). In your case, the model would be to draw shapes or curves or
spheres. As long as you don>t give better arguments as why you believe
the model you have is good, and for which type of data it is good for,
this is a lost attempt.
What you don>t seem to realize is that while it is fairly true that more
complex models can describe more complex data, these models *also*
require more modeling parameters you somehow have to encode as part of
the message. It is a trade-off between simplicity of the model against
the size of the model parameters. Choosing a simple pattern repetition
model (as in LZ77) leaves only few model parameters (length and offset),
but it is only sufficient to match patterns exactly (from the past) and
not to describe sequences with a more complicated construction algorithm
(as the one I gave above). You can surely introduces models that do that
better, but then you also need more parameters.
In the end, you>ll never have an algorithm that "perfectly compresses
everything" because even though your model is then very complete, it is
so complicated that you need to transmit too much data just to describe
it. You *cannot* win this game, it>s a logical constraint about maps
between finite sets, a very elementary one.
now say for two lengths of data, a shape for each.
now.. this might be a little harder to believe is right.
I>m not arguing at this level - you don>t seem to understand.
given a shape, and another shape, there is math to say the shape but
made different, to the other shape, where the math to say one shape
different to the other shape is smaller than the other shape. So
instead of saying two shapes, say one shape and the math to make the
shape different as the other shape.
All very well, but you still need data to describe this "different", and
you>ll soon find out (once you would dare to try to implement it) that
the overall byte budget required to describe this "different" is higher
than the byte budget you save by using this model, at least for *most* data.
If you don>t believe this, I urge you to implement your idea in an
algorithm and observe this yourself. Depending on the data set, the most
successful models are simple.
given a perfect idea of how this would work, shouldn>t it be that the
math has a 50% rightful claim of being smaller than the other shape,
and a 50% rightful claim of being bigger than the other shape?
Shouldn>t it though just to think of the most idea condition there
should be?
doesn>t that make sense when there could be some math smaller to say
one shape made to be changed is another shape, smaller than the other
shape? and some math bigger than the other shape? shouldn>t the idea
round off as a 50/50 of smaller and bigger than the other shape? to
say a shape changed is another shape.
It all makes sense to say so, but your algorithm also has to say so,
namely has to communicate this to the decoder. And *that* is where your
problem is.
Again, if you don>t believe me, construct this algorithm and you>ll see
yourself.
So long,
Thomas[/quote] |
|
| |
|
| Back to top |
Industrial One
Guest
|
| Posted: Tue Jul 29, 2008 5:52 am Post subject: Re: compression type |
|
|
On Jul 19, 10:34 pm, mcja...@gmail.com wrote:
[quote]On Jul 20, 12:04 am, Industrial One <industrial_...@hotmail.com
wrote:
On Jul 19, 2:03 pm, mcja...@gmail.com wrote:
why can>t compression be reducing reorganized patterns?
Any kind of pattern, direct or indirect is a redundancy. If you build
a compressor based on "reorganizing patterns" it would require
exhaustive processing and not compress significantly more than already-
existing LZW techniques. I thought like you once, when I noticed that
re-arranging paragraphs/sentences in many usenet posts would make it
way more redundant (cuz of all the quotes) but when I tested the idea
(by hand) on one thread and compared it to RAR, the gain was roughly
1.5%.
I think it misses the point of redundancy altogether though... it>s
calling abhcgdef dhbfcega dbfegcha acgdfbhe a curve about the same
size i guess if you say those letters in a sphere and make math that
draws a curve work through the letters as the token.
where those letters once in the sphere like abcdefgh is with a curve
line drawing across the letters for each way they are.. i see no
repeat occurances of a string occur there too good, but i see abcdefgh
once and a curve line in math like a few characters might be to be
each way those letters reorganize.
a very differerent proportion to see carefully.
i think if i were to try an algorithm to build this in a sphere i>d
just find the pattern maybe somewhat already there and carry on with
where the curve takes it for anything more to add that gets another
token... but given the idea of a sphere and curve just being silly at
it, it>s really for another way altogether to say it better.
[/quote]
That>s cool, but the problem is all the extensive processing it would
require. And when we talk about practical data to compress such as
common English text, all the side information representing your
mathematical curves n shit will cancel most of the benefits of your
exhaustive searching for less uniform redundancies. As I said, you
will beat modern LZW techniques by 1 or 2% and take 2 or 3x more time
to encode. Bad tradeoff.
[quote]but it has a fundementally different idea than reducing redundancy...
i don>t think that has to be the only way of compression working.
[/quote]
And it isn>t the only method around. It>s the most efficient as it
takes less than a minute and brings the size down close to the
entropical limit.
[quote]it>s finding a pattern reorganized, so nothing to do with reducing
redundancy at all.
see.. build in a sphere area the words or string parts but see how
the others built there too find another curve to be mostly anything
else needing a token sometimes?
it>s like so with not being redundancy reduction at all. it>s finding
a reorganization of a pattern say words in a sentence with any way to
be arranged being what says once to storing the words, and a token
many ways to say the words organized another way. it has no
equilivency to the idea of redundancy reduction at all if you think
what proportional difference this can be. for example how effective it
can be has nothing to do with how much redundancy there is. it>s
effective on account of how you can find a pattern part of another
pattern to be like saying what>s in both patterns once, but tokens
that say the pattern every which way. and most importantly to figure
what a proportion it has, it>s to find anything that>s not even part
of the pattern except some to be where a curve says that but the rest
as what>s already there.
see how that could of been compressed if every word showed up only
once in the sphere, but all to say about how it writes is curves that
draw through the sphere connecting the words... so just say math curve
designations in sphere area.it>s not just finding the longest strings
in common to be a token, it>s finding reorganized words. see it may
seem the same to say once a word and token it, but it>s not to say how
a sentence is backwards and forwards as what has the setence said once
but a different token. even though that>s a few tokens right instead?
that>s not a proportion that compares to the idea of how much
backwards what can be forwards the other way, but even not that way
but in the middle to be what has after it some of another pattern
already made for and before some of even another. like where you put
them in the sphere maybe?
it>s another proportion though besides what redundancy reduction can
even achieve in idea... because it>s not working with that limit of
seeing a pattern reorganized another way. see... it>s putting words
before and after the other way, but them to say other sentences any
way that has those words is to be only the part of the sentence that
isn>t those words before and after where in the sphere you draw a
curve that connects beginning, the middle part, then the end part as
what.
[/quote]
I follow you perfectly, and I>m tellin ya again: that is way too CPU
intensive and the benefits are minimal. If you got all this spare time
why don>t you dedicate it to video encoding. It>s still far from
complete. |
|
| |
|
| Back to top |
mcjason
Guest
|
| Posted: Tue Jul 29, 2008 10:42 am Post subject: Re: compression type |
|
|
On Jul 17, 8:24 am, mcja...@gmail.com wrote:
[quote]A primitive idea maybe?
from what I understand most compression techniques try to use
redundancy elimination as their main score. So take for example repeat
occurances of the same and give token of replica instead. What would
happen say if you placed in a geometric area all of what gives a
token, and said not token but geometric location as what happens to be
it? Pretty much it maybe if the token is always the same size to be
what works right? so what happens if you say in geometric area what
out to be instead of just what repeats itself a sequence of words say
for example that occur in different order what is neighbouring
eachother where you can say in geometric area a plot course that draws
a string pattern different ways as the token, to be crude as any
example words spaced in a sphere, with a curve that intersects the
words that find themself ordered other ways as the token to say.
so you may see this in a file:
the first sentence to see
another sentence like this
a good sentence to run on about
a final sentence to finish
to see another sentence
about a good sentence
but put the word "sentence" in this sphere, and surround all the words
that make each sentence so that all you do to token the whole sentense
is to draw say a curve in the sphere through each word as what you say
is the token, like math that makes the curve and where it starts. but
also see the word "see" and "good" once because they show up in more
than one sentence, find the curve to be at the same place for those
words as the token for those setences.
isn>t this no matter what the same as redundancy reduction done right?
it says at least the same doesn>t it? but has yet better potention to
say nothing worse but better? in idea? since token space is allowed to
be the same for what geometry there can be to say a place? but
extended for the idea of patterns that rearrange?
doesn>t this have a better theory to it altogether with what
rearranged patterns can be as what can be found common enough I
suppose.
[/quote]
Overall though isn>t compression usually finding the tradeoff to be at
an easy line to see...
a token for what repeats instead of each time it repeats, a token that
isn>t anything else said for real to be data but mixes with data that
can be anything, so a token the way it>s seperate from real data.
so the tradeoff is to find what is smaller to say a token for, for
what repeats, like how a token can mean something bigger than the
token.
so a token that>s worth it instead of the real data, is a token
smaller than the real data but said mixed with real data, a token that
means something bigger instead of the token.
so a tradeoff of how a token is worth saying the way a token can be
said, for what is bigger than the token it says, for what is found to
have repeat occurances that it>s better to have once what repeats and
a token for each time it repeats.
don>t most compression>s find that to be about right?
where it>s to say a token smaller than what it means, because the
token means something else, where the token is mixes with what doesn>t
have a token the way it>s actually a token and not real data taken as
not a token.
so it>s to find a ratio better of the idea... for what can have a
token instead, for how it is to say a token mixes with data, for how a
token is unique to each thing a token can mean, for how a token mixes
with real data is with real data that can take up the idea of what a
token can be, for what repeats as given a token how much it repeats
for how the token is smaller to say mixes with real data, to say what
repeats once for there to be a token for it. for what>s worth it.
so that>s as good a compression ratio they can have is around how that
idea works right?
I>m trying to find a way to say good how I think the idea I>m trying
to express is distinguishing from this idea very much...
it>s mostly trying to say how the size of a curve line doesn>t matter
as much for the idea of how the size of the blocks can be..
so there might be many small blocks like single characters, but then a
few big ones where the curved line makes a whole part out of them
together where the curved line is smaller.
but then it>s also how with those same parts you can add other parts,
and have another curved line say something else, but with using some
of the parts there already. and parts there already weren>t added
again. but now a curved line as the size says something like maybe
much bigger if parts there already can mostly add up to something with
only a few new parts.
how ultimately it>s like trying to say every word there is in
english.. but like this...
where every prefix/suffix/base word/etc is seperated... then put each
part in a sphere right? add a space in there.. numbers and stuff too.
draw a spiral curve in there where a whole sentence fits together...
but keep going though...
how much do you think the size of the spiral would get for the size of
how much it says to see each point from where the spiral begins?
but even yet.. say whole sentences or two words together that show up
too often as a single block, as better yet for what the size of the
spiral is.
see how it>s not even to think the spiral mixes with real data?
because if you make a sphere with parts and keep seperate from that
the spiral.
is anyone trying to see this right though for what it says....
"ewiruyweBBBBsdkjfbsadBBBBshfdsjkhnfsdBBBBsdfhksjBBBBsdjfhsdkjhfdBBBB"
so said like
"ewiruywe:BBBB:sdkjfbsad:shfdsjkhnfsd:sdfhksj:sdjfhsdkjhfd"
see how... see how for that it>s to say those blocks, but as
seperated?
once BBBB right? a part that repeats.
so now to say the whole string... it>s a curve that connects
"ewiruywe:BBBB:sdkjfbsad:shfdsjkhnfsd:sdfhksj:sdjfhsdkjhfd" parts
together....
so a curved line that does this...
from "ewiruywe" to "BBBB" to "sdkjfbsad" to "BBBB" to "shfdsjkhnfsd"
to "BBBB" to "sdfhksj" to "BBBB" to "sdjfhsdkjhfd" to "BBBB"
so see how the file compressed is saying each block, and a curved line
to connect the blocks?
see how though?
easy... I get it.
but now see this... ?
how big can this be for how many repeat occurances of BBBB there are ?
forever big right? so forever it can say that each BBBB is to have a
block seperated of before and after BBBB... right? but then it>s to
not add BBBB again.
that>s forever though... any size, that it>s to see this tradeoff of
making the file smaller...
if seperatating BBBB is to say a block seperated like before and
after, but then a curved line already so big to say the blocks
together so far, is a curved line made more to say another two
blocks,
then it>s to see in any size there can be more... only if seperating
before and after BBBB, not adding BBBB again, and saying the curved
line made more.. is smaller.
so if that>s always smaller what? is it to see that in size of data
being any size... that even one that that has repeat occurances can
make the whole file smaller for each repeat occurance... without the
pigeonhole problem? for how this works?
if the block sepearation and curved line is worth saying one less
"BBBB" for how much bigger that is... then it>s to take care of data
any size of repeating BBBB to make it smaller ? |
|
| |
|
| Back to top |
Jim Leonard
Guest
|
| Posted: Tue Jul 29, 2008 6:15 pm Post subject: Re: compression type |
|
|
On Jul 29, 5:42 am, mcjason <mcja...@gmail.com> wrote:
[quote]so if that>s always smaller what? is it to see that in size of data
being any size... that even one that that has repeat occurances can
make the whole file smaller for each repeat occurance... without the
pigeonhole problem? for how this works?
[/quote]
No.
Please get back on your meds. |
|
| |
|
| Back to top |
|
