Помогите развить новую концепцию ЯП

Разложение - дело компилятора, долгое дело. А вот восстанавливать будет проще.

а где ты будешь всё это ХРАНИТЬ?

Ну для тех программ, где множество входных данных конечно, это будет работать.

ещё раз: для сортировки 100 символов требуется хранить 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 вариантов решения.

Может разработать какую-нибудь концепцию приближенных вычислений, где каждый последующий коэффициент разложения влияет на результат всё меньше и меньше? Это пригодилось бы во многих задачах, например декодировании видео/аудио.

так ты возьми и попробуй.

вот мне тут как-то давно-давно приятель предлагал паковать данные путем записи смещения-длины числа Пи.

а как приятель объяснил то, что в смещение-длине будет меньше бит, чем в исходном сообщении?

Программы считают что-то, почти не опираясь на заранее расчитанные данные.

потому что это дешевле. НАМНОГО.

Разгадка проста: если сумма равна 5, а одно из слагаемых 3, то очевидно, второе слагаемое 2. Вопрос: КАКОЕ? Ответ на этот вопрос очевидно и весит ровно 1 бит.

Не мог бы ты пояснить понятнее, а то я ничего не понял.

ВНЕЗАПНО «просто так» её становится БОЛЬШЕ! Энтропия растёт. Поясню на простом примере: Информации в сумме двух чисел ровно на 1 бита больше, чем в аргументах (т.е. если сложить 2 байта результат занимает 9 бит). Откуда берутся лишний бит?

По идее, информации после суммы становится как раз-таки меньше, потому что у нас было два 8-битных числа, то есть в сумме 16 бит, а получилось одно 9-битное. Мы теряем информацию о том, какие именно были слагаемые, для каждой суммы возможно как раз ровно 2^7 вариантов (например, для 0 это 0+0, 1+255, 2+254, ..., 128+128), то есть эти 7 бит и исчезают.

вы все упоролись в этом треде :)

Нет. Я написал х...ту, потому что «для 0 это 0+0, 1+255, 2+254, ..., 128+128» это в случае, если верхний, 9-ый бит мы отбрасываем. Да ещё и 1+255 и 255+1 — это всё-таки разные вещи. Поэтому, если отбрасываем, то теряем, как и ожидалось, 8 бит.

А если не отбрасываем, то 0 соответствует только 0+0, а 256 (или 0 с флагом переноса) уже 1+255, 2+254, ..., 128+128, ..., 255+1, то есть 255 вариантов. Наверное, в среднем, там как раз 7 бит и выйдет, конечно, но выглядит уже не так хорошо.

С умножением, кстати, хуже, потому что умножив 8 бит на 8 бит получается число, которое можно уложить только в 16 бит, но, однако, могут получиться далеко не все 16-битные числа. Но почему информация в этом случае «жиреет», я объяснить не могу.

Не мог бы ты пояснить понятнее, а то я ничего не понял.

любая бинарная коммутативная операция убивает один бит результата.

По идее, информации после суммы становится как раз-таки меньше

у кого? У нас — да. Информации становится меньше, энтропия растёт. Нам нужны лишние биты, что-бы это скомпенсировать. Это как энергия, расходуемая на силу трения.

8-битных числа, то есть в сумме 16 бит, а получилось одно 9-битное. Мы теряем информацию о том, какие именно были слагаемые, для каждой суммы возможно как раз ровно 2^7 вариантов (например, для 0 это 0+0, 1+255, 2+254, ..., 128+128), то есть эти 7 бит и исчезают.

не так. Ты предполагаешь, что мы знаем 8 бит после операции. Очевидно, что мы не можем узнать 16 бит до. Можем только 8. На первый взгляд(всего есть 2⁸=256 вариантов сумм двух чисел по модулю 256). Проблема в том, что из всех этих 256и вариантов только два(0+0 и 128+128) однозначные. Все остальные — двузначные(56+200 например неотличимо от 200+56). Потому, нам недостаточно знать 8 бит суммы и 8 бит слагаемого. Нужен ещё один бит, говорящий о том, _какое_ это слагаемое.

