инновации на марше (антивирус Бабушкина)

denis24

После бесславной истории про отечественную операционку BolgenOS всплыла ещё одна история про то, как пацан пришёл к успеху:
http://habrahabr.ru/post/170487/
Вкратце суть токова: чувак придумал три инновационные разработки:
1. Флешка, которую нельзя потерять
2. Антивирус
3. Архиватор.
Самый прикол про архиватор. Механизм работы по словам автора:
Про архивацию, вынудили:
Алгоритм архивации таков: любой файл представляет собой HEX-последовательность символов, переводим этот HEX в DEC, получаем неебически-большое число, дописываем перед этим число 0, — получаем число в диапазоне от 0 до 1 с огромным числом знаков после запятой, а дальше всё просто — подбираем 2 таких целочисленных числа, частное которых даст нам искомое число в диапазоне от 0 до 1 с точностью совпадений до последнего знака. Беда в подборе чисел, которое может идти и 2 часа, а может идти и 2 недели. Есть опытные образцы и работающая программа, и всё это работает.
Ну а самая мякотка в том, что он свой антивирус продавал в госучереждения. Есть мнение, что столь быстрый успех обеспечил ему папа - проректор местного медуниверситета по учебной работе.: http://www.agmu.ru/about/struktura/prorektor-po-uchebnoy-rab...
Парню прямая дорога в Сколково ящщетаю. Вместе с папой, разумеется.
Тут находится суперподробный разбор работы антивируса и анализ того, откуда все это было спизжено: http://sporaw.livejournal.com/153328.html

seregen-ka

"ну, он профессионал?" (c)

denis24

большеада.
Вот, собственно, флэшка, которую нельзя потерять:

