Science and Technology news... :: View topic

mcjason · Guest

On Jul 17, 8:24 am, mcja...@gmail.com wrote:
[quote]A primitive idea maybe?

from what I understand mostcompressiontechniques 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]
For the point of what I tried saying about random...

since it can be said that any random data is compressed if you have a
software program with the same entropy source seed the generation of
random data, isn>t it the same to say that random carries no trend in
it>s nature against compressability?

Like, duh... isn>t the random generating software program just the
same as the random data compressed?

just to say though... because it>s enough to see what idea tries to be
about saying redundancy not found enough in random data is why it>s
"mathematically impossible?" to compress? just because it has few
repeat occurances worth giving a token about?

I hated that too...

am I maybe onto something when I say how reorganized patterns can
achieve a type of compression that should have no ordering against the
nature of random data?

there should be many instances of finding in random things like a few
characters together in groups that reorganize another way, but not all
of them reorganized another way but for some to be part of how another
pattern has some of another pattern.

""cherth church theater lightning ghost storm rover"
stored like
ch er th ur ea t lightning o st orm rov

and then space of a few tokens.

can you see how more this way doesn>t work like the pigeon hole
problem?

i would even say nothing but a sphere with blocks, and the rest as
tokens. because you can say just a sphere with 1 block and 1 token to
be only that overhead, but now to say better about a smaller size is
to only find a tradeoff that seems certain of catching a benefit with
random.

so no pigeon hole problem there at all actually... just the tradeoff
of token size and blocks broken apart.

I>m almost certain this achieves for random data.

mcjason · Guest

On Jul 23, 12:28 am, mcjason <mcja...@gmail.com> wrote:
[quote]On Jul 17, 8:24 am, mcja...@gmail.com wrote:

A primitive idea maybe?

from what I understand mostcompressiontechniques 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.

For the point of what I tried saying about random...

since it can be said that any random data is compressed if you have a
software program with the same entropy source seed the generation of
random data, isn>t it the same to say that random carries no trend in
it>s nature against compressability?

Like, duh... isn>t the random generating software program just the
same as the random data compressed?

just to say though... because it>s enough to see what idea tries to be
about saying redundancy not found enough in random data is why it>s
"mathematically impossible?" to compress? just because it has few
repeat occurances worth giving a token about?

I hated that too...

am I maybe onto something when I say how reorganized patterns can
achieve a type ofcompressionthat should have no ordering against the
nature of random data?

there should be many instances of finding in random things like a few
characters together in groups that reorganize another way, but not all
of them reorganized another way but for some to be part of how another
pattern has some of another pattern.

""cherth church theater lightning ghost storm rover"
stored like
ch er th ur ea t lightning o st orm rov

and then space of a few tokens.

can you see how more this way doesn>t work like the pigeon hole
problem?

i would even say nothing but a sphere with blocks, and the rest as
tokens. because you can say just a sphere with 1 block and 1 token to
be only that overhead, but now to say better about a smaller size is
to only find a tradeoff that seems certain of catching a benefit with
random.

so no pigeon hole problem there at all actually... just the tradeoff
of token size and blocks broken apart.

I>m almost certain this achieves for random data.- Hide quoted text -

- Show quoted text -
[/quote]
so it>s like saying that in data of any size no matter what, there>s a
benefit if it can be found to have a pattern that>s bigger than the
token be reorganized more than one way right?

like, in all of the data to compress... just find in all of it
"uiJKllnq" and also "KlluiB" to store "ui J K ll n q b", and then
anything more like "opqKb" stores only "op" more because now a token
can be for it with how the rest is there.

I like how it looks to put it all in a sphere area say, and have the
file 'content' only be tokens. like, the file content is only tokens
that draw a pattern organization plot.

mcjason · Guest

On Jul 17, 8:24 am, mcja...@gmail.com wrote:
[quote]A primitive idea maybe?

from what I understand mostcompressiontechniques 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]
and maybe the file format would be where at the beginning just say one
thing after the other the way each thing after another can only be
what starts in the center at rotates around what makes it so a curved
line maybe can also be draw to connect things to together? then the
rest of the file as just curved line tokens?

mcjason · Guest

On Jul 17, 8:24 am, mcja...@gmail.com wrote:
[quote]A primitive idea maybe?

