Чи можна PRNG використовувати для магічного стиснення речей?

Ця ідея мені прийшла в голову як дитина, яка навчається програмувати і вперше зустрічається з PRNG. Я досі не знаю, наскільки це реально, але зараз є обмін стеками.

Ось схема 14 років для дивовижного алгоритму стиснення:

Візьміть ПРНГ і посіяйте його насінням s щоб отримати довгу послідовність псевдовипадкових байтів. Щоб передати цю послідовність іншій стороні, вам потрібно лише повідомити опис PRNG, відповідне насіння та довжину повідомлення. Для досить довгої послідовності цей опис був би набагато коротшим, ніж сама послідовність.

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

PRNG повторюються після створення достатньо великої кількості бітів, але порівняно з "типовими" циклами моє повідомлення є досить коротким, тому це не здається великою проблемою.

Voila, ефективний (якщо рубе-голдбергійський) спосіб стиснення даних.

Отже, якщо припустити:

• Послідовність, яку я хочу стиснути, є кінцевою і відомою заздалегідь.
• Мені не вистачає грошей чи часу (Тільки доки потрібна кінцева сума обох)

Я хотів би знати:

• Чи є фундаментальний недолік в міркуванні схеми?
• Який стандартний спосіб проаналізувати подібні думки експерименти?

Підсумок

Часто буває так, що в хороших відповідях з’ясовується не тільки відповідь, але і те, що я насправді запитував. Дякую за терпіння та детальні відповіді.

Ось моя дев’ята спроба узагальнення відповідей:

• PRNG / кут насіння не сприяє нічого, це не більше ніж програма, яка виробляє бажану послідовність як вихід.
• Принцип голубої дуги: Є набагато більше повідомлень довжиною> k, ніж є (генерують повідомлення) програми довжиною <= k. Тож деякі послідовності просто не можуть бути результатом програми коротшою, ніж повідомлення.
• Варто зазначити, що інтерпретатор програми (повідомлення) обов'язково фіксується заздалегідь. І його дизайн визначає (малу) підмножину повідомлень, які можна генерувати, коли надходить повідомлення довжиною k.

На даний момент оригінальна ідея PRNG вже мертва, але для вирішення є принаймні одне останнє питання:

• З: Чи можу мені пощастити і виявити, що моє довге (але кінцеве) повідомлення просто трапляється на виході програми довжиною <k біт?

Власне кажучи, це не питання випадковості, оскільки значення кожного можливого повідомлення (програми) необхідно знати заздалегідь. Або це значення деякого повідомлення від <K бітів чи ні .

Якщо я вибираю випадкове повідомлення розміром> = k біт випадковим чином (чому б мені це зробити?), Я б у будь-якому випадку мав би ймовірність того, що зможу надіслати його, використовуючи менше, ніж k біт, і майже впевненість, що не зможу надіслати він взагалі використовує менше k біт.

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

Нарешті:

• Питання: У чому вся справа у сфері складності ентропії / колгорогова ?

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

У вас нова геніальна схема стиснення, так? Добре, тоді ...

♫ Давайте всі пограємо, гра ентропії ♫

Щоб бути простим, я вважаю, що ви хочете стиснути повідомлення рівно бітів, для деяких фіксованих n . Однак ви хочете мати можливість використовувати його для довших повідомлень, тому вам потрібен певний спосіб відрізнити своє перше повідомлення від другого (воно не може бути неоднозначним, що ви стиснули).$n$$n$

Отже, ваша схема полягає у визначенні деякого сімейства PRNG / насіння таким чином, що якщо ви хочете стиснути, скажімо, , тоді ви просто записуєте деяке число k , яке визначає деякий попередньо обчислений (і спільний) набір / PRNG комбо, який генерує ці біти після $01000111001$$k$$n$ запитів. Добре. Скільки існує різних бітових рядків довжиною ? 2 n (у вас n варіантів між двома пунктами; 0 і 1 ). Це означає, що вам доведеться обчислити 2 n цих комбо. Без проблем. Однак вам потрібно виписати k у двійковій формі, щоб прочитати його. Скільки великих може отримати k ? Ну, вона може бути такою великою, як і $n$$2^n$$0$$1$$2^n$$k$$k$$2^n$. Скільки бітів мені потрібно, щоб виписати ? log 2 n = $2^n$$\log{2^n} = n$ .