PS: Это верно для любой бинарной операции, даже не коммутативной. Для тернарной операции мы теряем один трит(ln(3)/ln(2)=1.58496 бит).

Нет. Я написал х...ту, потому что «для 0 это 0+0, 1+255, 2+254, ..., 128+128» это в случае, если верхний, 9-ый бит мы отбрасываем.

потому что над расширенным полем Галуа порядка 256=2⁸ существуют отличные от нуля делители нуля. Например 2 — тоже делитель нуля. А когда мы складываем два одинаковых числа, мы множим на два. Т.о. у выражения 2*x=0 имеется несколько решений. В т.ч. и 128 над полем в 256. 2+2 тоже будет 0, хотя у нас и получается 4. Это из-за того, что кольцо вычетов не является полем, если модуль не простой. Даже если он имеет вид pⁿ, где p простое число, в случае, если мы определили сложение/умножение «как обычно».

А если не отбрасываем, то 0 соответствует только 0+0, а 256 (или 0 с флагом переноса) уже 1+255, 2+254, ..., 128+128, ..., 255+1, то есть 255 вариантов. Наверное, в среднем, там как раз 7 бит и выйдет, конечно, но выглядит уже не так хорошо.

в поле целых ℚ вариантов будет ровно N-1, где N — размер нашего подмножества ℚ. Потому если N→∞, то вариантов ровно N.

С умножением, кстати, хуже, потому что умножив 8 бит на 8 бит получается число, которое можно уложить только в 16 бит, но, однако, могут получиться далеко не все 16-битные числа. Но почему информация в этом случае «жиреет», я объяснить не могу.

потому что у нас кривое умножение. На самом деле информация не жиреет. В таблице умножения содержится ровно столько же информации, как и в таблице сложения. Умножения «дырявое», например в твоей таблице умножения над ℚ>1 нет числа 13. Т.е. произведения «пухнут», но весят столько же, с информативной т.з. Не сложно доказать, что таблицу умножения над ℚ можно сжать до размера таблицы сложения.

Для тернарной операции мы теряем один трит(ln(3)/ln(2)=1.58496 бит).

поправка: не один, а два трита, ибо 3!=6=2*3.

не буду многословным: не взлетит.

Это верно для любой бинарной операции

Что верно?

Ты хочешь изоморфизма D * D и D (|D|^2 = |D| или floor(log_n(|D|^2))+1 = floor(log_n(|D|))+1)? Он есть у пустых множеств, множеств из одного элемента и счётно-бесконечных множеств :)

Или если взять функции игнорирования одного из аргументов или min с max (коммутативны) на любых множествах, то под результат нужно столько бит, сколько их нужно под один аргумент. Никакого изменения в битности.

Или взять операцию возвращающую константу — бит может быть нужно меньше.

Сложение в натуральных числах добавляет бит, да — больше.

Умножение удваивает — ещё больше.

Это верно для любой бинарной операции

Что верно?

верно то, что 1 бит теряется при любой бинарной операции.

Или если взять функции игнорирования одного из аргументов или min с max (коммутативны) на любых множествах, то под результат нужно столько бит, сколько их нужно под один аргумент. Никакого изменения в битности.

это если ты ярлычки к аргументам приклеишь: «первый» и «второй». Без ярлычков не взлетит.

Или взять операцию возвращающую константу — бит может быть нужно меньше.

операция возвращающая константу выдаёт _всегда_ 0 бит. Т.к. значение заранее известно.

Умножение удваивает — ещё больше.