from what I understand mostcompressiontechniques 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]
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...

Jim Leonard · Guest

On Jul 22, 8:53 pm, mcjason <mcja...@gmail.com> wrote:
[quote]where something like
ajkl12 and ajlk12 can be said another way, and another way to say is
less than what it takes to say one data block.
so a sphere with like "(data but not aj k, and 12: aj:k:12:
data)TOKENS"...
[/quote]
What is a "data block"? Data is not free. If you constrain your idea
of a "data block" to a single byte then you can see there is no space
savings.

Already you are disproving your own argument. You are saying that it
should be simple to represent:
"ajkl12"
in a different form with:
"(data but not aj k, and 12: aj:k:12: data)TOKENS"
which is clearly longer than the source data, unless you think you can
define it in less than 6 bytes (which you can>t).

Please research LZ77 so that you can see your method has already been
surpassed 30 years ago.

Jim Leonard · Guest

On Jul 23, 12:14 am, mcjason <mcja...@gmail.com> wrote:
[quote]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...
[/quote]
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_Compression-_Huffman_and_Arithmetic_Coding%2C_LZ77%2C_LZ78

http://www.fadden.com/techmisc/hdc/index.htm

Read these completely, and if you don>t understand the LZ77 portions,
find a different hobby.

mcjason · Guest

On Jul 23, 1:37 pm, Jim Leonard <MobyGa...@gmail.com> wrote:
[quote]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.
[/quote]
Hello?

I>d like to think I>m not doing a poor job approaching the idea of why
random might not be a challenge at all to compress, is this not
interesting for this discussion group?

Let me try to restate my idea....

I>m trying to explain how the idea of what I>m saying is fundamentally
different than any other compression I believe so.

It>s trying to be the idea of pattern reorganization, definitely not a
proportional comparison to redundancy reduction as it is to reduce
repeat occurances.

It>s actually so simple to think about, I believe I embraced the idea
of how it>s _almost definitely_ true to the idea of being good about
random.

I>d like to try to explain what tradeoff proportion the idea has...

so given no case at all of compression, say just the whole file as one
data block in the sphere, and 1 token of it. so a file with no
overhead to care about really for what matters, so the same size
abouts.

so now to think of any benefit of compressing, it>s to realize this:

- instead of one block,
like "loqenalqoq"
have the few blocks "l:o:q:ena" in geometric area, like say each
block is seperated by distance and locationed.
now for the token, say _a curved line_ that connects the blocks in
order. so curved line through each block like l-o-q-ena-l-q-o-q

so now storage is sized "loqena" bytes + size of curved line (like
beizer curve or something)

and now say more of the file to see has "hghalauiqen"
then it>s to store as more "h:g:h:a:ui:en"

but then in algorithm I suppose now the block "ena" can be made
"en", and the "a" portion dropped because there>s already an "a" block
to organize the "ena"
pattern.

and now another curve token, or to extend the curve token already
there.

- so as long as in data _ANY LENGTH_ there can be found _EVEN 1_
occurance of a pattern that is part of another pattern even, or
organizes another way, it>s to
claim a benefit. You can see the size of the token being funny too
for what there is to see about a tradeoff.

like, in data any length... once found "tyqi" and another time
found "tynnqi" and the rest of the file
would be like storing "REST0:ty:qi:REST1:REST2:nn" (no bigger), and
maybe even a curved line token the same size!

REST0 before "tyqi"
REST1 after "tyqi" until "tynnqi"
REST2 after tynnqi

now before there could have been one token for the whole file
content,
now there can be still one token as a curved line, but instead of
being for one place, it curves through
REST0:ty:qi:REST1:ty:nn:qi:REST2"

so now the size is.. well!

before: ("ALL")curved line
after: ("REST0:ty:qi:REST1:REST2:nn" <- size of "ALL" before negative
other "ty:qi")curved line

but some overhead to say more blocks.

so basically it>s to draw a pattern organization plot of blocks that
organize together as different patterns to piece together the file
content.

mcjason · Guest

On Jul 24, 1:46 pm, mcjason <mcja...@gmail.com> wrote:
[quote]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.

Hello?

I>d like to think I>m not doing a poor job approaching the idea of whyrandommight not be a challenge at all to compress, is this not
interesting for this discussion group?

Let me try to restate my idea....