На жаль! Ваша схема стиснення потребує повідомлень до тих пір, що ви стискаєте!

"Ха-ха!", Ти кажеш, "але це в гіршому випадку! Одне з моїх повідомлень буде відображено до , для чого потрібно лише $0$$1$ для представлення біт! Перемога!"

Так, але ваші повідомлення повинні бути однозначними! Як я можу відрізнити а потім 0 від 10 ? Оскільки деякі ваші клавіші мають довжину $1$$0$$10$$n$ , всі вони повинні бути, інакше я не можу сказати, де ви почали і зупинилися.

"Ха-ха!", Ви кажете, "але я можу просто поставити довжину рядка у двійковій формі! Це потрібно лише порахувати до , яке може бути представлене журналами n бітів! Отже, мій 0 зараз поставлений з префіксом лише журналу $n$$\log{n}$$0$$\log{n}$ біти, я все одно перемагаю! "

Так, але тепер ці дійсно великі цифри мають префікс бітів. Ваша схема стиснення зробила деякі ваші повідомлення ще довшими! І половина всіх ваших чисел починається з 1 , тому половина$\log{n}$$1$ ваших повідомлень настільки довша!

Потім ви продовжуєте викидати більше ідей, таких як символ, що закінчується, gzipping число та стискання самої довжини, але всі вони стикаються з випадками, коли отримане повідомлення просто довше. Насправді, за кожен біт, який ви зберігаєте на якомусь повідомленні, інше повідомлення отримуватиме довший відповідь. Взагалі, ви просто збираєтеся змінити "вартість" ваших повідомлень. Якщо зробити деякі коротшими, це просто зробить інші довшими. Ви дійсно не можете помістити різних повідомлень за менший простір, ніж виписувати 2 n двійкових рядків довжиною $2^n$$2^n$$n$ .

"Ха-ха!", Ти кажеш, "але я можу вибрати деякі повідомлення як" дурні "і зробити їх незаконними! Тоді мені не потрібно рахувати весь шлях до $2^n$ , тому що я не підтримую , що багато повідомлень!»

Ти маєш рацію, але ти насправді не виграв. Ви просто скоротили набір повідомлень, які підтримуєте. Якщо ви підтримували лише та $a=0000000011010$ як повідомлення, яке ви надсилаєте, то ви точно можете мати код a → 0 , b → 1 , який точно відповідає тому, що я сказав. Тут n = 1 . Фактична довжина повідомлень не важлива, скільки їх є.$b=111111110101000$$a\rightarrow 0$$b\rightarrow 1$$n=1$

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

Так! Вітаємо, ви щойно відкрили ентропію ! Якщо у вас є повідомлення, де я е повідомлення має ймовірність р я бути посланим, то ви можете отримати очікувану довжину повідомлення до ентропії Н = Е п я = 1 р я увійти ( 1 / р я ) цієї множини повідомлень. Це якесь дивне вираження, але все, що вам потрібно насправді знати, це те, що це найбільше, коли всі повідомлення однаково ймовірні, і менше, коли деякі зустрічаються частіше, ніж інші. У крайньому випадку, якщо ви в основному знаєте, кожне повідомлення буде $n$$i$$p_i$$H = \sum_{i=1}^np_i\log(1/p_i)$ . Тоді ви можете використовувати цей надзвичайно ефективний код: a → 0 , x → 1 x в іншому випадку. Тоді очікувана довжина повідомлення в основному 1 , який є дивним, і це буде дуже близько до ентропії H . Однак H - нижня межа, і ви її справді не можете перемогти, як би ви не намагалися.$a=000111010101$$a\rightarrow0$$x\rightarrow1x$$1$$H$$H$

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

