Les données peuvent-elles être compressées à une taille inférieure à la limite de compression des données de Shannon?

Je lisais sur les algorithmes de compression des données et la limite théorique pour la compression des données. Récemment, j'ai rencontré une méthode de compression appelée "Combinatorial Entropy Encoding", l'idée principale de cette méthode est de coder le fichier comme les caractères présentés dans le fichier, leurs fréquences et l'indice de permutation de ces caractères représentés par le fichier.

Ces documents peuvent aider à expliquer cette méthode:

https://arxiv.org/pdf/1703.08127

http://www-video.eecs.berkeley.edu/papers/vdai/dcc2003.pdf

https://www.thinkmind.org/download.php?articleid=ctrq_2014_2_10_70019

Cependant, dans le premier document, j'ai lu qu'en utilisant cette méthode, ils pouvaient compresser du texte à moins que la limite de Shannon (Ils n'ont pas considéré l'espace nécessaire pour enregistrer la fréquence des caractères et l'espace nécessaire pour enregistrer la méta données du fichier). J'y ai pensé et j'ai trouvé que cette méthode ne serait pas très efficace pour les très petits fichiers mais d'un autre côté elle pourrait bien fonctionner avec des fichiers volumineux. En fait, je ne comprends pas très bien cet algorithme ou la limite de Shannon, je sais juste que c'est la somme de la probabilité de chaque caractère multipliée par de l'inverse de la probabilité.$log_2$

J'ai donc quelques questions:

1. Cette méthode de compression comprime-t-elle vraiment les fichiers à une taille inférieure à la limite de Shannon?

2. Existe-t-il un algorithme de compression qui comprime les fichiers à moins que la limite de Shannon (la réponse à cette question pour autant que je sache est non)?

3. Une méthode de compression qui compresse des fichiers à une taille inférieure à la limite de Shannon peut-elle exister?

4. Si le codage combinatoire comprime vraiment les fichiers au-delà de la limite de Shannon, n'est-il pas possible de compresser le fichier encore et encore jusqu'à ce que nous atteignions la taille de fichier souhaitée?

En fait, je ne comprends pas très bien cet algorithme ou la limite de Shannon, je sais juste que c'est la somme de la probabilité de chaque caractère multipliée par log2 de l'inverse de la probabilité.

C'est là que réside le nœud. La limite de Shannon n'est pas une propriété universelle d'une chaîne de texte. C'est la propriété d'une chaîne de texte plus un modèle qui fournit des probabilités (éventuellement dépendantes du contexte) des symboles. Il nous indique dans quelle mesure ce modèle peut compresser le texte, en supposant que le modèle est précis .

Si vous utilisez un modèle pour calculer la limite de Shannon, puis un autre modèle pour compresser, si le deuxième modèle est plus précis, vous pouvez battre la limite de Shannon d'origine que vous aviez calculée, mais ce n'est pas vraiment pertinent.

Il est trivialement simple de montrer que vous pouvez compresser en dessous de la limite de Shannon - prenez un compresseur de triche qui a un tas de fichiers communs assignés aux jetons. Ces fichiers sont stockés en tant que ces jetons. (De toute évidence, le compresseur doit être très volumineux ou s'appuyer sur une très grande bibliothèque.)

Le compresseur sera intrinsèquement moins efficace pour traiter tout fichier qui n'est pas dans sa bibliothèque, car il doit en quelque sorte distinguer un jeton d'une compression normale.

Ce que vous ne pouvez pas faire, c'est avoir un compresseur qui dépasse la limite de Shannon sur tous les fichiers .

$1/2$, $1/3$, $1/6$. Ensuite, pour encoder chaque symbole avec probabilité$p$, vous avez besoin $log_2(1/p)$morceaux. Et étant donné un modèle particulier, vous ne pouvez pas compresser les données mieux que l'entropie de Shannon des probabilités produites par ce modèle particulier.

Mais si vous appliquez un autre modèle, vous obtiendrez une autre séquence de probabilités. Fe la lettre "u" est plutôt rare, donc sa probabilité sur tout le texte peut être de 3%, et c'est la probabilité que vous devez assigner à cette lettre en utilisant un modèle de Markov d'ordre 0 .

Mais dans les textes anglais, après "q" vient généralement un "u", donc en utilisant un modèle d'ordre 1, vous pouvez attribuer une probabilité beaucoup plus élevée à "u" après "q", améliorant ainsi le taux de compression.

De plus, certains modèles produisent moins de symboles qu'il n'y en a de saisis, par exemple LZ77 remplace les répétitions de texte par des références arrières, donc "abababab" devient "ab [2,8]".

Lorsque quelqu'un parle de l'entropie de Shannon de certaines données plutôt que des données compressées par un modèle particulier, elle signifie généralement l'entropie de Shannon produite par un modèle d'ordre 0, c'est-à-dire en attribuant à chaque symbole sa probabilité sur l'ensemble du texte. De toute évidence, vous pouvez battre cette marge en appliquant un modèle plus sophistiqué aux données.

Une autre interprétation possible du texte: l'algorithme de compression donné va vous donner une meilleure compression de certains textes, et une pire compression sur d'autres. Cependant, les utilisateurs se soucient généralement de certains types de fichiers (pages HTML en anglais, code machine 80386) plus que d'autres (tableaux de nombres vraiment aléatoires, bruit insignifiant sélectionné pour minimiser la répétition). Tout schéma de compression va se révéler meilleur pour compresser les données du monde réel et pire qu'inutile pour compresser certains autres types de chaînes.