I>m trying to explain how the idea of what I>m saying is fundamentally
different than any other compression I believe so.

It>s trying to be the idea of pattern reorganization, definitely not a
proportional comparison to redundancy reduction as it is to reduce
repeat occurances.

It>s actually so simple to think about, I believe I embraced the idea
of how it>s _almost definitely_ true to the idea of being good aboutrandom.

I>d like to try to explain what tradeoff proportion the idea has...

so given no case at all of compression, say just the whole file as one
data block in the sphere, and 1 token of it. so a file with no
overhead to care about really for what matters, so the same size
abouts.

so now to think of any benefit of compressing, it>s to realize this:

- instead of one block,
like "loqenalqoq"
have the few blocks "l:o:q:ena" in geometric area, like say each
block is seperated by distance and locationed.
now for the token, say _a curved line_ that connects the blocks in
order. so curved line through each block like l-o-q-ena-l-q-o-q

so now storage is sized "loqena" bytes + size of curved line (like
beizer curve or something)

and now say more of the file to see has "hghalauiqen"
then it>s to store as more "h:g:h:a:ui:en"

but then in algorithm I suppose now the block "ena" can be made
"en", and the "a" portion dropped because there>s already an "a" block
to organize the "ena"
pattern.

and now another curve token, or to extend the curve token already
there.

- so as long as in data _ANY LENGTH_ there can be found _EVEN 1_
occurance of a pattern that is part of another pattern even, or
organizes another way, it>s to
claim a benefit. You can see the size of the token being funny too
for what there is to see about a tradeoff.

like, in data any length... once found "tyqi" and another time
found "tynnqi" and the rest of the file
would be like storing "REST0:ty:qi:REST1:REST2:nn" (no bigger), and
maybe even a curved line token the same size!

REST0 before "tyqi"
REST1 after "tyqi" until "tynnqi"
REST2 after tynnqi

now before there could have been one token for the whole file
content,
now there can be still one token as a curved line, but instead of
being for one place, it curves through
REST0:ty:qi:REST1:ty:nn:qi:REST2"

so now the size is.. well!

before: ("ALL")curved line
after: ("REST0:ty:qi:REST1:REST2:nn" <- size of "ALL" before negative
other "ty:qi")curved line

but some overhead to say more blocks.

so basically it>s to draw a pattern organization plot of blocks that
organize together as different patterns to piece together the file
content.- Hide quoted text -

- Show quoted text -
[/quote]
I don>t think random has any trend against patterns that reorganize,
like it has against string reoccurances.

so in so much data the tradeoff of finding patterns that reorganize
starts to show a better gain than finding pattern parts
as string reoccurances. because "aa:bb:cc" is ccbbaa, aabbcc, bbccaa,
etc. and even part of "aaeegg"

mcjason · Guest

On Jul 23, 1:24 pm, Jim Leonard <MobyGa...@gmail.com> wrote:
[quote]On Jul 22, 8:53 pm, mcjason <mcja...@gmail.com> wrote:

where something like
ajkl12 and ajlk12 can be said another way, and another way to say is
less than what it takes to say one data block.
so a sphere with like "(data but not aj k, and 12: aj:k:12:
data)TOKENS"...

What is a "data block"? Data is not free. If you constrain your idea
of a "data block" to a single byte then you can see there is no space
savings.

Already you are disproving your own argument. You are saying that it
should be simple to represent:
"ajkl12"
in a different form with:
"(data but not aj k, and 12: aj:k:12: data)TOKENS"
which is clearly longer than the source data, unless you think you can
define it in less than 6 bytes (which you can>t).

Please research LZ77 so that you can see your method has already been
surpassed 30 years ago.
[/quote]
one token about the same size might as well cover fewer or lesser
parts of what organizes together.

Jim Leonard · Guest

On Jul 24, 12:46 pm, mcjason <mcja...@gmail.com> wrote:
[quote]I>d like to think I>m not doing a poor job approaching the idea of why
random might not be a challenge at all to compress, is this not
interesting for this discussion group?
[/quote]
Not when you are ignoring what we>re saying when trying to help you.

[quote]I>m trying to explain how the idea of what I>m saying is fundamentally
different than any other compression I believe so.
[/quote]
It>s not. I just told you why in a previous post; I guess you don>t
bother reading posts.

