Стиснення даних за допомогою простих чисел

22

Нещодавно я натрапив на наступну цікаву статтю, яка стверджує, що ефективно стискати випадкові набори даних завжди більше ніж на 50%, незалежно від типу та формату даних.

В основному, він використовує прості числа, щоб унікально побудувати подання 4-байтових фрагментів даних, які легко розпакувати, враховуючи, що кожне число є унікальним продуктом простих чисел. Для того, щоб пов'язати ці послідовності з праймерами, він використовує словник.

Моє запитання:

Чи справді це можливо, як це пропонують автори? За даними статті, їх результати дуже ефективні і завжди стискають дані до менших розмірів. Чи не буде розмір словника величезним?
Не вдалося це використати для повторного стиснення стислих даних за допомогою того ж алгоритму? Очевидно, і було показано, що такі методи (де стислі дані повторно стискаються якомога більше разів, різко зменшуючи розмір файлу) неможливі; Дійсно, між набором усіх випадкових даних та стислих даних не було б ніякого поділу. То чому це відчуває, що це можливо?
Навіть якщо техніка ще не досконала, очевидно, її можна оптимізувати і сильно вдосконалити. Чому це не більш широко відоме / вивчене? Якщо справді ці твердження та експериментальні результати правдиві, чи не могло це революціонізувати обчислення?

information-theory data-compression primes

— Кланген
джерело

5

