Compactação de dados usando números primos

22

Recentemente, deparei com o seguinte artigo interessante, que afirma compactar com eficiência conjuntos de dados aleatórios sempre em mais de 50%, independentemente do tipo e formato dos dados.

Basicamente, ele usa números primos para construir exclusivamente uma representação de blocos de dados de 4 bytes que são fáceis de descompactar, pois cada número é um produto exclusivo de números primos. Para associar essas seqüências aos primos, utiliza um dicionário.

Minha pergunta é:

  • Isso é realmente viável, como sugerem os autores? Segundo o artigo, seus resultados são muito eficientes e sempre compactam dados em um tamanho menor. O tamanho do dicionário não será enorme?
  • Não foi possível usar isso para comprimir iterativamente os dados compactados usando o mesmo algoritmo? É óbvio, e foi demonstrado, que tais técnicas (onde os dados compactados são compactados novamente tantas vezes quanto possível, reduzindo drasticamente o tamanho do arquivo) são impossíveis; de fato, não haveria bijeção entre o conjunto de todos os dados aleatórios e os dados compactados. Então, por que isso parece possível?
  • Mesmo que a técnica ainda não esteja perfeita, ela pode obviamente ser otimizada e fortemente aprimorada. Por que isso não é mais conhecido / estudado? Se essas afirmações e resultados experimentais são verdadeiros, isso não revolucionaria a computação?
Klangen
fonte
5
Como você observou, o jornal está fazendo reivindicações muito fortes. Sempre desconfie de tais afirmações, especialmente se o artigo for publicado em um local estranho (artigos incríveis "revolucionando a computação" devem aparecer em locais conhecidos e respeitados, certo?).
Juho 21/07
2
é impossível "sempre comprimir dados aleatórios" com base, por exemplo, na teoria da complexidade de Kolmogorov . e uma reprovação é semelhante a como você esboçou. não tenho certeza se isso é uma interpretação incorreta do papel ou do papel original. por que você não destaca onde essa afirmação específica entra?
vzn
6
"Não foi possível usar isso para comprimir iterativamente os dados compactados usando o mesmo algoritmo?" - Sim. Qualquer algoritmo que afirma ser capaz de compactar todos os dados arbitrários pode ser aplicado recursivamente à sua própria saída, de modo que qualquer dado seja compactado em 0 bits. Assim, essa afirmação é impossível.
Jörg W Mittag
1
@ JörgWMittag Eu tenho um algoritmo que permite comprimir um arquivo repetidamente para um pequeno número de bits, mas é extremamente impraticável. Também funciona apenas com arquivos que começam com 1 bit: trate o arquivo inteiro como um número binário grande, diminua-o e descarte os zeros à esquerda. Para descompactar, aumente-o, adicionando um 1 inicial, se necessário.
user253751
3
Nota pessoal: não se preocupe em enviar trabalhos para qualquer periódico da Elsevier - nunca.
500 - Erro interno do servidor

Respostas:

34

sempre comprima conjuntos de dados aleatórios em mais de 50%

Isso é impossível. Você não pode compactar dados aleatórios , precisa de alguma estrutura para aproveitar. A compactação deve ser reversível; portanto, você não pode comprimir tudo em 50% porque há muito menos cadeias de comprimento do que as de comprimento n .n/2n

Existem alguns problemas importantes com o documento:

  • Eles usam 10 arquivos de teste sem qualquer indicação de seu conteúdo. Os dados são realmente aleatórios? Como eles foram gerados?

  • Eles afirmam atingir taxas de compactação de pelo menos 50%, enquanto seus dados de teste mostram que atingem no máximo 50%.

Este algoritmo define uma estratégia sem perdas que utiliza os números primos presentes no sistema de números decimais

  • O que? Números primos são números primos, independentemente da base.

  • Problema nº 1 com descompressão: a fatoração primária é um problema difícil, como eles fazem isso com eficiência?

  • Problema # 2 com descompressão ( este é o kicker ): eles multiplicam os números primos juntos, mas, assim, você perde qualquer informação sobre a ordem, pois . Eu não acho que é possível descomprimir usando a técnica deles.25=10=52

Não acho que este artigo seja muito bom.