Про антивирус:
Студент из АлтГТУ разработал компьютерную антивирусную программу, ее уже сейчас устанавливают в некоторых школах Барнаула.
Алексей Бабушкин учится на третьем курсе технического университета. Над антивирусом “Иммунитет” он начал работать еще будучи школьником. Программа оказалась удачной. Сейчас Алексей продал более одной тысячи лицензий. В основном ее устанавливают на персональных компьютерах, но уже приобрели несколько школ и компаний краевого центра.
- Мы давно заинтересовались этим проектом, - рассказывает заведующий отделением довузовской подготовки АлтГТУ Виктор Мусько. - Он выходил за рамки школьной программы. Конкурировать с известными антивирусными продуктами обычному студенту сложно. Но “Иммунитет” должен занять свою нишу в регионе. Он эффективен при блокировке вирусов, имеющих небольшой объем. В этом случае нужна компактная программа. “Иммунитет” скромно, но очень качественно выполняет свои функции.
Преимущество “Иммунитета” заключается в том, что он занимает небольшой объем памяти – всего 5-7 мегабайт. Благодаря этому компьютеры не тормозят. Годовое обслуживание антивируса стоит около 450 рублей. Название программы Алексею помог придумать его отец - проректор по учебной работе медицинского университета.
“Отец установил антивирус на рабочем компьютере, – вспоминает Алексей Бабушкин. - Работа программы ему понравилась. Он и предложил название - “Иммунитет”. Потому что антивирус лечит компьютер от болезней”.
Кстати, идея создания антивируса появилась у Алексея благодаря учителю по информатике (Ох уж эти учителя информатики - помните учителя информатики Дениса Попова? Не они ли всему виной? — прим. sporaw который часто говорил, что ученики приносят зараженные вирусами флешки и от этого школьные компьютеры глючат. Потом идея переросла в готовый продукт. Со временем друзья стали просить Алексея установить программу на их компьютеры. Когда он понял, что антивирус действительно хорошо работает, стал продавать его.
Системный администратор Александр Беллер говорит, что у “Иммунитета” есть некоторые преимущества.
- Когда я работал системным администратором в барнаульской гимназии № 69, мы установили “Иммунитет” на десятки компьютеров,
в том числе и на те, не новые, которым мощные антивирусники не по зубам. И "Иммунитет" нормально работает.
Уже сегодня антивирус Бабушкина установлен на компьютерах в его лицее, у всех друзей и знакомых на домашних компьютерах и даже в городском комитете по здравоохранению — в общей сложности около двухсот пользователей
Так что там у нас с ядром. О, это прекрасно:

Romyk

Алгоритм архивации таков: любой файл представляет собой HEX-последовательность символов, переводим этот HEX в DEC, получаем неебически-большое число, дописываем перед этим число 0, — получаем число в диапазоне от 0 до 1 с огромным числом знаков после запятой, а дальше всё просто — подбираем 2 таких целочисленных числа, частное которых даст нам искомое число в диапазоне от 0 до 1 с точностью совпадений до последнего знака. Беда в подборе чисел, которое может идти и 2 часа, а может идти и 2 недели. Есть опытные образцы и работающая программа, и всё это работает.

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

antcatt77

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

denis24

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

Romyk

Вот только два полученных числа в сумме будут больше, чем исходная последовательность в большинстве случаев.

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

Asmodeus

на хабре уже предложили мегаидею: брать любые 2 числа, с их помощью получать этот код, разархивировать в авишник и смотреть кино. А чо - мегаидея, а сколько денег сэкономит.
Михалков и Спилберг рвут на себе волосы с досады :grin:

Mausoleum

Тихо, блин, пока Михалков не начал собирать оброк еще и с операции деления!

Innysa

А идея как минимум любопытная, ведь она сработает даже на случайных последовательностях где обычные архиваторы пасуют. Есть какой нибудь анализ?
Пусть данное число k длиной n знаков, тогда 0.k = k / 10^n, Дальше продолжать?

LAPIN

Интуиция мне говорит то же самое, но хочется хоть какой нибудь пруф или обоснование.
Жесть, форум МГУ :)
Дробная запись 0.123456789 это по сути 123456789 / 1 000 000 000
То есть, вот твои 2 числа - 123456789 и 1 000 000 000
Оба числа можно грубо оценить как 10 ^ p1 и 10 ^ p2 (снизу как 10 ^ p-1 , сверху как 10 ^ p для числа из p цифр)
то есть 123 (3 цифры) снизу как 100 = 10 ^ 2, сверху как 1000 (10 ^ 3)
Из известной формулы о том, шта x ^ a * x ^ b = x ^ (a + b) мы понимаем, что p1 + p2 = p3 - степень оценочного числа для частного, соответственно. Для 123456789 / 10 будет p1 = 8, p2 = 9 => p3 = 17.
Сл-но символьный размер в десятичной записи будет одинаков для частного и суммы делителя с делимым :)
-----
UPD:
То бишь, для несократимой дроби, например, где делимое является простым числом "архив" будет в 2 раза больше оригинала.
Сокращение длины будет лишь если дробь хорошо сокращается, опять же как заметили например 0,0078125. ( 1 / 128)
Да, тут похоже, здесь уже надо смотреть сравнение мощности множества пар чисел без общего делителя, чьё делимое лежит в [0, 1] и рациональных чисел интервала [0,1].
Я поторопился с утверждением, что неработоспособность легко доказать, каюсь :(
3/7 периодическое, такие рассматривать можно в виде исключения ИМХО. По сути ни один "архив" не окажется равен 3/7.
UPD2:
Поправлю кривой пост, иначе из-за моего маленького просчёта не влияющего на доказательство никто не читает дальше, похоже :)

LAPIN

сработать-то она сработает. Вот только два полученных числа в сумме будут больше, чем исходная последовательность в большинстве случаев.
Ровно таким же будет +- байт.
Ну и, разумеется, будет значительная потеря, если хранить числа в ASCII-представлении.

n2610

Интуиция мне говорит то же самое, но хочется хоть какой нибудь пруф или обоснование.
Рассмотрим все возможные файлы объёмом не более некоторого заданного, пусть их будет N. Теперь рассмотрим множество заархивированных файлов. Их общая длина не может быть меньше общей длины исходных файлов, потому что исходные файлы - N самых коротких файлов. Следовательно, средняя длина заархивированных файлов не может быть меньше средней длины исходных файлов, и длина файла после архивирования в среднем не может уменьшиться.

Romyk

То есть раз числа 3 и 7 записываются одним десятичным разрядом, то результат деления 3/7 можно записать максимум двумя десятичными числами? это контрпример.
upd. Хотя доказательство вполне очевидно вытекает из того что комбинаций двух n-битных чисел не более чем в числе с 2n-бит, а уникальных результатов деления и того меньше. Поэтому, хотя на первый взгляд кажется что результат деления nбитных чисел может быть гораздо длинее 2nбит, их множество все таки меньше чем может быть представлено 2n-битным числом. Получается, как тут уже выше написали, что только часть последовательностей может быть представлена в виде деления с выигрышем, в остальных случаях таких чисел просто не подобрать без увеличения n.