[quote]so basically it>s to draw a pattern organization plot of blocks that
organize together as different patterns to piece together the file
content.
[/quote]
THIS HAS ALREADY BEEN DONE IN PREVIOUS METHODS INVENTED 30 YEARS AGO.
Was that clear enough? What you describe is no different than the
match/offset codes used in LZ77, with the exception that LZ77 is more
efficient than what you have been describing.

Until you can accurately describe LZ77, and how your method exceeds it
for all test cases, please stop posting about your idea.

mcjason · Guest

On Jul 24, 2:08 pm, Jim Leonard <MobyGa...@gmail.com> wrote:
[quote]On Jul 24, 12:46 pm, mcjason <mcja...@gmail.com> wrote:

I>d like to think I>m not doing a poor job approaching the idea of why
random might not be a challenge at all to compress, is this not
interesting for this discussion group?

Not when you are ignoring what we>re saying when trying to help you.

I>m trying to explain how the idea of what I>m saying is fundamentally
different than any other compression I believe so.

It>s not. I just told you why in a previous post; I guess you don>t
bother reading posts.

so basically it>s to draw a pattern organization plot of blocks that
organize together as different patterns to piece together the file
content.

THIS HAS ALREADY BEEN DONE IN PREVIOUS METHODS INVENTED 30 YEARS AGO.
[/quote]

Only if the idea of pattern reorganization you>re think about about is
to land the redundant portions in locations that are better
found with match/offset codes... what I>m talking about here is _very
different_!

I>m supposing the idea that portions of the file that can be broken
apart and reorganized in different ways.
say "not a long string" is found to be the data to compress...
then it>s to store "not a long string" as any of these ways...

- "not:a:long:string"
also "a string long"
also "not a string"
also just "not a long"

- "n:ot:a:lo:g:stri:n"
also "got log lot"

- "no:t:a:lo:ng:s:r:i"
also "nostalgia"

- "n:o:t:a:l:ng:stri"
also "nostril tang"

- "not:a:lo:ng:stri"

- "n:o:t:a:l:g:s:ri"
also "analog"
also "tall snot"
also "latta nosrita"

"no:t:a:lo:ng:s:tri:ng"

[quote]Was that clear enough? What you describe is no different than the
match/offset codes used in LZ77, with the exception that LZ77 is more
efficient than what you have been describing.
[/quote]

I think you>re giving too much credit here to the idea of thinking
compression just works the way that is good, from what I gather of how
that tries to contradicts the example I>m trying to make of how
pattern reorganization is actually a completely different idea
altogether, that has nothing to do with having to find repeat
occurances
of the same thing said to be better at saying what should be taken as
less to say more.

[quote]
Until you can accurately describe LZ77, and how your method exceeds it
for all test cases, please stop posting about your idea.
[/quote]
I think you>re using a sliding window to see something else.

So each of the next characters is exactly equilivent to the characters
found at an offset difference behind where we>re at.

It may be only to find how repeating an example tries to say something
else mostly that gets stuck at only being a little less than the more
it has, because although
some was said as part of something else and the rest can>t be found as
anything but new, it>s to find in part what is mostly said another way
that already got eliminated
as a part found in something else that looked better in another
example of where it was.

mcjason · Guest

On Jul 25, 2:30 am, mcjason <mcja...@gmail.com> wrote:
[quote]On Jul 24, 2:08 pm, Jim Leonard <MobyGa...@gmail.com> wrote:

On Jul 24, 12:46 pm, mcjason <mcja...@gmail.com> wrote:

I>d like to think I>m not doing a poor job approaching the idea of why
random might not be a challenge at all to compress, is this not
interesting for this discussion group?

Not when you are ignoring what we>re saying when trying to help you.

I>m trying to explain how the idea of what I>m saying is fundamentally
different than any other compression I believe so.

It>s not. I just told you why in a previous post; I guess you don>t
bother reading posts.

so basically it>s to draw a pattern organization plot of blocks that
organize together as different patterns to piece together the file
content.

THIS HAS ALREADY BEEN DONE IN PREVIOUS METHODS INVENTED 30 YEARS AGO.

Only if the idea of pattern reorganization you>re think about about is
to land the redundant portions in locations that are better
found with match/offset codes... what I>m talking about here is _very
different_!