Як ви зауважили, папір заявляє справді сильні претензії. Завжди будьте дуже підозрілі до подібних претензій, особливо якщо папір опублікований у чужих місцях (на шанованих відомих майданчиках мають з'являтися дивовижні папери, що "революціонізують обчислення", правда?).

— Джухо

2

не можна "завжди стискати випадкові дані", наприклад, на основі теорії складності колмогоров . і спротив схожий на те, як ви накреслили. не впевнений, чи це неправильне тлумачення паперу чи оригіналу. чому ви не підкреслюєте, куди йде ця конкретна претензія?

— vzn

6

"Не вдалося це використати для повторного стиснення стислих даних за допомогою того ж алгоритму?" - Так. Будь-який алгоритм, який стверджує, що здатний стискати всі довільні дані, може бути рекурсивно застосований до власного виводу таким чином, що будь-які дані стискаються до 0 біт. Таким чином, ця претензія неможлива.

— Йорг W Міттаг

1

@ JörgWMittag У мене є алгоритм, який дозволяє вам кілька разів стискати файл до невеликої кількості біт, але це вкрай недоцільно. Також працює лише з файлами, що починаються з 1 біта: трактуйте весь файл як велике двійкове число, зменшуйте його, а потім відкиньте ведучі 0. Для декомпресії збільшуйте її, додаючи при необхідності 1.

— користувач253751

3

Примітка для себе: Не турбуйтеся надсилати будь-які документи до будь-яких журналів Elsevier.

— 500 - Внутрішня помилка сервера

34

завжди стискати випадкові набори даних більш ніж на 50%

Це неможливо. Ви не можете стискати випадкові дані, для цього вам потрібна структура. Стиснення повинно бути оборотним, тому ви не зможете стиснути все на 50%, оскільки струн довжиною набагато менше, ніж довжини . $n/2$ $n$

З документом є деякі основні проблеми:

Вони використовують 10 тестових файлів, не вказуючи їх вмісту. Дані справді випадкові? Як вони були створені?
Вони стверджують, що вони досягають коефіцієнта стиснення принаймні 50%, тоді як їх тестові дані показують, що вони досягають максимум 50%.

Цей алгоритм визначає стратегію без втрат, яка використовує прості числа, наявні в системі десяткових чисел

Що? Прості числа - прості числа незалежно від бази.
Випуск №1 з декомпресією: проста факторизація - це важка проблема, як вони це роблять ефективно?
$2\cdot 5 = 10 = 5\cdot 2$

Я не думаю, що цей документ є дуже хорошим.

— Том ван дер Занден
джерело

З того, що я зрозумів, вони зберігають порядок рядків з однаковою кратністю у словнику. Але чи не може у випадкових наборах даних породжувати величезний словник, враховуючи, що існує багато 4-байтних рядків з кратністю 1 (або однаковою кратністю)?

— Кланген

@Pickle У їх прикладі рядок "@ THE" має множинність 2. Я не бачу, як вони можуть реконструювати, у яких двох місцях має входити слово "the".

— Том ван дер Занден

1

А, бачу. Гарне спостереження. Дійсно, це головна проблема. Як цей документ було прийнято з’являтись у журналі? Чи не повинно бути більш ретельного експертного огляду?

— Кланген

4

@Pickle Так, перевірки повинні бути більш жорсткими. Це не завжди так, хоча інколи недосвідчені / ліниві / некомпетентні організатори конференції не встигають вчасно знайти рецензентів. Існує багато випадків, коли папери, що містять випадкові події, сприймаються, приймаються, і один журнал навіть опублікував документ під назвою "Забирай мене зі свого ебатього списку розсилки" .

— Том ван дер Занден

Хахаха, це дивовижно. Але сумно водночас.

— Кланген

15

Я збираюся відкластись до Тома ван дер Зандена, який, здається, прочитав документ і виявив слабкість у методі. Хоча я детально не читав статтю, виходячи з реферату та таблиці результатів, це виглядає як широко правдоподібне твердження.

Вони стверджують, що це стійкий коефіцієнт стиснення 50% для текстових файлів (не "всіх файлів"), який вони відзначають приблизно так само, як LZW, і приблизно на 10% гірше, ніж (імовірно, нульовий порядок) кодування Хаффмана. Стиснення текстових файлів на 50% не важко досягти, використовуючи досить прості методи; це бакалаврське завдання з багатьох курсів інформатики.

Я погоджуюся, що документ не дуже хороший, як опубліковані дослідження, і я не думаю, що це добре говорить рецензентам, що це було прийнято. Крім очевидних відсутніх деталей, які унеможливлюють відтворення результатів (наприклад, якими були текстові файли), і жодних спроб пов'язати їх з полем стиснення, немає сенсу, що вони справді розуміють, що робить їх алгоритм.

Веб-сайт конференції вимагає співвідношення прийнятості 1: 4, що змушує задуматися про те, що вони відхилили.

— Псевдонім
джерело

12

Ви запитаєте:

Чи справді це можливо, як це пропонують автори? За даними статті, їх результати дуже ефективні і завжди стискають дані до менших розмірів. Чи не буде розмір словника величезним?

Так, звісно. Навіть для їх обраного вручну прикладу ("ШВИДКИЙ СРІБНИЙ ФОКС СТРІЛЯЄТЬСЯ ЛЕГИЙ ДОГ") вони не досягають стиснення, оскільки словник містить кожну 4-байтну підрядку тексту (мінус 4 байти за одне повторення " THE ") ... і" стиснута "версія тексту повинна містити весь словник, плюс усе це просте число.

Не вдалося це використати для повторного стиснення стислих даних за допомогою того ж алгоритму? Очевидно, і було показано, що такі методи (де стислі дані повторно стискаються якомога більше разів, різко зменшуючи розмір файлу) неможливі; Дійсно, між набором усіх випадкових даних та стислих даних не було б ніякого поділу. То чому це відчуває, що це можливо?

Знову вам здається, що ви добре розумієте ситуацію. Ви інтуїтивно зрозуміли, що жодна схема стиснення ніколи не може бути ефективною на всіх входах, адже якби вона була, ми могли б просто застосувати її знову і знову, щоб стиснути будь-який вхід до одного біта - а потім до небуття!

Інакше кажучи: Після того, як ви стиснули всі .wav-файли до .mp3, вам не вдасться покращити розмір файлу, застебнувши їх. Якщо ваш MP3-компресор зробив свою роботу, не залишиться жодних зразків для використання компресора ZIP.

(Це ж стосується шифрування: якщо я беру файл нулів і шифрую його відповідно до мого криптографічного алгоритму вибору, отриманий файл краще не бути компресійним , інакше мій алгоритм шифрування просочує "шаблон" у свій вихід!)

Навіть якщо техніка ще не досконала, очевидно, її можна оптимізувати і сильно вдосконалити. Чому це не більш широко відоме / вивчене? Якщо справді ці твердження та експериментальні результати правдиві, чи не могло це революціонізувати обчислення?

Ці твердження та експериментальні результати не відповідають дійсності.

Як вже зазначав Том ван дер дер Занден, "алгоритм стиснення" Чакраборті, Кар та Гучайта є недоліком у тому, що він не тільки не досягає жодного коефіцієнта стиснення, але і незворотній (по математиці, "не бієктивний"): безліч текстів, які всі «стискають» на одне зображення, тому що їх алгоритм в основному є множенням, а множення є комутативним.

Вам повинно бути добре, що ваше інтуїтивне розуміння цих понять миттєво привело вас до правильного висновку. І якщо ви можете зекономити час, вам слід пошкодити авторів статті, які явно витратили багато часу на роздуми над цією темою, не розуміючи її взагалі.

Каталог файлів на один рівень над URL-адресою, яку ви опублікували, містить 139 «статей» такої ж якості, всі, мабуть, прийняті до «Матеріали Міжнародної конференції з нових досліджень у галузі обчислювальної техніки, інформації, зв'язку та застосувань». Це здається шахрайською конференцією звичайного типу. Мета таких конференцій - дозволити шахрайським науковцям заявляти про "публікацію в журналі", а також дозволяти недобросовісним організаторам заробляти тонну грошей. (Докладніше про підроблені конференції, ознайомтеся з цією темою reddit або різними публікаціями StackExchange на цю тему .) Шам-конференції існують у кожному полі. Просто навчіться довіряти своїм інстинктам і не вірити всьому, що ви прочитали у "конференції", і ви все зробите чудово.

— Квокслузон
джерело

Дякуємо, що чітко виклали, чому цей документ є звичайним лаєм, і розкажіть, як навіть можливо, що він був написаний в першу чергу і що йому вдалося пройти будь-який вид рецензування.

— vaab

Дякуємо за вашу стислу відповідь. Дійсно сумно, коли ти навіть не можеш довіряти публікації журналів, щоб їх хоча б переглянув якийсь колега. Це дійсно проливає багато світла на те, що треба бути пильними навіть під час читання "передбачуваних" публікацій наукових журналів. Можна подумати, що такі статті підлягають не лише рецензуванню, але й мінімальному експертному «аналізу», як це було прийнято в таких сферах. Я сподіваюся, що це стане очейним для багатьох людей.

— Кланген

Сьогодні я дізнався, що існує принаймні два патенти США на подібні "нескінченні алгоритми стиснення". Дивіться gailly.net/05533051.html

— Quuxplusone

5

Ентропія ефективно обмежує продуктивність найсильнішого можливого стиснення без втрат. Таким чином, не існує алгоритму, який може стискати випадкові набори даних завжди більш ніж на 50%.

— Ж.-Є. Шпилька
джерело

8

Навіть не існує алгоритму, який може стискати випадкові набори даних завжди більш ніж на 0,0000001%.

— Девід Річербі

1

Методи стиснення, які є відновлюваними, загалом знаходять шаблон і повторно виражають його спрощено. Деякі дуже розумні, деякі дуже прості. У якийсь момент немає візерунка. Процес (и) "кип'ятили" дані, встановлені в ньому найпростішою унікальною схемою. Будь-які спроби стиснення з цієї точки вперед призводять до збільшення набору даних або зменшення унікальності. У схемах стиснення магічного числа завжди є недолік, або незначна рука, або втрата. будьте обережні до будь-якого процесу, який вимагає виконати останні WinZip або RAR.

— SkipBerne
джерело

2

s

$s$

s

$s$

s

$s$

1

@DavidRicherby, тоді ваше стиснення порожнього рядка створює більший набір даних, як стверджує SkipBerne. Але я вважаю, що його відповідь повинна уточнити, що він задумується про повторне стиснення попереднього результату, використовуючи той самий алгоритм .

— Ángel

2

@ Ángel SkipBerne стверджує, що існують рядки, які не можна стиснути жодним алгоритмом (" будь-яка спроба стиснення з цієї точки вперед", мій акцент). Це неправильно з причини, яку я даю: для кожного рядка існує алгоритм, який стискає цю рядок.

— Девід Річербі

Як я його інтерпретую, SkipBerne стверджує, що для кожного алгоритму стиснення існує рядок, яку неможливо компресувати. Що правда. Зрозуміло, що ця стиска, що не стискається, відрізнятиметься для різних алгоритмів.

— Хосе Антоніо відновлює Моніку

@DavidRicherby Ви неправильно замінюєте квантори - цілком зрозуміло, що SkipBerne написав, що (для будь-якого методу стиснення є точка, після якої не відбувається стиснення), а не це (є точка, після якої для будь-якого методу стиснення існує відсутність стиснення). Ця відповідь фактично правильна, але не додає нічого до старих, краще написаних відповідей.

— Жил "ТАК - перестань бути злим"