antcatt77

Ровно таким же будет +- байт.
в твоем же примере 0.123456789 до архивирования 9 цифр, а после архивирования будет 123456789 и 1000000000 - 19 цифр

LAPIN

в твоем же примере 0.123456789 до архивирования 9 цифр, а после архивирования будет 123456789 и 1000000000 - 19 цифр
Да, я накосячил
Поправился. 19 цифр - ну это вопрос к автору алгоритма :)
Для любых простых чисел "архив" будет в 2 раза больше оригинала, как ни крути.

lilith000007

Дробная запись 0.123456789 это по сути 123456789 / 10
:facepalm:

coteico

А вааабсче, даже если и все ок - дробь a/10^t сократима только на 2 и на 5 в тех или иных степенях. Стало быть изменение одной цифры ведет к изменению размера архива до полностью несжатого удвоенного размера.
Бррр юношеский максимализм, он такой

komBAR

Бл, что за СЗМ в этом треде. С чего вы вообще взяли что дроби обязаны быть десятичными. Очевидно, имеются в виду обычные. И с помощью цепных дробей действительно можно неплохо приближать иррациональные числа дробями.
Хотя реального сжатия от этого не будет скорее всего (ну или для каких-то сильно специфических данных).

andr02

Бабушкин, который это предложил, скорее всего не знает про цепные дроби.

alexk01

Не затрагива разумность алгоритма интересно зачем HEX переводится в DEC. Как это помогает делению? Если десятичная система берется чтобы было больше возможностей для сокращения, не лучше ли взять основание 6?

kastodr33

думаю сокращения там все же не планировалось, требуемое число при делении не обязано плучаться точно, достаточно чтобы первые n знаков совпадали, дальше может быть любая херня.

alexk01

Сам СЗМ. О цепных дробях речь вообще не шла. Обычно методы сжатия основаны на неких закономерностях в последовательности байт. Случайную последовательность в общем случае сжать нельзя. Так вот этот метот не содержит статистического начала, в силу его бредовости интуиция подсказывает, что для него любая последовательность байт должна рассматриваться как случайная.

n2610

А вааабсче, даже если и все ок - дробь a/10^t сократима только на 2 и на 5 в тех или иных степенях. Стало быть изменение одной цифры ведет к изменению размера архива до полностью несжатого удвоенного размера.
Алгоритм архивации таков: любой файл представляет собой HEX-последовательность символов, переводим этот HEX в DEC, получаем неебически-большое число, дописываем перед этим число 0, — получаем число в диапазоне от 0 до 1 с огромным числом знаков после запятой, а дальше всё просто — подбираем 2 таких целочисленных числа, частное которых даст нам искомое число в диапазоне от 0 до 1 с точностью совпадений до последнего знака.
То есть, 0.3333 можно "заархивировать" как 1/3.

vamoshkov

иррациональные числа
очевидно там не идет речь об иррациональных числах

vamoshkov

дальше может быть любая херня.
и как тогда понять где конец?

vamoshkov

То есть, 0.3333 можно "заархивировать" как 1/3.
а "разорхивировать" потом как 1/3?

kastodr33

хранить длину, очевидно.

vamoshkov

очевидно в авторском алгоритме длина не хранится

kastodr33

кому это очевидно?
мне очевидно что хранится
вообще на уровне "идеи" для школьника алгоритм вполне нормальный, говорит о том что башка хоть как то варит.
То что работать он будет мягко говоря не всегда - доказательство этого уже менее тривиально.
Поэтому чувак просто взял и запрогал, и сам же говорит что вышла херня неработоспособная.

vamoshkov

То что работать он будет мягко говоря не всегда - доказательство этого уже менее тривиально.
попробуй доказать что он хоть когда-нибудь будет хоть как-то работать, пусть даже при хранении длины файла
ну то есть кроме тривиального 1/3 разумеется, поскольку последовательность троек можно и более простыми методами заархивировать.
 
алгоритм вполне нормальный

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

уверен, что ничего он не запрогал, и мегабайтный файл заархивировать его программа не сможет и за год
 
на уровне "идеи" для школьника

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

alexk01