I>m supposing the idea that portions of the file that can be broken
apart and reorganized in different ways.
say "not a long string" is found to be the data to compress...
then it>s to store "not a long string" as any of these ways...

- "not:a:long:string"
also "a string long"
also "not a string"
also just "not a long"

- "n:ot:a:lo:g:stri:n"
also "got log lot"

- "no:t:a:lo:ng:s:r:i"
also "nostalgia"

- "n:o:t:a:l:ng:stri"
also "nostril tang"

- "not:a:lo:ng:stri"

- "n:o:t:a:l:g:s:ri"
also "analog"
also "tall snot"
also "latta nosrita"

"no:t:a:lo:ng:s:tri:ng"

Was that clear enough? What you describe is no different than the
match/offset codes used in LZ77, with the exception that LZ77 is more
efficient than what you have been describing.

I think you>re giving too much credit here to the idea of thinking
compression just works the way that is good, from what I gather of how
that tries to contradicts the example I>m trying to make of how
pattern reorganization is actually a completely different idea
altogether, that has nothing to do with having to find repeat
occurances
of the same thing said to be better at saying what should be taken as
less to say more.

Until you can accurately describe LZ77, and how your method exceeds it
for all test cases, please stop posting about your idea.

I think you>re using a sliding window to see something else.

So each of the next characters is exactly equilivent to the characters
found at an offset difference behind where we>re at.

It may be only to find how repeating an example tries to say something
else mostly that gets stuck at only being a little less than the more
it has, because although
some was said as part of something else and the rest can>t be found as
anything but new, it>s to find in part what is mostly said another way
that already got eliminated
as a part found in something else that looked better in another
example of where it was.- Hide quoted text -

- Show quoted text -
[/quote]
Maybe people can see this isn>t even in the same line of thinking as
where the idea of a piegonhole problem can be seen?

It>s to see as only as the content inside a sphere, and curved lines
through it to say how it comes together that way.

I>m feeding off an area that has parts that come together to say what
makes sense of what>s plainspoken the way that parts can come together
many ways, and I>m always finding parts to come together to say
something different many ways, but with so many parts to put together
as what can only get a little harder, and ways to put them together
that only gets a little more complicated, it>s seeing how the stuffing
is without the pigeonhole problem the way only so much fits explaining
well for what I understand of how to say it better. It>s try over and
over again even and still find a pattern that can be said smaller as
better that might be the outstanding difference to see. I>d probably
find a pattern after a while that doesn>t say much different than
being a pattern too complicated to see smaller.

Thomas Richter · Guest

mcjason schrieb:

[quote]
Hello?
[/quote]
Hello, hello? Someone home?

[quote]I>d like to think I>m not doing a poor job approaching the idea of why
random might not be a challenge at all to compress, is this not
interesting for this discussion group?
[/quote]
NO, it isn>t, you>re wasting bandwidth by repeating endlessly. You have
homework to do, so please do. There are things you have to *read* first
(seriously!), and a couple of questions you must become clear about. All
this has been mentioned before, by other people.

o) Read about LZ77. Even if you *think right now* it is unrelated to
your idea, nevertheless read it. There is nothing you must be afraid of,
please do and then(!) think about it. The best you can do is actually
work LZ77 out in one example yourself (emulating the machine by pen and
paper.) I>m serious.

o) Please think about what "random" actually means. Your concepts are
still not cleaned up.

[quote]It>s trying to be the idea of pattern reorganization, definitely not a
proportional comparison to redundancy reduction as it is to reduce
repeat occurances.

It>s actually so simple to think about, I believe I embraced the idea
of how it>s _almost definitely_ true to the idea of being good about
random.
[/quote]
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.

[quote]- instead of one block,
like "loqenalqoq"
have the few blocks "l:o:q:ena" in geometric area, like say each
block is seperated by distance and locationed.
now for the token, say _a curved line_ that connects the blocks in
order. so curved line through each block like l-o-q-ena-l-q-o-q
[/quote]
Which is, in a nutshell, LZ77/LZ78 in a variant. It separates patterns
into blocks, locating the the longest possible substring in its
dictionary and adds the pattern plus its extension to the dictionary.

[quote]so now storage is sized "loqena" bytes + size of curved line (like
beizer curve or something)
[/quote]
Just consider: How much data do you need to describe the curve (just
estimate!) LZ77 is simpler, it stores (entropy encoded) a
length/distance pair. If you would think about it, you>ll find that the
parameters describing your curve are pretty long compared to what the LZ
variants do.