не удваивает. Сам посчитай. Битов нужно не больше, просто у нас система счисления такая(умножение многочлена степени m на многочлен степени n очевидно даёт многочлен степени m+n, а я виноват, что у нас многочлены вместо чисел?). Естественно я говорю только про ℚ, т.к. в более мощных множествах понятие «количество информации» не имеет смысла(сколько бит в π?). В таблице умножения есть далеко не все числа, некоторых просто нет(простые числа), а некоторые числа повторяются(составные, из разных комбинаций простых). Таблица сложения напротив, регулярная, в ней все числа есть(любое число можно составить из любых двух меньших чисел, складывая их и вычитая. Лишь-бы эти два числа были не равны друг другу. С умножением такой вариант не катит, из двух чисел ты можешь составить только комбинацию вида x^m*y^n, ну и ещё несколько, подключив деление, если числа не взаимно простые конечно).

ВНЕЗАПНО «просто так» её становится БОЛЬШЕ! Энтропия растёт. Поясню на простом примере: Информации в сумме двух чисел ровно на 1 бита больше, чем в аргументах (т.е. если сложить 2 байта результат занимает 9 бит). Откуда берутся лишний бит?

Разгадка проста: если сумма равна 5, а одно из слагаемых 3, то очевидно, второе слагаемое 2. Вопрос: КАКОЕ? Ответ на этот вопрос очевидно и весит ровно 1 бит.

Вот в очередной раз убеждаюсь, что у тебя какая-то каша в голове об информационной энтропии.

Ну или совершенно не умеешь выражать словами свои мысли.

Вот в очередной раз убеждаюсь, что у тебя какая-то каша в голове об информационной энтропии.

мне насрать на твоё мнение. Мои знания работают, и работают неплохо. Если они не совпадают с твоим пониманием — это твоя проблема, а не моя. Вот если-бы они не совпадали с практикой — я-бы задумался.

верно то, что 1 бит теряется при любой бинарной операции.

Это не верно.

Для множества D бинарная операция (по определению) это функция f : D * D -> D. Их всего |D| ^ (|D| ^ 2) разных. Ты утверждаешь, что для любого множества D и любой такой функции... Что?

Под D нужно n = log(|D|) бит (тоже по определению). Под первый _или_ второй аргумент — n бит. Под первый _и_ второй — 2 n (log(|D * D|) = log(|D| ^ 2) = 2 log(|D|)). Под результат — 0 <= log(|Im(f)|) <= n бит, то есть столько же или на сколько угодно меньше, не на 1.

Дальше, если 1 < |D| < aleph_0, то бинарная операция не может быть вложением/биекцией, то есть аргументы не восстанавливаются однозначно из результата. Это всегда так — тут не о чем говорить (и вообще — коммутативная операция по определению не вложение/биекция, в случае любого D, так как забывает эти самые ярлычки). Между отрезком и его квадратом есть соответствие только в случае если их нет, они точки или дискретные или непрерывные линия и плоскость.

Ещё у тебя может быть идеальное M с операциями (пусть натуральные числа) и модельное D (регистр), тогда из f : M * M -> M делаем f' : D * D -> M и видим, что log(|Im(f')|) может быть относительно n чем угодно — никаких потерь единиц.

это если ты ярлычки к аргументам приклеишь: «первый» и «второй». Без ярлычков не взлетит.

Это называется декартово произведение.

В случае min : D * D -> D образ это ровно D, под результат нужно ровно n бит.

n != n + 1.

операция возвращающая константу выдаёт _всегда_ 0 бит

Я не стал этого говорить, но да — log(1) = 0.

0 != n + 1.

не удваивает.

Строго говоря не удваивает (есть эквивалентные разбиения на множители, так что часть информации теряется), но и не увеличивает на единицу:

> let n = 64
> logBase 2 n
6.0
> logBase 2 $ fromIntegral $ length $ nub [x * y | x <- [1 .. n], y <- [1 .. n]]
10.302638923787553

11 != 6 + 1.

Я больше про то, что крайний случай это вложение D * D в M (D < M) — Im(f) ~ D * D. То есть правильное утверждение — при сужении любой бинарной операции с M на D всегда _достаточно_ вдвое большего количества бит под результат по отношению к битности (одного из) аргумента (D).

