Compressione dei dati utilizzando i numeri primi

22

Di recente mi sono imbattuto nel seguente interessante articolo che afferma di comprimere in modo efficiente insiemi di dati casuali sempre più del 50%, indipendentemente dal tipo e dal formato dei dati.

Fondamentalmente usa i numeri primi per costruire in modo univoco una rappresentazione di blocchi di dati a 4 byte che sono facili da decomprimere dato che ogni numero è un prodotto unico dei numeri primi. Per associare queste sequenze ai numeri primi utilizza un dizionario.

La mia domanda è:

È davvero fattibile come suggerito dagli autori? Secondo il documento, i loro risultati sono molto efficienti e comprimono sempre i dati a dimensioni inferiori. Le dimensioni del dizionario non saranno enormi?
Non potrebbe essere usato per ricomprimere iterativamente i dati compressi usando lo stesso algoritmo? È ovvio, ed è stato dimostrato, che tali tecniche (in cui i dati compressi vengono ricompressi il più volte possibile, riducendo drasticamente la dimensione del file) sono impossibili; in effetti, non vi sarebbe alcuna biiezione tra l'insieme di tutti i dati casuali e i dati compressi. Allora, perché ti sembra possibile?
Anche se la tecnica non è ancora perfetta, può ovviamente essere ottimizzata e fortemente migliorata. Perché questo non è più conosciuto / studiato? Se davvero queste affermazioni e risultati sperimentali fossero veri, questo non potrebbe rivoluzionare l'informatica?

information-theory data-compression primes

— Klangen
fonte

5

Come hai osservato, il documento sta avanzando affermazioni davvero forti. Siate sempre molto sospettosi di tali affermazioni, specialmente se il documento è pubblicato in una sede strana (documenti sorprendenti che "rivoluzionano l'informatica" dovrebbero apparire in luoghi noti e rispettati, giusto?).

— Juho,

2

è impossibile "comprimere sempre dati casuali" basandosi, ad esempio, sulla teoria della complessità di kolmogorov . e un disproof è simile a come hai abbozzato. non sono sicuro che si tratti di un'interpretazione errata della carta o della carta originale. perché non metti in evidenza da dove proviene quel particolare reclamo?

— vzn

6

"Non potrebbe essere usato per ricomprimere iterativamente i dati compressi usando lo stesso algoritmo?" - Sì. Qualsiasi algoritmo che afferma di essere in grado di comprimere tutti i dati arbitrari può essere applicato in modo ricorsivo al proprio output in modo tale che qualsiasi dato sia compresso a 0 bit. Pertanto, questa affermazione è impossibile.

— Jörg W Mittag,

1

@ JörgWMittag Ho un algoritmo che ti consente di comprimere ripetutamente un file in un piccolo numero di bit, ma è estremamente poco pratico. Funziona anche con file che iniziano con 1 bit: considera l'intero file come un numero binario di grandi dimensioni, decrementalo, quindi scarta gli 0 iniziali. Per decomprimerlo, incrementalo, aggiungendo un 1 iniziale se necessario.

— user253751

3

Nota per se stessi: non preoccuparti di inviare documenti a nessuna rivista Elsevier - mai.

— 500 - Errore interno del server il

34

comprimi sempre set di dati casuali di oltre il 50%

È impossibile. Non è possibile comprimere dati casuali , è necessario disporre di una struttura per trarne vantaggio. La compressione deve essere reversibile, quindi non è possibile comprimere tutto del 50% perché ci sono molte meno stringhe di lunghezza rispetto a quelle di lunghezza . $n/2$ $n$

Ci sono alcuni problemi importanti con l'articolo:

Usano 10 file di test senza alcuna indicazione del loro contenuto. I dati sono davvero casuali? Come sono stati generati?
Sostengono di raggiungere rapporti di compressione di almeno il 50%, mentre i loro dati di test mostrano che raggiungono al massimo il 50%.

Questo algoritmo definisce una strategia senza perdite che utilizza i numeri primi presenti nel sistema dei numeri decimali

Che cosa? I numeri primi sono numeri primi indipendentemente dalla base.
Numero 1 con decompressione: la scomposizione in fattori primi è un problema difficile, come lo fanno in modo efficiente?
Problema n. 2 con decompressione ( questo è il kicker ): moltiplicano insieme i numeri primi, ma così facendo perdi qualsiasi informazione sull'ordine, poiché . Non penso che sia possibile decomprimere affatto usando la loro tecnica. $2\cdot 5 = 10 = 5\cdot 2$

Non penso che questo documento sia molto valido.

— Tom van der Zanden
fonte

Da quello che ho capito, memorizzano l'ordine delle stringhe con la stessa molteplicità nel dizionario. Ma in set di dati casuali, questo non dovrebbe generare un dizionario enorme, dato che ci sono molte stringhe da 4 byte con molteplicità 1 (o uguale molteplicità)?