[quote]and now say more of the file to see has "hghalauiqen"
then it>s to store as more "h:g:h:a:ui:en"
[/quote]
Separating data in blocks is an elementary feature of all the lookalikes
of LZ.

[quote]but then in algorithm I suppose now the block "ena" can be made
"en", and the "a" portion dropped because there>s already an "a" block
to organize the "ena"
pattern.

and now another curve token, or to extend the curve token already
there.
[/quote]
And you still have to store those instructions to the decoder. Well,
fine then, but note that you need to allocate rate (file size) to do so,
and while storing an "a" takes one byte, how many bytes does it take to
describe the curve? That rate isn>t for free!

[quote]- so as long as in data _ANY LENGTH_ there can be found _EVEN 1_
occurance of a pattern that is part of another pattern even, or
organizes another way, it>s to
claim a benefit. You can see the size of the token being funny too
for what there is to see about a tradeoff.

like, in data any length... once found "tyqi" and another time
found "tynnqi" and the rest of the file
would be like storing "REST0:ty:qi:REST1:REST2:nn" (no bigger), and
maybe even a curved line token the same size!

REST0 before "tyqi"
REST1 after "tyqi" until "tynnqi"
REST2 after tynnqi

now before there could have been one token for the whole file
content,
now there can be still one token as a curved line, but instead of
being for one place, it curves through
REST0:ty:qi:REST1:ty:nn:qi:REST2"

so now the size is.. well!
[/quote]
No, the data you gave is insufficient for the decoder. You *also* need
to describe the curves, which takes more rate; which is exactly why you
won>t be able to compress "random" data at all.

[quote]before: ("ALL")curved line
after: ("REST0:ty:qi:REST1:REST2:nn" <- size of "ALL" before negative
other "ty:qi")curved line

but some overhead to say more blocks.

so basically it>s to draw a pattern organization plot of blocks that
organize together as different patterns to piece together the file
content.
[/quote]
Actually, do you read our posts here? Hello? Anybody home?

So long,
Thomas

Willem · Guest

mcjason wrote:
) <a lot of nonsense, repeated over and over>

I notice you have chosen to completely ignore my posts about how
'compression' and 'redundancy reduction' are two phrases for the same
thing.

Furthermore, I notice that must of your replies are in the line of
'but my method is completely different' followed by the umpteenth
explanation of 'your method', without acrtually addressing the points
that are made. You sound like a broken record.

Are you trolling, or just plain stupid ? My vote is on trolling.
(The bit about 'random' kinda gives it away.)

SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I>m not paranoid. You all think I>m paranoid, don>t you !
#EOT

mcjason · Guest

On Jul 25, 2:59 am, Thomas Richter <t...@math.tu-berlin.de> wrote:
[quote]mcjason schrieb:

Hello?

Hello, hello? Someone home?

I>d like to think I>m not doing a poor job approaching the idea of why
random might not be a challenge at all to compress, is this not
interesting for this discussion group?

NO, it isn>t, you>re wasting bandwidth by repeating endlessly. You have
homework to do, so please do. There are things you have to *read* first
(seriously!), and a couple of questions you must become clear about. All
this has been mentioned before, by other people.

o) Read about LZ77. Even if you *think right now* it is unrelated to
your idea, nevertheless read it. There is nothing you must be afraid of,
please do and then(!) think about it. The best you can do is actually
work LZ77 out in one example yourself (emulating the machine by pen and
paper.) I>m serious.

o) Please think about what "random" actually means. Your concepts are
still not cleaned up.

It>s trying to be the idea of pattern reorganization, definitely not a
proportional comparison to redundancy reduction as it is to reduce
repeat occurances.

It>s actually so simple to think about, I believe I embraced the idea
of how it>s _almost definitely_ true to the idea of being good about
random.

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.
[/quote]
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.

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. 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.

it>s to say this proves how random is compressable, take it whatever
way you want I know it>s right.

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.

now say for two lengths of data, a shape for each.

now.. this might be a little harder to believe is right.

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.

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.

so now if "BLUE" is a box shape, and "RED" is almost a box shape
punched in the corner so hard. I can store a box shape, and how hard
to punch the box in the corner.