Є довічних рядків довжиною менше , ніж N , і 2 N довічних рядків довжини рівно N . Це означає, що яким би не був ваш алгоритм стиснення , повинен бути якийсь рядок, який він взагалі не може стискати, лише тому, що відображення від вихідної рядки до стислої рядка повинно бути ін’єктивним (один на один). Це є рушійною силою багатьох застосувань складності Колмогорова.$2^N-1$$N$$2^N$$N$

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

Imagine that your seed $s$ has length $k$. Your PRNG is a deterministic function of the seed, so it outputs at most $2^k$ different sequences of length $n$. There are $2^n$ of these, so your scheme isn't going to work unless it falls back on just sending the whole $n$-bit string when there is no corresponding $s$.

(As another answer noted, this will happen for any compression function you choose at all.)

Beside other already answared points, I just want to add this link: https://www.schneier.com:443/blog/archives/2009/09/the_doghouse_cr.html

Now, the annual energy output of our sun is about 1.21×10^41 ergs. This is enough to power about 2.7×10^56 single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. If we built a Dyson sphere around the sun and captured all its energy for 32 years, without any loss, we could power a computer to count up to 2^192. Of course, it wouldn't have the energy left over to perform any useful calculations with this counter.

So only iterating (no comparing...) to find a valid 187bit constellation of your desired data would take under (not attainable) ideal conditions more energy than the sun emits over a year.

A very quick proof that an universal compressor cannot exist. Let´s suppose you do make one, and you compress an input. Now, iteratively compress the output of your program. If you can always reduce the size, it will get smaller and smaller on every step, until you are down to 1 bit.

You could argue that, perhaps, the output of your algorithm has such a structure that it cannot be compressed more, but then you could just apply a deterministic shuffle* before recompressing.

Footnote: Some deterministic shuffling actually helps in some compression schemes: http://pytables.github.io/usersguide/optimization.html?highlight=shuffling#shufflingoptim

The use of a PRNG for "compression" is basically useful in one situation: when it is necessary to use a "random" bunch of data and compactly record what data was used. Most pseudo-random generators can only generate a tiny fraction of possible sequences, but if one only needs a small-to-moderate number of "random" sequences, the fraction of possible sequences that a PRNG can generate will often be more than adequate.

If the sequence of data that one wishes to store happens coincidentally to match what a certain PRNG would generate given the right seed, storing the seed may be a compact alternative to storing the data. Unless the source of data is such that such matches are likely to occur, however, they would be so infrequent that searching for them would not be worthwhile.

Something to consider to add to the cacophony of answers that assert why there are some strings that cannot be compressed owing to the, by definition, injective nature of decompression, and the limited universe of compressed strings from which to select to represent messages is this: most strings cannot be compressed because there are very many more high entropy, disordered strings than there are lower entropy and structured ones, therefore giving rise to the condition that we see in practice that: compression is most of the time useful, since the messages we most often wish to compress are those most often possessive of some aliquot of order and structure, and by this dint, are part of the very much smaller universe of lower entropy objects. This means it is possible that, by choosing a suitable output length, we can compress everything in the smaller, structured universe. The term structured, entropy and ordered here are deliberately imprecise, to reflect the subjective definitions of the semantics and usefulness of messages we may wish to compress.

And in direct answer to the questioner's request : *yes, you could of course just get lucky and find the output of your PRNG is the exact message you wish to compress, it's just that you so often won't find this is the case because the very property that characterises a PRNG, namely, its ability to product an (almost) unending variety of different strings, make it concomitantly unlikley to produce yours.

Of course you could mitigate this unlikelihood by using a PRNG to walk over a "domain graph" of word to word transitions, and you increase greatly the likelihood of your message's apparition, and also find you must now add the domain graph to the compressed message length.