попробуй доказать что он хоть когда-нибудь будет хоть как-то работать, пусть даже при хранении длины файла
ну то есть кроме тривиального 1/3 разумеется, поскольку последовательность троек можно и более простыми методами заархивировать.
1/19=0.(052631578947368421)
Выгода очевидна. Но для произвольного числа выгода сомнительна.

kastodr33

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

vamoshkov

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

vamoshkov

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

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

уверен что ничего он там не запрогал.
А придумать какую то хуйню без понимания что это вообще такое много ума не надо.

kastodr33

уверен что ты не умеешь читать.
"Беда в подборе чисел, которое может идти и 2 часа, а может идти и 2 недели. Есть опытные образцы и работающая программа, и всё это работает."
"как выделять куски? попробуй обоснуй что выгода очень даже будет."
то что выгода будет очевидно. Алгоритмы поиска подходящих цепочек можно придумать разные.

Romyk

 
Рассмотрим все возможные файлы объёмом не более некоторого заданного, пусть их будет N. Теперь рассмотрим множество заархивированных файлов. Их общая длина не может быть меньше общей длины исходных файлов, потому что исходные файлы - N самых коротких файлов. Следовательно, средняя длина заархивированных файлов не может быть меньше средней длины исходных файлов, и длина файла после архивирования в среднем не может уменьшиться.

Это ведь доказательство невозможности сжать произвольную последовательность и невозможности универсального архиватора? Я его знаю в более наглядной форме (от противного) (своими словами, кто хочет может найти более правильную интерпретацию)- Допустим есть некий архиватор, который способен сжать произвольную входную последовательность на 1 бит. Следовательно, многократно использовав этот архиватор можно сжать любую произвольную последовательность до 0 бит. Отсюда следует что такого архиватора не существует.
То что ты приводишь именно это объясняет тот урожай минусов который я собрал - видимо, за речь про сжатие произвольных данных (я в курсе что это невозможно, неудачно выразился - имелись в виду псевдослучайные численные последовательности).
Пруф я просил на другое - на то что предложенный алгоритм (взяв только суть - представление некоего числа в виде дроби двух других) не имеет смысла - для себя я его сформулировал выше, повторюсь. Допустим есть некая 128 битная последовательность, которую мы пытаемся представить в виде дроби двух 32 битных чисел (которая совпадает на первых 128 битах результата с искомой, а не дает точно искомый результат - это обстоятельство не надо забывать, хотя это все равно несущественно). Фишка в том что множество уникальных результатов деления (другими словами, численных последовательностей) двух 32битных чисел меньше чем 2^64, а множество чисел представимых в виде 128 бит гораздо более мощнее - 2^128. Соответственно, подобрать такую дробь для произвольной 128-битной последовательности можно с вероятностью как максимум 1/2^64, для оставшихся последовательностей дроби, состоящей из 32-битных чисел, не существует. И даже для 64-битных последовательностей вероятность найти подходящую дробь меньше единицы из-за избыточности кодирования (0.5=1/2=2/4=4/8... и становится близкой к единице только если избыточность каким то образом убрать (например, взяв простые числа и пронумеровав их).
Блин, получается частный случай того что ты и привел. Да уж, лоханулся, заканчивал не МГУ, так что успокойтесь за честь диплома.

andr02

также наверняка если архивировать не всю последовательность целиком а куски то выгода очень даже будет.
Нука нука, у меня тут есть список хэшей, они все коротенькие 32 16 разрядные циферки - 16 байт кусочек. Сможешь сжать их с выгодой?

vamoshkov

"Беда в подборе чисел, которое может идти и 2 часа, а может идти и 2 недели. Есть опытные образцы и работающая программа, и всё это работает."
а 3 недели может идти? :)
а четыре?
он это все проверял как ты думаешь?
то что выгода будет очевидно.

очевидно что не будет :)

alexk01

ну и какой это класс файлов, как его можно описать?
Разве что учебник математики для 3 класса.

Vikuschechka9

Флешка, которую нельзя потерять
я бы по закону запретил терять такую флешку
поддержка со стороны думы подоспеет, ждите

alexk01