— Klangen,

@Pickle Nel loro esempio, la stringa "@THE" ha una molteplicità 2. Non vedo come possano ricostruire in quali due posti dovrebbe andare la parola "the".

— Tom van der Zanden,

1

Ah, capisco. Buona osservazione. In effetti, questo è un grosso problema. Come è stato accettato questo documento per apparire sul diario? Non dovrebbe esserci una revisione tra pari più rigorosa?

— Klangen,

4

@Pickle Sì, ci dovrebbe essere una revisione più rigorosa. Questo non è sempre il caso, a volte gli organizzatori di conferenze inesperti / pigri / incompetenti non riescono a trovare i peer review in tempo. Ci sono più occorrenze di documenti contenenti accettazioni generate in modo casuale generate e un diario ha persino pubblicato un documento intitolato "Fammi uscire dalla tua fottuta mailing list" .

— Tom van der Zanden,

Hahaha è fantastico. Ma triste allo stesso tempo.

— Klangen,

15

Ho intenzione di rinviare a Tom van der Zanden che sembra aver letto il documento e scoperto una debolezza nel metodo. Mentre non ho letto il documento in dettaglio, passando dall'abstract e dalla tabella dei risultati, sembra un'affermazione ampiamente credibile.

Ciò che sostengono è un consistente rapporto di compressione del 50% sui file di testo (non "tutti i file"), che notano circa lo stesso di LZW e circa il 10% peggiore della codifica Huffman (presumibilmente di ordine zero). La compressione dei file di testo del 50% non è difficile da ottenere utilizzando metodi ragionevolmente semplici; è un compito universitario in molti corsi di informatica.

Sono d'accordo sul fatto che il documento non è molto valido come ricerca pubblicata e non credo che parli bene dei revisori che questo è stato accettato. A parte gli ovvi dettagli mancanti che rendono impossibile la riproduzione dei risultati (ad es. Quali fossero i file di testo) e nessun tentativo di legarli al campo della compressione, non ha senso che capiscano davvero cosa sta facendo il loro algoritmo.

Il sito web della conferenza afferma un rapporto di accettazione 1: 4, il che ti fa chiedere cosa hanno rifiutato.

— Pseudonimo
fonte

12

Tu chiedi:

È davvero fattibile come suggerito dagli autori? Secondo il documento, i loro risultati sono molto efficienti e comprimono sempre i dati a dimensioni inferiori. Le dimensioni del dizionario non saranno enormi?

Sì, naturalmente. Anche per il loro esempio scelto a mano ("THE QUICK SILVER FOX SALTA SUL CANE PIENO"), non ottengono la compressione, perché il dizionario contiene ogni sottostringa a 4 byte del testo (meno 4 byte per la ripetizione di " IL ") ... e la versione" compressa "del testo deve includere l'intero dizionario più tutta questa merda con numeri primi.

Non potrebbe essere usato per ricomprimere iterativamente i dati compressi usando lo stesso algoritmo? È ovvio, ed è stato dimostrato, che tali tecniche (in cui i dati compressi vengono ricompressi il maggior numero di volte possibile, riducendo drasticamente la dimensione del file) sono impossibili; in effetti, non vi sarebbe alcuna biiezione tra l'insieme di tutti i dati casuali e i dati compressi. Allora, perché ti sembra possibile?

Ancora una volta sembra che tu abbia una buona comprensione intuitiva della situazione. Hai intuitivamente capito che nessuno schema di compressione può mai essere efficace su tutti gli input, perché se lo fosse, potremmo semplicemente applicarlo più e più volte per comprimere qualsiasi input fino a un singolo bit - e quindi al nulla!

Per dirla in altro modo: una volta compressi tutti i tuoi file .wav in .mp3, non otterrai alcun miglioramento nella dimensione dei file comprimendoli. Se il tuo compressore MP3 ha fatto il suo lavoro, non rimarrà alcun motivo per sfruttare il compressore ZIP.

(Lo stesso vale per la crittografia: se prendo un file di zero e lo crittografo secondo il mio algoritmo crittografico di scelta, è meglio che il file risultante non sia comprimibile , altrimenti il mio algoritmo di crittografia perde "modello" nel suo output!)

Anche se la tecnica non è ancora perfetta, può ovviamente essere ottimizzata e fortemente migliorata. Perché questo non è più conosciuto / studiato? Se davvero queste affermazioni e risultati sperimentali fossero veri, questo non potrebbe rivoluzionare l'informatica?

Queste affermazioni e risultati sperimentali non sono veri.