2 n != n + 1.

Заметь, никаких систем счислений, рациональных чисел и расширений полей Галуа — примитивные рассуждения про любые множества, операции и информацию (определённую через мощность, то есть как количество состояний которое нужно закодировать строкой из такого-то количества символов).

С практикой реализации метода Гаусса?

у тебя программы-числодробилки чтолей?

Заметь, никаких систем счислений, рациональных чисел и расширений полей Галуа — примитивные рассуждения про любые множества, операции и информацию (определённую через мощность, то есть как количество состояний которое нужно закодировать строкой из такого-то количества символов).

именно здесь и кроется разница наших точек зрения: КАК закодировано? Каким способом?

Ты считаешь, что «10=1*2³+0*2²+1*2¹+0*2⁰», и по твоим расчётам для числа 10 необходимо и достаточно 4х битов.

Но я считаю совершенно иначе: если речь идёт о байтах, то множество у нас из 256и эл-тов, и для _одного_ числа 10 требуется ровно log₂(256)=8битов. Зная сумму(mod256) и одно из слагаемых мы знаем и второе слагаемое, но не знаем, как была сконструирована сумма(если известное слагаемое ≠ половине суммы, если =, то тоже не знаем, но это и не важно). Т.е. известная нам информация равна _всегда_ 8 бит, но ещё один бит для нас потерян (после суммирования).

С умножением ситуация интереснее, даже если умножать байты по mod65536. По твоему получается, что надо 16 бит на произведение, но по моему это не так: число 17 вообще не входит в таблицу умножения(не считая умножения его самого на нейтральный элемент(1)). Число 6 входит в таблицу умножения один раз(с кратностью два, 2*3=3*2), а число 12 входит в таблицу дважды(2*6=3*4). Очевидно, что число 6 несёт больше информации, чем число 12. Т.к. если произведение равно 6, то мы однозначно знаем, что это 2*3. А если 12, то есть два варианта. Поэтому нужно учитывать для каждого произведения, на сколько вариантов оно может быть разложено. (для суммы m+n таких вариантов всегда m+n)

А вот вопрос «как кодировать» меня мало волнует, как не кодируй, но простое число на множители не раскладывается, а число 12 раскладывается двумя способами. А значит, нельзя считать, что множество произведений имеет цену в зависимости от log₂(2*N).

Для примера рассмотрим GF(3)

таблица сложения:

012
120
201

000
012
021

Просто мы видим маленький кусочек всего множества, и нам кажется, что умножение «больше». На самом деле, оно не «больше», просто произведение растёт по модулю быстрее, за счёт «дырок», а дырки получаются потому, что в ℚ что угодно на что угодно делить нельзя. А значит умножение «проскакивает» много своих значений.

С практикой реализации метода Гаусса?

а что не так в методе Гаусса?

Мои знания работают, и работают неплохо. Если они не совпадают с твоим пониманием — это твоя проблема, а не моя.

Если ты не можешь внятно донести свою мысль, то это в первую очередь твоя проблема. Я могу пойти читать или слушать других людей, ты же будешь иметь проблемы кому-то что-то рассказать всюду.

ВНЕЗАПНО «просто так» её становится БОЛЬШЕ! Энтропия растёт. Поясню на простом примере: Информации в сумме двух чисел ровно на 1 бита больше, чем в аргументах (т.е. если сложить 2 байта результат занимает 9 бит). Откуда берутся лишний бит?

Вот где у тебя энтропия растет? Было два слогаемых, энтропия 16 бит. Сложили - энтропия 9 бит.

Если, как ты говоришь, одно из слогаемых известно, то как была энтропия 8, так и у суммы будет 8.

Если ты не можешь внятно донести свою мысль, то это в первую очередь твоя проблема.

а ты можешь? И где можно почитать твои мысли?

Я могу пойти читать или слушать других людей