Вообще СЗМ в квардрате в этом разделе. Вопрос же не выходит за рамки школьного курса информатики по сути.
1. Ни один архиватор произвольную последовательность в общем случае не сожмет. То есть если X-случайная последовательность, равномерно выбранная из всех последовательностей длины n, f(X)-сжатая, то матожидание E(f(X>=n. На самом деле неравенство даже будет строгим.
2. Реальные последовательности байт распределены совсем не равномерно. Возьмем, например, текст. Он состоит в основном из прописных и строчных букв одного из алфовитов да нескольких спецсимволов. То есть кодировать символ можно 1 байтом, но реально он будет принимать не 256, а меньше сотни значений. уже потенциал для сжатия в 2,5 раза.
Да еще пробелы и буквы о встречаются гораздно чаще, чем х, ц и кавычки, а строчные буквы гораздо чаще чем прописные. это все можно использовать для сжатия.
Или, например, картинка. Рядом с черным пикселем гораздо чаще будет идти другой черный, чем белый.
Т.о. алгоритмы сжатия могут использовать статистические алгоритмы чтобы закодировать наиболее часто встречающиеся последовательности более короткими словами, а редкие - длинными. За счет этого на реальных (а не случайных равномерно распределенных) достигается выигрыш в объеме.
Повторюсь, выигрыш достигается за счет учета природы данных статистическими методами.
3. Предложенный парнем алгоритм никаких статистических методов не использует. Где он может быть полезен с учетом природы данных? Интуиция подсказывает, что разве что при кодировании большой последовательности рациональных чисел.

filippov2005

По теме - ничего предосудительного в произведенном студентом/школьнике не вижу.
А вот, что СМИ вместо того, чтобы найти экспертов и предупредить пользователей о низком качестве поделок (побочный общественно-полезный выход от СМИ наоборот раскручивают таких Петриков :( Имею в виду http://news.rambler.ru/17652044/
Оффтоп:
Жесть, форум МГУ :)
Дробная запись 0.123456789...
Забавно. Пост начинается с фразы, которая подтверждается самим постом :)
Результатом для 0.123456789 будет первая нечетная подходящая дробь, погрешность которой не более чем 10 в степени -[количество знаков в исходном числе], а именнно
  1356669/10989019 = 0.12345678900000082..., т.е в сумме 15 цифр плюс хранение длины.
Так как подходящая дробь p/q приближает не хуже, чем на 1/(q*q то как только число знаков в знаменателе превысит половину знаков исходного числа, ошибка станет меньше, чем в последнем знаке. Если при этом брать только нечетные подходящие дроби (которые всегда больше, чем то, что приближаешь то получится то, что надо - начало десятичной записи будет совпадать с исходным числом.

kastodr33

как ты определил что журнализды в полной мере изложили суть алгоритма?

sergur

По теме - ничего предосудительного в произведенном студентом/школьнике не вижу.
тут детально показывается, что всё это натуральное наебалово и петриковщина

filippov2005

А не, досмотрел текст по ссылке до конца.
Но это не столь важно. Обратите внимание на другое. Сзади на бланке: МФТИ и печать "ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ" и проч. Вы понимаете, что этот, с позволения сказать "документ", использовался им в конкурсе? И МФТИ по сути "заверило" результаты этих тестов.
Подделка документов это серьезно.

kastodr33

но-но, обсуждается конкретно алгоритм архивации и реализация его школьником.
СИтуация с "антивирусом" же - совсем мерзко пахнет.

vamoshkov

как ты определил что журнализды в полной мере изложили суть алгоритма?
:) :) :)
а про поиск чисел за 2 недели методом перебора не наврали, как думаешь? :)

vamoshkov

обсуждается конкретно алгоритм архивации и реализация его школьником.
срочно покупай:
сейчас работает над технологий архивации, позволяющей из 2 Gb фильма получить файл размером в 2-3 kb

там видео он сам об этом говорит, переврать тут журнализды ничего не могли

Asmodeus

2 Gb фильма получить файл размером в 2-3 kb
Так может он просто про ярлык говорит :o , Он же разархивацию не обещает ;)
Я тоже как-то на дискете знакомому 10 фильмов принес таким образом :o

a100243

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

vamoshkov

кажется я понял гениальную идею идею изобретателя как сохранить весь интернет на флешку

n2610