I think this strongly debates the idea of how random is compressable.

Or you can just think the software that makes for random data is the
random data itself compressed if you run it the same way.

I think given at least that, there>s nothing to think about at all
when it comes to how random is compressable except the restrictions of
redundancy reduction>s way of reducing repeat occurances, that is MOST
CERTAINLY not the only way to compress information.
The pigeonhole problem can find it>s way there too.

[quote]
- instead of one block,
like "loqenalqoq"
have the few blocks "l:o:q:ena" in geometric area, like say each
block is seperated by distance and locationed.
now for the token, say _a curved line_ that connects the blocks in
order. so curved line through each block like l-o-q-ena-l-q-o-q

Which is, in a nutshell, LZ77/LZ78 in a variant. It separates patterns
into blocks, locating the the longest possible substring in its
dictionary and adds the pattern plus its extension to the dictionary.

so now storage is sized "loqena" bytes + size of curved line (like
beizer curve or something)

Just consider: How much data do you need to describe the curve (just
estimate!) LZ77 is simpler, it stores (entropy encoded) a
length/distance pair. If you would think about it, you>ll find that the
parameters describing your curve are pretty long compared to what the LZ
variants do.
[/quote]
How many blocks to organize together can a curve draw through?

[quote]
and now say more of the file to see has "hghalauiqen"
then it>s to store as more "h:g:h:a:ui:en"

Separating data in blocks is an elementary feature of all the lookalikes
of LZ.

but then in algorithm I suppose now the block "ena" can be made
"en", and the "a" portion dropped because there>s already an "a" block
to organize the "ena"
pattern.

and now another curve token, or to extend the curve token already
there.

And you still have to store those instructions to the decoder. Well,
fine then, but note that you need to allocate rate (file size) to do so,
and while storing an "a" takes one byte, how many bytes does it take to
describe the curve? That rate isn>t for free!

- so as long as in data _ANY LENGTH_ there can be found _EVEN 1_
occurance of a pattern that is part of another pattern even, or
organizes another way, it>s to
claim a benefit. You can see the size of the token being funny too
for what there is to see about a tradeoff.

like, in data any length... once found "tyqi" and another time
found "tynnqi" and the rest of the file
would be like storing "REST0:ty:qi:REST1:REST2:nn" (no bigger), and
maybe even a curved line token the same size!

REST0 before "tyqi"
REST1 after "tyqi" until "tynnqi"
REST2 after tynnqi

now before there could have been one token for the whole file
content,
now there can be still one token as a curved line, but instead of
being for one place, it curves through
REST0:ty:qi:REST1:ty:nn:qi:REST2"

so now the size is.. well!

No, the data you gave is insufficient for the decoder. You *also* need
to describe the curves, which takes more rate; which is exactly why you
won>t be able to compress "random" data at all.
[/quote]

I imagine this idea....

If there was a big sphere, inside this sphere are many pieces of the
puzzle to put the file together.
Near er is amp, p, ack, tr, and age because the words pack and
amperage come together.
Near amp already in the sphere is cr, and l because the words cramp
and crack come together.
Near cr already in the sphere is im, and son, because the words
crimson and trim come together.
Near ack already in the sphere is att, because the word attacker come
toghther.

Now try putting more in the sphere for more data...

then it>s to say for example "try improving" to store is only
"y:oving" as more to keep and a curve to either extend or add.

[quote]
before: ("ALL")curved line
after: ("REST0:ty:qi:REST1:REST2:nn" <- size of "ALL" before negative
other "ty:qi")curved line

but some overhead to say more blocks.

so basically it>s to draw a pattern organization plot of blocks that
organize together as different patterns to piece together the file
content.

Actually, do you read our posts here? Hello? Anybody home?

So long,
Thomas- Hide quoted text -

- Show quoted text -[/quote]


www.GetXFactor.com Leading Technology, Science, Agriculture News and information	Part of the Identityscape.com network... getxfactor.com jmoodmusic.com smartbusinesschoices.com mintdepot.com lowfaresalways.com evangelicalview.com shoppingpodder.com soproudlywehail.com webnews.ws currenthumor.com

Science and Technology news... Forum Index -> Compression Forum	Goto page Previous 1, 2, 3, 4, 5, 6 Next
Page 4 of 6