а я не преподаватель и не педагог. Я изначально не планировал тебя учить. Потому мои слова видимо не очень и понятны, ежели ты не в теме. Если хочешь узнать что-то по теме, то да, есть соответствующий курс, слушать лоровских троллей(в т.ч. и меня) — не самый лучший способ получать фундаментальное образование. Разве что у тебя есть конкретный практический вопрос.

ты же будешь иметь проблемы кому-то что-то рассказать всюду.

а с чего ты взял, что мне нужно кому-то что-то рассказывать?

Ну и в общем, если есть величина x, то для любой функции f энтропия f(x) _меньше_или_равна_ энтропии x.

Вот где у тебя энтропия растет? Было два слогаемых, энтропия 16 бит. Сложили - энтропия 9 бит.

ты определись: конечное множество, или бесконечное? Если конечное, то 9 бит никак получится не может, или у тебя не кольцо(а тогда что?). Если бесконечное, то почему ты такие маленькие числа берёшь? Бери побольше. Хотя-бы из миллиона бит. И тогда увидишь, что разница практически нулевая.

И да, если у тебя есть сумма скажем 100, и числа ℕ, то у тебя вариантов комбинаций слагаемых ровно 100. 0+100=1+99=...=49+51=50+50. Т.е. на множестве из 100 элементов энтропия неизвестного числа 1..100 равна одной сотой, и энтропия слагаемых тоже равна одной сотой. Т.о. энтропия правого слагаемого равна энтропии суммы.

Если, как ты говоришь, одно из слогаемых известно, то как была энтропия 8, так и у суммы будет 8.

а я разве знаю, какое слагаемое правое, а какое левое?

Ну и в общем, если есть величина x, то для любой функции f энтропия f(x) _меньше_или_равна_ энтропии x.

так уж и для «любой»? sqrt(1), да?

ты определись: конечное множество, или бесконечное? Если конечное, то 9 бит никак получится не может, или у тебя не кольцо(а тогда что?).

Я имел ввиду обычное арифметическое сложение. Если сложение по модулю 256, то энтропия суммы 8. (была 16, стала 8)

Если бесконечное, то почему ты такие маленькие числа берёшь? Бери побольше. Хотя-бы из миллиона бит. И тогда увидишь, что разница практически нулевая.

А если бесконечное и все элементы равновероятны, то энтропия равна +бесконечность

а я разве знаю, какое слагаемое правое, а какое левое?

Если ты не знаешь, какое из слагаемых задано, то условная энтропия пары чисел равна 9, а суммы таки все равно 8.

так уж и для «любой»? sqrt(1), да?

Что такое sqrt(1)? Какое исходное множество x было и какая функция?

ЗЫ вообще это тривиальное свойство энтропии.

Вот даже нагуглил доказательство в yahoo ответах https://answers.yahoo.com/question/index?qid=20080205211150AAr07Mh

UPD: Ладно, херовое там доказательство, но идея правильная.

А если бесконечное и все элементы равновероятны, то энтропия равна +бесконечность

не. Если у тебя бесконечное множество ℚ, то аргументы всё равно могут быть конечными, например 2*2=4.

Что такое sqrt(1)?

понял.

Ладно, «энтропия» это грубо говоря величина противоположная информации.

ты правильно сказал, что:

для любой функции f энтропия f(x) _меньше_или_равна_ энтропии x.

для функции. А вот для x энтропия растёт. Например мы не знаем, чем равен x, знаем, что x принадлежит ℚ, и что -127≤x≤127. Энтропия x равна 8 бит(чуть-чуть меньше). Теперь рассмотрим энтропию x². 0≤x²≤32768. Тем не менее, энтропия x² равна 7. Причина проста, x² принимает всего 128 значений, т.к. x²=(-x)². Т.е. энтропия x² меньше. Но сама функция увеличивает энтропию x.. После возведения в квадрат мы потеряли знак, и теперь уже _не_ _знаем_, меньше 0 x или нет. А значит энтропия растёт.

Вот даже нагуглил доказательство