Это ведь доказательство невозможности сжать произвольную последовательность и невозможности универсального архиватора? Я его знаю в более наглядной форме (от противного) (своими словами, кто хочет может найти более правильную интерпретацию)- Допустим есть некий архиватор, который способен сжать произвольную входную последовательность на 1 бит. Следовательно, многократно использовав этот архиватор можно сжать любую произвольную последовательность до 0 бит. Отсюда следует что такого архиватора не существует.
Ты приводишь доказательство того, что не существует архиватора, способного уменьшить размер любой последовательности. У меня было доказательство более сильного и на практике представляющего больший интерес утверждения - что не существует архиватора, способного в среднем уменьшить размер последовательности.
@
1. Ни один архиватор произвольную последовательность в общем случае не сожмет. То есть если X-случайная последовательность, равномерно выбранная из всех последовательностей длины n, f(X)-сжатая, то матожидание E(f(X>=n.
Про это я уже писал.
На самом деле неравенство даже будет строгим.
Не будет. Есть очень много "архиваторов", для которых длина заархивированной последовательности равна длине исходной, и ещё больше архиваторов, для которых длина заархивированной последовательности иногда меньше длины исходной, но Ef(X) = n.

Lecha

в твоем же примере 0.123456789 до архивирования 9 цифр, а после архивирования будет 123456789 и 1000000000 - 19 цифр

10^n прекрасно ужимается. Главное - знать количество нулей :) Ну и как правильно было замечено, это не далеко единственный способ.

Jusun

Я подозреваю он просто неправильно понял, что такое арифметическое сжатие
Вот! Первая умная мысль за весь тред!
Я, правда, с ней не согласен и примерно на 80% уверен, что это не школьник написал черезжопный алгоритм, похожий на арифметическое сжатие, а что школьник как раз арифметическое сжатие и написал, но либо журнализды не поняли сути этого алгоритма и передали как смогли, либо школьник слегка переупростил объяснение.

a100243

что школьник как раз арифметическое сжатие и написал,
1. Арифметическое сжатие работает быстрее
2. Школьник в интервью сам сказал (а не журналисты переврали что у него коэффициент сжатия 1:1000, а такое уже ни один вменяемый программист делать бы не стал

seregaohota

интересно зачем HEX переводится в DEC
у Бабушкина с HEX проблемы, а к DEC он привык

seregaohota

В ответ на:
На самом деле неравенство даже будет строгим.
Не будет. Есть очень много "архиваторов", для которых длина заархивированной последовательности равна длине исходной, и ещё больше архиваторов, для которых длина заархивированной последовательности иногда меньше длины исходной, но Ef(X) = n.
тоже хотел написать ему, что ошибается - офигенный архиватор - записать файлы задом наперед, длина будет равна, или переставить четные-нечетные биты-байты...

seregaohota

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

Vikuschechka9

Школьник в интервью сам сказал (а не журналисты переврали что у него коэффициент сжатия 1:1000
он систему счисления указал? а то вдруг бинарная... хотя всё равно фейл)

vamoshkov

а то вдруг бинарная...
он словами говорил

denis24

На лурке нашел еще одну идею от Бабушкина.
У меня вообще много идей, например я знаю как увеличить скорость передачи файлов по интернету в тысячи и миллионы раз! Всё достаточно просто.
Дано:
Есть два компьютера, соединённых по интернету. На компьютере А есть файл, следует передать его на компьютер Б.
Решение:
Компьютеры одновременно начинают генерировать файлы (размером с оригинальный) псевдослучайным генератором чисел. Как только на компьютере А случайный файл совпадёт с оригинальным, А посылает один бит информации компьютеру Б, тем самым останавливая передачу. Таким образом осуществилась телепортация данных, мы можем передать файл любого размера при помощи только одного бита информации!
Конечно, сейчас нет таких технологий, но с исследованными графена и квантовых компьютеров эта технология станет новым стандартом передачи данных. Я уже готовлю документы на патент.

seregaohota

я думаю пора вдохнуть в теорему о бесконечных обезьянах в отношении России новую жизнь, скоро уровень образования по качеству сравняется с дипломом, продаваемым в переходе метро, бесконечные обезьяны одним словом + поддерживающая их власть
короче если посадить достаточно-большое число обезьян Бабушкиных за компы, то они рано или поздно запрограммируют любой антивирус-архиватор или напечатают Гамлет или передадут любой файл одним битом и весь интернет поместится на флешку

n2610

Вполне разумная идея, в духе Sleep sort

Romyk

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

seregaohota

ОК
ответил уже

stm7543347

Randomsort, скорее.
Или shuffle, или как там он по-научному называется...
Оставить комментарий
Имя или ник:
Комментарий: