Talk:Incompressible string

Comments

This page really needs to be rewritten or deleted. The use of first person is abundant and ridiculous.

I may or may not have misunderstood the thing, but the last example 1234999988884321 should be compressible with the RunLengthEncoding-algorithm of Tsukyama, which sees characters appearing twice as "escape-character" (or run value) and needs an additional character to store, how often to repeat: This would lead to: 1234 99(escape-runvalue) 2(run length) 88(Escape-runvalue) 2(run) 4321

So compression would be possible by 2 characters: 1234999988884321 12349928824321 When decompressing, you look for characters(run-values) that appear twice and interpret the next character as how often to repeat this respecitve character(run) 88 2 becomes 88 88, 99 2 becomes 9999. Anyone who can confirm this is correct, before I add this into the article?

References

Strings are only incompressible with regard to a particular compression algorithm

Other than the empty string, it's untrue that there are any universally incompressible strings. As shown in the Kolmogorov complexity page, which was linked to in this article as support for that incorrect position:

A random string in this sense is "incompressible" in that it is impossible to "compress" the string into a program whose length is shorter than the length of the string itself. A counting argument is used to show that, for any universal computer, there is at least one algorithmically random string of each length. Whether any particular string is random, however, depends on the specific universal computer that is chosen.

As can be seen, that article doesn't allow for incompressibility regardless of algorithm. It's clear that whether a string is incompressible depends on the algorithm chosen. — Olathe (talk) 03:32, 19 January 2017 (UTC)

Agreed. Inompressibity entirely depends upon the scope (or context) of a given algorithm. 20040302 (talk) 13:16, 17 August 2018 (UTC)