Tom van der Zanden
fonte
Pelo que entendi, eles armazenam a ordem das strings com a mesma multiplicidade no dicionário. Mas em conjuntos de dados aleatórios, isso não deveria gerar um dicionário enorme, já que existem muitas seqüências de 4 bytes com multiplicidade 1 (ou igual multiplicidade)?
Klangen
@Pickle No exemplo deles, a string "@THE" tem multiplicidade 2. Não vejo como eles podem reconstruir em quais dois lugares a palavra "the" deve ir.
Tom van der Zanden
1
Ah entendo. Boa observação. Na verdade, esse é um grande problema. Como esse artigo foi aceito para aparecer na revista? Não deveria haver uma revisão por pares mais rigorosa?
Klangen 21/07
4
@ Pickle Sim, deve haver uma revisão mais rigorosa. Mas nem sempre é esse o caso, às vezes os organizadores de conferências inexperientes / preguiçosos / incompetentes não conseguem encontrar revisores por pares a tempo. Existem várias ocorrências de artigos contendo trechos gerados aleatoriamente sendo aceitos, e um periódico até publicou um artigo intitulado "Tire-me da porra da sua lista de endereços" .
Tom van der Zanden
Hahaha isso é incrível. Mas triste ao mesmo tempo.
Klangen
15

Vou adiar Tom van der Zanden, que parece ter lido o jornal e descoberto uma fraqueza no método. Embora eu não tenha lido o artigo em detalhes, partindo do resumo e da tabela de resultados, parece uma reivindicação amplamente crível.

O que eles afirmam é uma taxa de compactação consistente de 50% em arquivos de texto (não "todos os arquivos"), que eles observam ser quase o mesmo que LZW e cerca de 10% pior que a codificação Huffman (presumivelmente de ordem zero). Não é difícil conseguir compactar arquivos de texto em 50% usando métodos razoavelmente simples; é um trabalho de graduação em muitos cursos de ciência da computação.

Concordo que o artigo não seja muito bom como pesquisa publicada e não acho que seja bom para os revisores que isso foi aceito. Além dos óbvios detalhes ausentes que impossibilitam a reprodução dos resultados (por exemplo, quais eram os arquivos de texto) e nenhuma tentativa de vinculá-lo ao campo de compressão, não há sentido de que eles realmente entendam o que seu algoritmo está fazendo.

O site da conferência reivindica uma taxa de aceitação de 1: 4, o que faz você se perguntar o que eles rejeitaram.

Pseudônimo
fonte
12

Você pergunta:

  • Isso é realmente possível, como sugerem os autores? Segundo o artigo, seus resultados são muito eficientes e sempre compactam dados em um tamanho menor. O tamanho do dicionário não será enorme?

Sim, claro. Mesmo para o exemplo escolhido a dedo ("A RAPOSA PRATA RÁPIDA SALTA SOBRE O CÃO PREGUIÇOSO"), eles não obtêm compactação, porque o dicionário contém todas as subseqüências de 4 bytes do texto (menos 4 bytes para a repetição de " THE ") ... e a versão" compactada "do texto devem incluir todo o dicionário mais toda essa porcaria de números primos.

  • Não foi possível usar isso para comprimir iterativamente os dados compactados usando o mesmo algoritmo? É óbvio, e foi demonstrado, que tais técnicas (onde os dados compactados são compactados novamente tantas vezes quanto possível, reduzindo drasticamente o tamanho do arquivo) são impossíveis; de fato, não haveria bijeção entre o conjunto de todos os dados aleatórios e os dados compactados. Então, por que isso parece possível?

Novamente, você parece ter uma boa compreensão intuitiva da situação. Você percebeu intuitivamente que nenhum esquema de compactação pode ser eficaz em todas as entradas, porque, se fosse, poderíamos aplicá-lo repetidamente para compactar qualquer entrada em um único bit - e depois no nada!

Em outras palavras: depois de compactar todos os seus arquivos .wav para .mp3, você não obterá nenhuma melhoria no tamanho do arquivo compactando-os. Se o seu compressor de MP3 tiver feito seu trabalho, não haverá mais padrões para o compressor ZIP explorar.

(O mesmo se aplica à criptografia: se eu pegar um arquivo com zeros e criptografá-lo de acordo com meu algoritmo de criptografia preferido, é melhor que o arquivo resultante não seja compressível , ou então meu algoritmo de criptografia está vazando "padrão" em sua saída!)

  • Mesmo que a técnica ainda não seja perfeita, ela pode obviamente ser otimizada e fortemente aprimorada. Por que isso não é mais amplamente conhecido / estudado? Se essas afirmações e resultados experimentais são verdadeiros, isso não revolucionaria a computação?

Essas alegações e resultados experimentais não são verdadeiros.

