Ce n’est pas réel, c’est inventé.

Les algorithmes de compression de données sans perte ne peuvent pas garantir la compression de tous les ensembles de données d’entrée. En d’autres termes, pour tout algorithme de compression de données sans perte, il y aura un ensemble de données d’entrée qui ne devient pas plus petit lorsqu’il est traité par l’algorithme, et pour tout algorithme de compression de données sans perte qui réduit au moins un fichier, il y aura au moins un fichier qu’il agrandit. Ceci est facilement prouvé avec les mathématiques élémentaires en utilisant un argument de comptage, comme suit:

Supposons que chaque fichier est représenté comme une chaîne de bits d’une longueur arbitraire.Supposons qu’il existe un algorithme de compression qui transforme chaque fichier en un fichier de sortie qui n’est pas plus long que le fichier d’origine et qu’au moins un fichier soit compressé dans un fichier de sortie plus court que le fichier d’origine.

Soit M le plus petit nombre tel qu’il existe un fichier F de longueur M bits qui se compresse en quelque chose de plus court. Soit N la longueur (en bits) de la version compressée de F.

Parce que N<M, chaque fichier de longueur N conserve sa taille lors de la compression. Il y a 2N de tels fichiers. Avec F, cela fait 2N + 1 fichiers qui se compressent tous dans l’un des 2N fichiers de longueur N.

Mais 2N est plus petit que 2N + 1, donc selon le principe du trou de cochon, il doit y avoir un fichier de longueur N qui est simultanément la sortie de la fonction de compression sur deux entrées différentes. Ce fichier ne peut pas être décompressé de manière fiable (lequel des deux originaux devrait-il donner?), ce qui contredit l’hypothèse selon laquelle l’algorithme était sans perte.

Il faut donc conclure que notre hypothèse d’origine (selon laquelle la fonction de compression ne fait plus de fichier) est nécessairement fausse.

https://en.wikipedia.org/wiki/Lossless_compression#Limitations

https://en.wikipedia.org/wiki/Kolmogorov_complexity