Come già notato da Tom van der Zanden, l '"algoritmo di compressione" di Chakraborty, Kar e Guchait è imperfetto in quanto non solo non raggiunge alcun rapporto di compressione, ma è anche irreversibile (in mathspeak, "non biiettivo"): ci sono una moltitudine di testi che "comprimono" tutti sulla stessa immagine, perché il loro algoritmo è sostanzialmente la moltiplicazione e la moltiplicazione è commutativa.

Dovresti stare bene che la tua comprensione intuitiva di questi concetti ti abbia portato immediatamente alla giusta conclusione. E, se puoi risparmiare tempo, dovresti provare pietà per gli autori dell'articolo che hanno chiaramente trascorso molto tempo a pensare all'argomento senza capirlo affatto.

La directory dei file a un livello sopra l'URL che hai pubblicato contiene 139 "documenti" di questa stessa qualità, tutti apparentemente accettati nei "Atti della Conferenza internazionale sulla ricerca emergente in informatica, informazione, comunicazione e applicazioni". Questa sembra essere una falsa conferenza del solito tipo. Lo scopo di tali conferenze è consentire agli accademici fraudolenti di reclamare la "pubblicazione su una rivista", consentendo allo stesso tempo agli organizzatori senza scrupoli di fare un sacco di soldi. (Per ulteriori informazioni su conferenze false, dai un'occhiata a questo thread reddit o a vari post StackExchange sull'argomento .) Esistono conferenze fittizie in tutti i campi. Impara solo a fidarti del tuo istinto e a non credere a tutto ciò che leggi in un "procedimento della conferenza", e farai bene.

— Quuxplusone
fonte

Grazie per aver affermato chiaramente perché questo documento è semplicemente una cazzata, e spiega come è possibile che sia stato scritto in primo luogo e che sia riuscito a passare qualsiasi tipo di revisione.

— vaab,

Grazie per la tua risposta concisa. È davvero triste quando non puoi nemmeno fidarti che le voci del diario siano almeno riviste da un pari di qualche tipo. Questo fa davvero molta luce sul fatto che si deve essere vigili anche quando si leggono pubblicazioni "presunte" su riviste scientifiche. Si potrebbe pensare che tali articoli siano soggetti non solo alla "revisione" tra pari, ma anche a una "analisi" minima tra pari, come sarebbe consuetudine in tali settori. Spero che questo diventi una rivelazione per molte persone.

— Klangen,

Ho imparato oggi che esistono almeno due brevetti statunitensi su simili "algoritmi di compressione infinita". Vedi gailly.net/05533051.html

— Quuxplusone,

5

L'entropia limita efficacemente le prestazioni della più forte compressione lossless possibile. Pertanto non esiste alcun algoritmo in grado di comprimere set di dati casuali di sempre più del 50%.

— J.-E. perno
fonte

8

Non esiste nemmeno un algoritmo in grado di comprimere set di dati casuali sempre più dello 0,0000001%.

— David Richerby,

1

I metodi di compressione, ripristinabili, in generale trovano uno schema e lo riesprimono in modo semplicistico. Alcuni sono molto intelligenti, altri molto semplici. Ad un certo punto non c'è motivo. I processi hanno "bollito" i dati impostati nel modello univoco più semplice. Qualsiasi tentativo di compressione da quel momento in avanti comporta un set di dati più ampio o diluisce l'unicità. Negli schemi di compressione dei numeri magici c'è sempre un difetto, o una leggera perdita della mano. diffidare di qualsiasi processo che pretenda di fare l'ultimo WinZip o RAR.

— SkipBerne
fonte

2

s

$s$

s

$s$

s

$s$

1

@DavidRicherby, quindi la compressione della stringa vuota produce un set di dati più grande, come affermato da SkipBerne. Tuttavia, penso che la sua risposta dovrebbe chiarire che si sta riferendo sulla ricompressione dell'output precedente usando lo stesso algoritmo .

— Ángel,

2

L'affermazione di @Angel SkipBerne è che esistono stringhe che non possono essere compresse da nessun algoritmo (" qualsiasi tentativo di compressione da quel punto in avanti", la mia enfasi). Questo non è corretto per il motivo che do: per ogni stringa esiste un algoritmo che comprime quella stringa.

— David Richerby,

Il modo in cui lo interpreto SkipBerne afferma che per ogni algoritmo di compressione esiste una stringa che non può essere compressa. Che è vero. Quella stringa non comprimibile sarà diversa per diversi algoritmi, ovviamente.

— Jose Antonio Ripristina Monica il

@DavidRicherby Stai smarrendo i quantificatori - è ragionevolmente chiaro che SkipBerne ha scritto che (per qualsiasi metodo di compressione, c'è un punto dopo il quale non c'è compressione), non quello (c'è un punto dopo il quale per qualsiasi metodo di compressione, c'è nessuna compressione). Questa risposta è effettivamente corretta, ma non aggiunge nulla alle risposte più vecchie e meglio scritte.

— Gilles 'SO- smetti di essere malvagio' il