это если функция однозначная. Если вдобавок функция строго монотонная, то энтропия аргумента не меняется. Если нет, то энтропия аргумента увеличивается(в некоторых интервалах/точках).

это если функция однозначная.

Ворвусь в ваш тупой трёп с важным замечанием (из педивикии):

Функция f\colon X\to Y есть множество упорядоченных пар (x,y)\in X\times Y), которое удовлетворяет следующему условию: для любого[3] x\in X существует единственный элемент y\in Y такой, что (x,y)\in f.

Пардон за формулы.

Функция f\colon X\to Y есть множество упорядоченных пар (x,y)\in X\times Y), которое удовлетворяет следующему условию: для любого[3] x\in X существует единственный элемент y\in Y такой, что (x,y)\in f.

а «квадратный корень» это не функция? Если «функция», то почему для некоторых значений из ℝ эта функция даёт не единственный результат (sqrt(1)=±1), а для других результат вообще не существует в ℝ (sqrt(-1))?

А если «не функция», то что это?

все уже придумано до нас

Ты считаешь, что «10=1*2³+0*2²+1*2¹+0*2⁰», и по твоим расчётам для числа 10 необходимо и достаточно 4х битов.

Да нет, не считаю, количество бит под это число зависит от того элементом какого множества оно является (мы множество элементов и кодируем же, в отрыве от этого нет смысла).

Но я считаю совершенно иначе: если речь идёт о байтах, то множество у нас из 256и эл-тов, и для _одного_ числа 10 требуется ровно log₂(256)=8битов.

Ну и я так считаю — если 10 это элемент множества из 256 элементов, то это одно из состояний, ему соответствует октет — 256 состояниям нужно 8 бит.

именно здесь и кроется разница наших точек зрения

Вообще, абзац который ты процитировал сам по себе не нужен :)

По твоему получается

У меня нет точки зрения — мне интересно где у любой бинарной операции теряется бит в результате (в общепринятых определениях, ес-но). Вот ты говоришь про любые бинарные операции (на любых множествах?), но вместо того чтобы дать ясные определения и объяснения что имеется в виду — начинаешь рассказывать про сугубо специальные множества и операции. Я всё равно не понял — ну если взять Z/nZ (типа mod256), то |Im(sum_on_it)| = |Im(prod_on_it)| = n (= 256), мне этого достаточно. А ты какую-то хитрую информацию хочешь считать (что аж теорию Галуа наворачиваешь).

но не знаем, как была сконструирована сумма

То есть мы знаем оба аргумента, результат, но не знаем... Даже не знаю чего мы можем не знать (a + x = b решается однозначно, в отличии от a * x = b).

Ну и я так считаю — если 10 это элемент множества из 256 элементов, то это одно из состояний, ему соответствует октет — 256 состояниям нужно 8 бит.

надо ещё и кратность учитывать. В случае сложения это только x+y=y+x, а вот в случае умножения всё намного сложнее. Т.е. если у нас есть только число 12, и ещё мы знаем, что это произведение над ℕ, то это уже даёт нам 6 вариантов: 1*12,2*6,3*4. А вот для суммы вариантов 12: 0+12, 1+11, и так далее. Потому в сумме и получается информации меньше, а неопределённости больше.

У меня нет точки зрения — мне интересно где у любой бинарной операции теряется бит в результате (в общепринятых определениях, ес-но). Вот ты говоришь про любые бинарные операции (на любых множествах?)

не. «Любые» это слишком сильно. Речь только про кольцо с однозначной операцией((возможно)кроме одной или нескольких особых точек). Причём операция либо коммутативная, либо не коммутативная, но из z1=x⊕y следует существование z2=y⊕x, причём z2 однозначно и в этом кольце.

А ты какую-то хитрую информацию хочешь считать (что аж теорию Галуа наворачиваешь).

ты не понял: я её _считаю_. А здесь я просто отдыхаю ☺

То есть мы знаем оба аргумента, результат, но не знаем...

нет. Мы знаем _только_ результат. А об аргументах мы только догадываемся. (саму функцию мы конечно тоже знаем, и можем всегда её вычислить, в тех точках, где она определена, конечно).

Т.е. если речь о сумме над ℕ, то аргументы суммы n — подмножество ℕ из n элементов. Энтропия n равна 0(т.к. оно нам известно), энтропия аргументов(обоих) равна 1+log₂(n) (в битах).

Даже не знаю чего мы можем не знать a + x = b решается однозначно

относительно x? Да. Потому если энтропия a и b равна 0(мы их знаем), то энтропия x тоже равна нулю. Ну и смысл обсуждать этот случай? Мой старший сын, первоклассник, уже умеет такое решать.

Нет, не функция.

Обычно рассматривают «арифметический» квадратный корень, у которого положительные значения

Обычно рассматривают «арифметический» квадратный корень, у которого положительные значения

где рассматривается? В твоей школе, на уроке арифметики?

Нет, не функция.

ясно. Это я тебе в комментарий воткну.

Да мне хоть в жопу воткни. Если ты не знаешь определение функции, тут уже ничего не поделать.

Это тоже для тебя график функции?

http://rghost.net/54923289

esandmann, тут видишь, какое дело: очень много вариантов входных и выходных данных у программы (да что уж много - бесконечность). Твоя идея соизмерима с попыткой получить кино при помощи /dev/random. Там же по идеи случайные (если быть точнее, то псевдослучайные) данные, но не суть важно, но важно, что к примеру, фильм, возьмём конкретный, например, Титаник в цифровом виде - это последовательность 1 и 0, которые можно легко получать в /dev/random, таким образом, существует вероятность получить фильм Титаник из /dev/random, но есть одно но: будем считать, что размер этого файла с фильмом - 5 Гб, т.е. 5*1024 мегабайт, т.е. 5*1024*1024 килобайт, т.е. 5*1024*1024*1024 байт, т.е. 5*1024*1024*1024*8 бит, что равно 42 949 672 960 бит. Для каждого бита с вероятностью 50% будет 1 или 0, таким образом для гарантированного получения этого файла необходимо перебрать 2^42 949 672 960 вариантов, а это очень большое число, таким образом потребуется время, соизмеримое с существованием вселенной. У тебя же нет даже ограничения на объём входных и выходных данных. Вывод - не взлетит.

Да мне хоть в жопу воткни.

не, детка. Я жену люблю.

Если ты не знаешь определение функции, тут уже ничего не поделать.

функции они разные бывают. И определения тоже разные. Твоё, вырванное из контекста, не претендует на абсолют.

Это тоже для тебя график функции? http://rghost.net/54923289

да.

PS: а руки у тебя действительно из жопы растут ☺

Скажу больше - график функции может быть и не только линией, но и поверхностью.

необходимо перебрать 2^42 949 672 960 вариантов, а это очень большое число, таким образом потребуется время, соизмеримое с существованием вселенной.

ты заблуждаешься. Время существования вселенной — < наносекунды, по сравнению с этим числом.

Зачем ты взял 5Гб? Возьми тысячу бит(1000). Если за секунду ты проверяешь 1`000`000`000 комбинаций, на проверку всех вариантов потребуется 339773150426898567018145944019533805987254189404342214435486551360461393684974671008751388513348509046040928753663478825845746221997816477548978233596479414127808465716141266660992979612581530374110672950058551337632608487677535754666588785707669422709639665071237384819267815564834613 лет.

график функции может быть и не только линией, но и поверхностью.

а ещё он может быть лютой ☣, которую даже представить невозможно.

Ну не прикинул, что наша вселенная столь молода. Будем считать время с какого-то момента до большого взрыва, хоть это и не совсем правильно с точки зрения СТО ;)

Это брейкин ньюс, в самом деле

А 5 Гб взял для наглядности, как приблизительный размер простого DVD диска.