Como Tom van der Zanden já observado, o "algoritmo de compressão" de Chakraborty, Kar, e Guchait é falho na medida em que não só ele não alcançar qualquer taxa de compressão, é também irreversível (em mathspeak, "não bijective"): existem uma infinidade de textos "compactados" para a mesma imagem, porque o algoritmo deles é basicamente multiplicação e a multiplicação é comutativa.

Você deve se sentir bem ao saber que sua compreensão intuitiva desses conceitos levou à conclusão certa instantaneamente. E, se você puder poupar tempo, deve sentir pena dos autores do artigo, que claramente passaram muito tempo pensando sobre o assunto sem entendê-lo.

O diretório de arquivos um nível acima da URL que você postou contém 139 "artigos" dessa mesma qualidade, todos aparentemente aceitos nas "Anais da Conferência Internacional sobre Pesquisa Emergente em Computação, Informação, Comunicação e Aplicações". Parece ser uma conferência falsa do tipo usual. O objetivo de tais conferências é permitir que acadêmicos fraudulentos reivindiquem "publicação em um periódico", além de permitir que organizadores sem escrúpulos ganhem muito dinheiro. (Para mais informações sobre conferências falsas, consulte este tópico do reddit ou várias postagens do StackExchange sobre o assunto .) Conferências falsas existem em todos os campos. Apenas aprenda a confiar em seus instintos e não acredite em tudo que lê em um "processo de conferência", e você se sairá bem.

Quuxplusone
fonte
Obrigado por declarar claramente por que esse artigo é uma porcaria simples e contar como é possível que ele tenha sido escrito em primeiro lugar e que tenha passado por qualquer tipo de revisão.
vaab
Obrigado pela sua resposta concisa. É realmente triste quando você não pode confiar que os lançamentos contábeis sejam revisados ​​pelo menos por algum colega. Isso realmente esclarece bastante o fato de que é preciso estar vigilante, mesmo quando se lê "supostas" publicações de periódicos científicos. Alguém poderia pensar que tais artigos estão sujeitos não apenas à "revisão" por pares, mas também a uma "análise" mínima por pares, como seria habitual nesses campos. Espero que isso se torne uma revelação para várias pessoas.
Klangen
Aprendi hoje que existem pelo menos duas patentes nos EUA em "algoritmos de compressão infinita" semelhantes. Veja gailly.net/05533051.html
Quuxplusone
5

A entropia limita efetivamente o desempenho da compressão sem perdas mais forte possível. Portanto, não existe algoritmo que possa comprimir conjuntos de dados aleatórios sempre acima de 50%.

J.-E. PIN
fonte
8
Nem existe um algoritmo que possa comprimir conjuntos de dados aleatórios sempre acima de 0,0000001%.
David Richerby
1

Os métodos de compressão, que são restauráveis, geralmente encontram um padrão e o reexpressam de maneira simplista. Alguns são muito inteligentes, outros muito simples. Em algum momento, não há padrão. O (s) processo (s) 'juntou' os dados ao seu padrão único mais simples. Qualquer tentativa de compactação desse ponto em diante resulta em um conjunto de dados maior ou dilui a exclusividade. Nos esquemas de compressão de números mágicos, sempre há uma falha, uma mão leve ou perda. desconfie de qualquer processo que pretenda executar o WinZip ou o RAR mais recente.

SkipBerne
fonte
2
sss
1
@DavidRicherby, sua compactação da cadeia vazia produzirá um conjunto de dados maior, conforme reivindicado por SkipBerne. Ainda assim, acho que sua resposta deve esclarecer que ele está se referindo a recomprimir a saída anterior usando o mesmo algoritmo .
Ángel
2
A afirmação de @Ángel SkipBerne é que existem strings que não podem ser compactadas por nenhum algoritmo (" qualquer tentativa de compressão a partir desse ponto em diante", ênfase minha). Isso está incorreto pela razão que apresento: para cada string, existe um algoritmo que comprime essa string.
David Richerby
A maneira como interpreto o SkipBerne está alegando que, para cada algoritmo de compactação, existe uma string que não pode ser comprimida. Que é verdade. Essa string não compactável será diferente para algoritmos diferentes, é claro.
Jose Antonio Reinstate Monica
@DavidRicherby Você está extraviando os quantificadores - é razoavelmente claro que SkipBerne escreveu que (para qualquer método de compactação, há um ponto após o qual não há compactação), não que (existe um ponto após o qual para qualquer método de compactação, existe sem compressão). Essa resposta é correta, mas não acrescenta nada às respostas mais antigas e bem escritas.
Gilles 'SO- stop be evil'