Комментарии 1257
НЛО прилетело и опубликовало эту надпись здесь
Вам смешно, а парня в сколково возьмут ) инновации, прогресс…
того, который доктор? зеленое «изобретение» это видимо высокотехнологичная замена огурца )
Молодежь…
Вот правильная ссылка: quadregus
Вот правильная ссылка: quadregus
НЛО прилетело и опубликовало эту надпись здесь
Кстати Дениску Попова затравили до того, что он «ушел в искусство») Вроде как учится в каком-то муз.училище… Не состоялась у него блистательная карьера в IT…
Да ну? Он же на Лоре отписывался в прошлом году, народ даже его не троллил совсем, код там какой-то ему правили…
quadregus.livejournal.com/ вот его блог, там даже где-то была запись «с посвящения в школе искусств»)
На бокс ходит, вроде
да, отвратительно играет на фортепиано
Или Вы не о нем? :)
Не о нём. :)
НЛО прилетело и опубликовало эту надпись здесь
скорее уж его брат
BolgenOS второе пришествие?
Мда. Сейчас соберется 100+ комментариев про Дениса Попова
Второе пришествие Попова. :D
Мда. Сейчас соберется 100+ комментариев про Дениса Попова
P.s. это я не переспросил. А всего лишь написал комментарий несколькими секундами позже. Так уж случилось. Потом вставил цитату комментария выше (когда его увидел). Не нужно минусовать.
Прошу прощения за баян, но анекдоты становятся реальностью:
Разговаривают как то Потапов и Бабушкин:
— Слушай, вчера написал новый архиватор. Любой файл сжимает в 5 байт!
— Ну, просто рулез!..
— Ага. Сейчас работаю над разархиватором…
Разговаривают как то Потапов и Бабушкин:
— Слушай, вчера написал новый архиватор. Любой файл сжимает в 5 байт!
— Ну, просто рулез!..
— Ага. Сейчас работаю над разархиватором…
Это известный продукт, кстати. Архиватор Лыщенко. Причем, он еще более эффективен, чем в анекдоте.
PS
Ссылка как-то странно отображается, продублирую: www.lapsha.ru/articles/tech/2004/01/06/150700.html
PS
Ссылка как-то странно отображается, продублирую: www.lapsha.ru/articles/tech/2004/01/06/150700.html
Ну, я давно знаю такой архиватор MD5, благодаря этому у меня коллекция видео на 3.5 дискете )))))))))))))
и тоже с разархивацией туго ))))
и тоже с разархивацией туго ))))
Разархивировать можно через Rainbow table. Таблицы, правда, будут огого какие, но ведь можно!
Архивирую файлы встроенным в Windows архиватором. Вызывается по Shift+del, потом Enter. Очень сильно экономит место на диске.
Одному мне кажется, что выпуск новостей подозрительно похож на скандально известный? Даже фразы практически те же, не говоря уже о голосах пацана и ведущей :)
Сначала BolgenOS, теперь это…
И у всех первая мысль с Поповом связана.
И у всех первая мысль с Поповом связана.
"
Всё оказалось намного интересней. Благодарю, добавил в пост.
Ничего-ничего. Вот доведёт свой «проект» «Флешка-маркер» и однозначно в Сколково поедет. xD
как пишут на одном ресурсе — ждём ебилдов! :)
var 98 = «Еби гусей» ??? 0_o
Пароли ему уже везде поменяли, а то «Alexey456215» выглядит как то небезопасно.
Теперь я понял, почему Попов выбрал ник quadregus.
Quadregus <- квадрегусь <- четыре гуся.
С ним, оказывается, не только мысленная связь, но и половая.
Quadregus <- квадрегусь <- четыре гуся.
С ним, оказывается, не только мысленная связь, но и половая.
Жили у бабуси два весёлых гуся…
А я один на картинке про гусей увидел логин и пароль от сервера? O_o
А на болгенос встанет, интересно? А то Антивирус Попова скучен, да и обои надоели. Надеюсь, что аффтар сделает набор фанатских рулонов обоев.
… но уже приобрели несколько школ и компаний краевого центра.
Чей он там сынок?
Вот тут написано, что
Название программы Алексею помог придумать его отец — проректор по учебной работе медицинского университета.
НЛО прилетело и опубликовало эту надпись здесь
24 Февраля 2013 года. Где-то глубоко в Kaspersky Lab…
ИТАР-ТАСС: Студент Алтайского государственного политехнического университета создал антивирус. Его продукт, активно уничтожающий вирусные программы и занимающий скромный объем в ресурсах компьютера….
НЛО прилетело и опубликовало эту надпись здесь
кстати, можно задать вопрос этой милой девушке.
«всего лишь до 2-3kb»
ну это не сложно, сложнее сделать так, чтобы еще и «разжимал»
ну это не сложно, сложнее сделать так, чтобы еще и «разжимал»
Такой алгоритм давно уже придуман, формат архива — *.torrent :D
Он явно изобрел md5. Только вот разархивацию не сделал еще.
Ага, сжатие с потерей информации.
Зато правообладатели не страшны.
Я когда-то предлагал такое — искать содержимое файла в /dev/urandom. Вопрос был в том, насколько это легально — тогда мне сказали, что это всё равно считается копией.
Про хэши вопрос остаётся в силе — ведь можно сделать специально «слабый» алгоритм шифрования и доставать из его хэшей файлы как кроликов из шляпы.
Про хэши вопрос остаётся в силе — ведь можно сделать специально «слабый» алгоритм шифрования и доставать из его хэшей файлы как кроликов из шляпы.
>>Про хэши вопрос остаётся в силе — ведь можно сделать специально «слабый» алгоритм шифрования и доставать из его хэшей >>файлы как кроликов из шляпы.
Так нельзя же. Придется фильтровать все коллизии, попутно с нужным файлом, вам выгребет миллионы копий с тем же хэшем.
Так нельзя же. Придется фильтровать все коллизии, попутно с нужным файлом, вам выгребет миллионы копий с тем же хэшем.
Ничто не мешает сделать слабый алгоритм хэширования, не имеющий коллизий. Да и коллизий на фиксированной длине сообщений не так уж и много.
Математика мешает. Не сможете вы биекцию в любое подмножество сделать при фиксированном размере хеша. Да и биекция — это уже не хеширование, это уже шифрование будет.
Ну формально можно же хешировать файл блоками размером с сам хеш, для пущей надёжности. :)
А в чем суть? Мы же говорим про сжатие, а у вас тогда никакого сжатия не будет. Кроме того — даже в случае преобразования 1к1 по размерам — вам все равно нужна биекция, а это уже не тянет на хеш.
Тут по моему обсуждение плавно перетекло в тему «как лицензионно тырить нелицензионные фильмы» и просто если «какбы-хэшировать» фильм, а потом когда никто не видит — налету его доставать из этого псевдохэша. В итоге все довольны, фильма у меня нет, есть только его хэшь, а посмотреть я его могу
Разговор про «вытаскивание файлов из корзины» и сразу не был ни про шифрование, ни про хэширование.
А можно вообще блоками размером в один байт. Или в пару байтов. Или сколько-там-не-жалко процессорного время.
Извините, разве, например, SHA1 на размере его блока (20 байт, 160 бит), имеет коллизии? И имеет ли коллизии (самый слабый) алгоритм «хэширования» — XOR?
В конце концов, никто не мешает разбивать сообщение на части (хоть по байтам) и хэшировать именно их, «подбирая» в последствии эти блоки.
Вопрос тут в том, является ли это с юридической точки зрения копированием.
В конце концов, никто не мешает разбивать сообщение на части (хоть по байтам) и хэшировать именно их, «подбирая» в последствии эти блоки.
Вопрос тут в том, является ли это с юридической точки зрения копированием.
1) имеет.
2) XOR не имеет и это не хеширование
3) для чего это?
2) XOR не имеет и это не хеширование
3) для чего это?
Вы сводите множество А к множеству B, причём B гарантированно во много раз меньше А.
Вопрос: возможна ли взаимная однозначность?
Вопрос: возможна ли взаимная однозначность?
НЛО прилетело и опубликовало эту надпись здесь
А если множества бесконечные то «во много раз меньше» не определено (либо определено через невозможность взаимной однозначности).
>Я когда-то предлагал такое — искать содержимое файла в /dev/urandom.
Зачем вам тогда хэш? Вы ведь в /dev/urandom уже и так все фильмы имеете, даже которые еще не сняли.
Зачем вам тогда хэш? Вы ведь в /dev/urandom уже и так все фильмы имеете, даже которые еще не сняли.
Я как то озадачился в школе еще математикой. Если файл — это набор чисел, то в теории перебором можно получить любой файл картинку книгу. Начал считать количество переборов. Потом прикинул скорости текущих процессоров. Расстроился.
А если генерировать страницы текста, то там когда-то проскочит как создать лекарство от рака. Дело останется за малым – выбрать правильный вариант!
Будет трудно, потому что миллионы страниц будут озаглавлены «Лекарство от рака» и начинаться со слов «Возьмите свежий огурец и засуньте его...». Еще столько же будут описывать такое же применение соленого орурца. Миллиарды страниц вообще будет невозможно прочесть из-за того, что они будут написаны на древних языках в плохом транслите, а еще столько же — на русском с кучей ошибок.
Я ж и говорю: останется только выбрать правильный вариант :)
Слушайте, Вам с Вашим слогом надо фантастику писать. Попробуйте, я уверен: получится захватывающе и увлекательно :)
Волей судеб, пан Станислав тему тоже разрабатывал: dtskpl.ru/work/1076/,
«Путешествие шестое, или Как Трурль и Клапауций Демона Второго Рода создали, дабы разбойника Мордона одолеть»
«Путешествие шестое, или Как Трурль и Клапауций Демона Второго Рода создали, дабы разбойника Мордона одолеть»
Это было следующее что я понял. Надо фильтровать. Следующей идеей было представлять данные как архив и проверять на целостность. Но потом успокоился ))
Кроме шуток: многие проекты вида @home занимаются в том числе и Монте-Карло-подобным моделированием, либо «доставанием» случайных данных и их проверкой на пригодность.
Монте-Карло моделирование вообще довольно хорошо прижилось в науке, особенно в ядерной физике. Типично проводят набор моделирований и зависимость их результатов от входных параметров в дальнейшем используют как входные данные для машинного обучения: так работают LHC@home, Cosmology@home и т.д.
Монте-Карло моделирование вообще довольно хорошо прижилось в науке, особенно в ядерной физике. Типично проводят набор моделирований и зависимость их результатов от входных параметров в дальнейшем используют как входные данные для машинного обучения: так работают LHC@home, Cosmology@home и т.д.
я прям представил правообладателей с рулоном хэшей
Работает по принципу торрентов, но с использованием /dev/astral:
Тут аж 4 Гб до 16 байт «упаковано» :)
echo "md5sum=0373980cd6f270e1172067b86c044633 type=iso9660 size=4448059392" > /dev/astralctl
dd if=/dev/astral of=openSUSE.isoТут аж 4 Гб до 16 байт «упаковано» :)
Алексей Бабушкин
Про архивацию, вынудили:
Алгоритм архивации таков: любой файл представляет собой HEX-последовательность символов, переводим этот HEX в DEC, получаем неебически-большое число, дописываем перед этим число 0, — получаем число в диапазоне от 0 до 1 с огромным числом знаков после запятой, а дальше всё просто — подбираем 2 таких целочисленных числа, частное которых даст нам искомое число в диапазоне от 0 до 1 с точностью совпадений до последнего знака. Беда в подборе чисел, которое может идти и 2 часа, а может идти и 2 недели. Есть опытные образцы и работающая программа, и всё это работает.
В приннципе, что-то в этом есть. Сразу вспомнил статью, где нашли очередное самое большое простое число — может и не зря, в итоге, ищут :-).
Судя по алгоритму, любой файл у него должен представлять НЁХ-последовательность.
Я, возможно, не в теме, но в чем проблема представить набор единиц и ноликов в виде HEX-поседовательности?
Парень, конечно, зря про «восьмерку» заговорил в интервью, но нестандартные идеи у него есть — этого не отнять. А значит может выйти толк, главное мыслить outside of the box. А то налетели сразу, коршуны, лишь бы пообсасывать кому-то косточки.
Парень, конечно, зря про «восьмерку» заговорил в интервью, но нестандартные идеи у него есть — этого не отнять. А значит может выйти толк, главное мыслить outside of the box. А то налетели сразу, коршуны, лишь бы пообсасывать кому-то косточки.
все равно где-то будет прокол, будет два таких самых числа или подобное… потом распакованое видео «кубиками» будет )))
А ничего, что для большинства файлов оно найдёт два числа лет этак через пять, причём их запись будет длиннее исходного файла?
Касательно сроков — железо развивается (не вижу здесь препона: сегодня долго, завтра сможет делать ваш мобильник). Касательно того, что будет длиннее: я не математик, оспорить не могу (проще говоря, не знаю). Вы можете как-то доказать, что эти два числа «длиннее»?
НЛО прилетело и опубликовало эту надпись здесь
Если честно, вообще вас не понял («если некоторые меньше, значит некоторые больше»). Мне правда не очевидно, что запись этих двух чисел обязательно будет занимать, как минимум, тот же объем памяти (а то и больший) — может кто-то на пальцах объяснить?
О, пошла тяжелая артилерия по убиванию кармы — я бы, все-таки, был благодарен за человеческое объяснение, почему запись займет больше места, чем за молчаливый минус.
НЛО прилетело и опубликовало эту надпись здесь
В двух словах: есть ровно 2^31 разных 2-гибибайтных файлов (по определению количества информации). Им соответствует как минимум 2^31 разных архива (2 разных файла не могут быть представлены одним архивом). Если они разного размера, то есть как большие, так и меньшие (все архивы не могут быть меньше: не существует стольких разных файлов размером менее 2 гибибайт). В алгоритме нет никакой оптимизации под любой из часто встречающихся типов файлов, да и обещанное сжатие видео — нереально, следовательно, архив случайно взятого файла будет скорее больше исходного, чем меньше.
А архивы не могут быть одинакового размера?
2^(2^31)
Мне кажется, такое док-во не катит, т. к. про существующие алгоритмы сжатия аналогично можно доказать, что они не работают, но они ведь работают. Да, они учитывают особенности/избыточности существующих форматов, некоторые сжимают с потерями, но и этот странный алгоритм с делением может работать для каких-то наборов данных. Проще сказать, что «очевидно», что он почти никогда работать не будет)
Ну именно в том и дело, что каждый архиватор работает с конкретным типом данных (точнее, с данными имеющими характерные особенности). Белый шум ни один архиватор не сожмет, выйдет только больший файл.
Так тогда и доказывать надо, что этот алгоритм не подходит именно для какого-то типа данных, а не общий случай, что архиваторы не работают на белом шуме. Это неудачная попытка доказать умозрительную очевидность.
Понятно, когда такой алгоритм эффективен — когда данные периодичны с небольшим периодом, либо оканчиваются на много нолей. Понятно также, что это ужасно неуниверсально, и не может работать и на фильмах, и на документах. Непонятно совершенно, для какого типа данных оно предназначается, и на каком вообще может быть теоретически эффективно, по крайней мере без дополнительной обработки данных. (Не могу представить себе формат, в котором нельзя бы было поменять последний байт; к такому формату архиватор уже не подходит).
Но согласно вашей логике любой алгоритм сжатия — плохой. Если рассматривать его идею, не как идею архиватора, а как идею только алгоритма сжатия, то ваш контраргумент не работает.
В двух словах: есть ровно 2^31 разных 2-гибибайтных файлов (по определению количества информации). Им соответствует как минимум 2^31 разных архива (2 разных файла не могут быть представлены одним архивом)...
Звучит очень логично. Но теперь я, от недосыпа, не могу понять, как другие алгоритмы обходят эту логику.
Никак не обходят. Просто дело в том, что реально используемые алгоритмы архивации используют свойства реальных данных, например повторяющиеся последовательности.
Они хорошо работают на каком-то подмножестве входных файлов. Например, PPM — на текстах, JPEG — на фото, PNG — на графике и т. д.
Метод в сабже может сработать, скорее всего, на очень небольшом наборе искусственно сконструированных данных. Пример: если исходные файлы хранят десятичные представления дробей с большой точностью. Например, файл с 1 миллионом знаков после запятой дроби 23/713. Логично, что проще будет сохранить 23 и 713, чем мегабайт вида 0.0322580645161290032258064516129003225806451612900322580645161290…
Метод в сабже может сработать, скорее всего, на очень небольшом наборе искусственно сконструированных данных. Пример: если исходные файлы хранят десятичные представления дробей с большой точностью. Например, файл с 1 миллионом знаков после запятой дроби 23/713. Логично, что проще будет сохранить 23 и 713, чем мегабайт вида 0.0322580645161290032258064516129003225806451612900322580645161290…
JPEG тут вообще ни при чём, там сжатие с потерями, исходный файл из него не восстановить. Как и из mp3/mpeg4.
Да как же не причём — тоже алгоритм компрессии (если конечно сабж можно к ним вообще отнести)), хоть и с потерями, тоже работает на определённых частных случаях данных (фото). Дробями тоже можно приближать исходные данные с потерей точности (1/31 для числа выше), если это допустимо для конкретного вида данных.
Архивация = сжатие без потерь. Поэтому lossy-сжатие тут ни при чём.
Это лишь спор о терминах, сути это не меняет. В сабже топика речь про «сжатие». К тому же JPEG умеет сжимать и без потерь ru.wikipedia.org/wiki/JPEG-LS
Все просто. Предположим что у нас есть множество всех файлов объемом до 2Гб. Любой архиватор без потери — это биекция. Теперь мы утверждаем, что существует хотябы один файл, который архиватором «жмется».
Рассмотрим исходное множество как набор множеств (файлы в 1 байт, файлы в 2 байта, файлы в 3 байта и т.д. до 2Гб).
Пусть сжимаемый файл имеет размер K и сжимается до L. Тогда получается что в исходном пространстве количество всех файлов размера до L — больше чем осталось свободных ячеек размера до L в целевом пространстве (т.к. там находится архив файла размером K). Но т.к. архивация — это биекция, то мощность конечных множеств должна совпадать, а это значит что невозможно отобразить подмножество файлов размера до L в архивы размера до L, обязательно будут архивы больше размера L. Т.е. архиватор какие-то файлы сделает больше, чем они были до архивации.
Немного коряво вышло, но думаю идея математики понятна.
Рассмотрим исходное множество как набор множеств (файлы в 1 байт, файлы в 2 байта, файлы в 3 байта и т.д. до 2Гб).
Пусть сжимаемый файл имеет размер K и сжимается до L. Тогда получается что в исходном пространстве количество всех файлов размера до L — больше чем осталось свободных ячеек размера до L в целевом пространстве (т.к. там находится архив файла размером K). Но т.к. архивация — это биекция, то мощность конечных множеств должна совпадать, а это значит что невозможно отобразить подмножество файлов размера до L в архивы размера до L, обязательно будут архивы больше размера L. Т.е. архиватор какие-то файлы сделает больше, чем они были до архивации.
Немного коряво вышло, но думаю идея математики понятна.
Я правильно понял, что это относится к любому архиватору?
Хех, я матан с первого курса вспомнил благодаря комменту)
теория множеств же
Вообще — это не матан. В данном случае это мат. аппарат теории множеств.
Ну у меня это было в курсе матанализа. Так как я не математик, а физик, то, надеюсь, мне это простительно)
По-моему, это на уровне бытовых рассуждений можно понять, очень простая вещь.
Скажите это МГУ, в СУНЦе которого, на вполне математических направлениях, множества, почему-то, объясняются на матане.
Ну так это их ошибка. Я не могу быть ответственнен за это.
В СУНЦе всего три математики в расписании: геометрия, мат. ан и алгебра. Это не мешает затронуть куда больше разделов в пределах этих «официальных названий» курсов.
Взять и ввести пару или полпары ТМ, ТГ или ещё чего-нибудь? Получить дополнительные экзамены, бардак в расписании? Проще рассказать в рамках каких-нибудь основных курсов и/или спецкурсов.
Это, правда, совсем не освобождает от необходимости понимать к какому разделу относится тот или иной кусок курса.
Взять и ввести пару или полпары ТМ, ТГ или ещё чего-нибудь? Получить дополнительные экзамены, бардак в расписании? Проще рассказать в рамках каких-нибудь основных курсов и/или спецкурсов.
Это, правда, совсем не освобождает от необходимости понимать к какому разделу относится тот или иной кусок курса.
То же самое языком для человеков.
Предположим, что есть архиватор, который сжимает абсолютно любой файл, то есть размер архива всегда меньше размера исходного файла.
Тогда применяя этот архиватор много раз подряд, мы можем сжать любой файл до 0 байт.
Но такой файл нельзя распаковать:)
Предположим, что есть архиватор, который сжимает абсолютно любой файл, то есть размер архива всегда меньше размера исходного файла.
Тогда применяя этот архиватор много раз подряд, мы можем сжать любой файл до 0 байт.
Но такой файл нельзя распаковать:)
НЛО прилетело и опубликовало эту надпись здесь
Там немного более сильное условие было. В вашем случае архиватор, который не увеличивает файлы — прокатил бы. Но даже такое невозможно. Если что-то сжали, что-то надо увеличить.
архиватор, который не увеличивает файлы — прокатил бы. Но даже такое невозможно.Нет, необязательно. Просто несжимаемые данные вставляются неизменными.
НЛО прилетело и опубликовало эту надпись здесь
Формально так нельзя поступать, т.к. тогда мы не отличим файл архива от распакованных данных.
тогда мы не отличим файл архива от распакованных данныхВ условии об этом ничего, тащемта, не было.
Просто тогда архиватор будет некорректно работать в общем случае. Так что в условии это было, т.к. подразумевалась рабочая модель.
Можно имя менять. Дописывать .out к «сжатому». Кстати, этот чит подойдёт и для сжатия с реальным сжатием — несжимаемым файлам в имя «архива» будет дописываться спец. метка.
Ну такими темпами можно первые несколько символов файла вообще удалять и дописывать к его имени. Тогда архиватор будет все что угодно сжимать. Только это неправильно.
НЛО прилетело и опубликовало эту надпись здесь
А что тогда делать с файлом имя которого уже 256 символов (или сколько там максимально в данной фс).
Вы жестоки, но я осмелюсь оспорить это: «Архиватором Алексея — Можно!!!!»
Много раз нельзя, обычно уже после первой итерации вся информация, поддающая алгоритмическому «сжатию» уже закодирована. Все следующие итерации сжатия будут лишь незначительно увеличивать «архив» за счет добавления служебной информации от архиватора. Даже при использовании разных алгоритмов на итерациях, ситуация особо не изменится, так как все они сводятся к уменьшению информации благодаря кодированию повторяющихся данных или предсказуемых последовательностей.
То же самое языком для человеков.
Предположим, что есть архиватор, который сжимает абсолютно любой файл, то есть размер архива всегда меньше размера исходного файла.
Тогда применяя этот архиватор много раз подряд, мы можем сжать любой файл до 0 байт.
Но такой файл нельзя распаковать:)
У нас таким алгоритмом, некоторые умельцы, в университете конспекты (лекции) сжимали, в 0-байт информации! Причем к алгоритмам такого сжатия были допущены только избранные, в принципе если тетрадку не теряли в течении всего учебного процесса в ВУЗе, то ее хватало ровно на 5-ть лет!
доказали, что zip/rar/.… не могут работать)
Они и не работают, точнее работают в очень редких случаях) Например в тексте 17% объема занимают пробелы и поэтому тексты хорошо сжимаются.
Могут, но существуют такие файлы (например, те же архивы), результат работы архиватора на которых будет больше, чем входной файл.
НЛО прилетело и опубликовало эту надпись здесь
Естественно. Но это прекрасно укладывается в описанную выше математическую модель.
причём это можно закодировать 1 битом, ну или 1 байтом, для круглой цифры
НЛО прилетело и опубликовало эту надпись здесь
Не обязательно она будет неуспешной. Существует вариант, когда по случайности конец файла будет совпадать с контрольной суммой. И тогда архиватор некорректно работает.
НЛО прилетело и опубликовало эту надпись здесь
Лол, ветка один в один.
Потому что по сути — это часть информации, необходимая для разархивирования, только вынесенная в имя. Просто костыль, мат. модель от этого не изменилась. Если удалить эту информацию — однозначность теряется, мы не можем разархивировать файл. Не следует путать эту ситуацию с просто знанием о том, что файл — архив.
Для несжимаемых проверка контрольной суммы всегда будет неуспешной
Почти всегда) Если исходный файл был как раз данные+контрольная_сумма (намеренно или случайно) и его заархивировали (без сжатия, т. к. алгоритм его не смог сжать), то операция разархивирования будет пытаться его разархивировать, т. к. найдет верную контрольную сумму. Только это всё уже далеко от сабжа)
Вообще не ожидал от вас таких вопросов. ИМХО конечно, но программист, позиционирующий свою зарплату в $8К — всетаки должен знать математику на таком уровне.
Я боюсь, у нас с вами разные представления о задачах программистов (а также необходимых навыках). Да, действительно, не получится мне поддержать разговор о непрерывности по Дедекинду.
Дело не в хардкоре, это достаточно базовые вещи с точки зрения Computer Science.
Просто я не только программист (к слову, давно уже не программист в обычном понимании этого слова), который оправдывает свой ценник другим набором навыков (отличным от знания теории групп и т. д.).
Ну, а можете расшифровать набор навыков этот и объяснить, почему в него не входят базовые вещи из Computer Science и математики?
НЛО прилетело и опубликовало эту надпись здесь
Не факт, $8K — это прайс, который уже пол года висит в его резюме на hh.ru. Скорее попытка наняться в фирму, где начальство не соображает в IT, а IT отдел еще не создан. Тогда полный профит, никто и не укажет на его некомпетентность. Мы его приглашали к себе в уже существующий отдел — он отказался даже приходить на собеседование.
НЛО прилетело и опубликовало эту надпись здесь
Возможно, хотя, наверняка, бывают и исключения. Ну тем не менее такой персонал обычно подбирается через кадровые агенства, а они друг с другом сотрудничают в плане обмена данными о кандидатах, так что можно с большой долей вероятности говорить что конкретно данный кандидат теперь станет широко известен в этих кругах.
Понятно. Возможно я не прав, но был уверен, что важно знать пусть немного вещей — но на глубоком и хорошем уровне, чем знать много чего, но на посредственном.
Edited: ошибся веткой (ответ выше).
Это ответ на этот комментарий. Просто когда я отвечал, каменты выше еще не был отредактирован и был копией камента по ссылке.
Ваш комментарий:
По моему тут есть расхождения.
Эффект Даннинга — Крюгера — когнитивное искажение, которое заключается в том, что «люди, имеющие низкий уровень квалификации, делают ошибочные выводы и принимают неудачные решения, и не способны осознавать свои ошибки в силу своего низкого уровня квалификации». Это приводит к возникновению у них завышенных представлений о собственных способностях, в то время как действительно высококвалифицированные люди, наоборот, склонны занижать свои способности и страдать недостаточной уверенностью в своих силах, считая других более компетентными.
Ваш комментарий:
Просто я не только программист (к слову, давно уже не программист в обычном понимании этого слова)
По моему тут есть расхождения.
У нас поменялся порядок комментариев (подумал, что ответил в другую ветку и стер комментарий, опубликовав еще раз а оказалось, что достигнут предел вевления комментариев): получилось, что это вы написали про эффект Даннига, а я глупо оправдываюсь, говоря, что знаю, что это такое (опять с вами покормим троллей).
Даблпост, запутался в комментариях, тут был вот этот ответ.
Все верно (но и последнее отлично для выбора стратегии и направления движения, так сказать, helicopter view). Я знаю на глубоком, хорошем уровне другие вещи, которые нужны для задач, которые передо мной встают (плюс важно помнить, что помимо навыков есть другие вещи, на тему хватки, видения продукта, понимания ситуации и т. д.).
Просто то, что здесь сейчас обсуждают — не из их числа. Да, я не знаю этого, я осознаю это и мне не стыдно это признать (хотя бы потому, что я прекрасно знаю, в том числе, и такие вещи как эффект Даннинга-Крюгера).
Просто то, что здесь сейчас обсуждают — не из их числа. Да, я не знаю этого, я осознаю это и мне не стыдно это признать (хотя бы потому, что я прекрасно знаю, в том числе, и такие вещи как эффект Даннинга-Крюгера).
НЛО прилетело и опубликовало эту надпись здесь
>Я знаю на глубоком, хорошем уровне другие вещи, которые нужны для задач, которые передо мной встают (плюс важно помнить, что помимо навыков есть другие вещи, на тему хватки, видения продукта, понимания ситуации и т. д.).
Йес! Я знал, знал!
У вас офигенная хватка. Из двух бездарей (Попов, Бабушкин) вы выбрали того у которого папа круче. Какой же эффективный менеджер пройдёт мимо возможности отката. Хватка!
Продукт видите и ситуацию понимаете не в бровь, а в глаз! Пока ботаны расчехляют теорию множеств вы так проницательно поняли ситуацию с теми двумя файлами, которые можно пожать за время чуть меньшее половины бесконечности (и восстановить за время чуть меньшее трети бесконечности). Какое потрясающее виденье продукта!
Йес! Я знал, знал!
У вас офигенная хватка. Из двух бездарей (Попов, Бабушкин) вы выбрали того у которого папа круче. Какой же эффективный менеджер пройдёт мимо возможности отката. Хватка!
Продукт видите и ситуацию понимаете не в бровь, а в глаз! Пока ботаны расчехляют теорию множеств вы так проницательно поняли ситуацию с теми двумя файлами, которые можно пожать за время чуть меньшее половины бесконечности (и восстановить за время чуть меньшее трети бесконечности). Какое потрясающее виденье продукта!
Знаешь, иногда мне кажется что он прав и зачастую людям нужна супер мегасистема хранения с дикими скоростями записи. А то сроду они пишут пишут пишут, все равно потом никто ничего не читает. Тут главное правильно предложить /dev/null. Вот вы, ботаны, не сможете. А такие как Бабушкин и Попов запросто. И ведь продадут, и ведь потом за техподдержку попросят. А то что если вдруг понадобиться данные таки прочитать так «вы не правильно записали» или «а где файлик волшебный на ftp» или «у вас злобный вирус все удалил».
Какие с Вашей точки зрения знания (и допущение незнания смежных технологий, необходимые навыки ) должны быть, чтобы позиционировать желаемую компенсацию на таком уровне, основываясь на реалиях рынка?
Ну и, разумеется, я не вижу ничего зазорного не знать что-либо. Стыдно должно быть не задавать вопросов.
На примере частного случая: скажем, мы хотим закодировать число 1 таким способом. Дробь 0,1 получается путем деления 1 на 10. Таким образом, чтобы «заархивировать» всего одну цифру, нужно сохранить 3 цифры. Мне это уже кажется сомнительным.
Это частный пример: он не показывает, что подобное применимо всегда. На пальцах хорошо объяснили тут habrahabr.ru/post/170487/#comment_5914109
Таким образом, чтобы «заархивировать» всего одну цифру, нужно сохранить 3 цифры.
LOL
+1
Если так подходить с таким же успехом можно файлы по хешу собирать ( генерировать случайные последовательности байт, затем хешировать и сравнивать с эталонным хешем ). И когда наши миллионы обезьян с печатными машинками напишут Войну и Мир то будет вам результат.
Идеи может быть и клевые но теории сжатия информации она как бы никуда не денется. Либо с потерями, либо без. Сжать можно все хоть до одного бита, а как разжать?
> А значит может выйти толк
Парень — сынок проректора медуниверситета, у нас такие люди, как показывает опыт, с детства обречены на успех, какими бы выдающимися дебилами они б ни были
Парень — сынок проректора медуниверситета, у нас такие люди, как показывает опыт, с детства обречены на успех, какими бы выдающимися дебилами они б ни были
Разумеется. Простой пример — Билл Гейтс. Его мать поначалу неплохо лоббировала интересы сына. А поделия Билли были жуткими баянами и велосипедами в одном флаконе.
Ага. Разница в том, что в конечном итоге они работали.
Эта хрень — не работает.
Эта хрень — не работает.
Тогда BolgenOS — вполне нормально. Она же работает!
Болджен — это Убунта с перебитыми копирайтами. Переходя на метафоры, это эквивалент попытки купить Мерседес и приклеить на него шильдик VasyaSuperPuperCarShop, дабы выдать за свое творение.
Даже если говорить про DOS, то его Билли и сотоварищи хотя бы купили и доработали, что, в отличие от выходки Дениса и этого Алексея, не является зазорным и нелегальным актом.
Даже если говорить про DOS, то его Билли и сотоварищи хотя бы купили и доработали, что, в отличие от выходки Дениса и этого Алексея, не является зазорным и нелегальным актом.
НЛО прилетело и опубликовало эту надпись здесь
Пфф. Adobe очень много сделала для Flash с момента покупки его у Macromedia. Сравнение некорректное.
НЛО прилетело и опубликовало эту надпись здесь
К чему тогда вполне очевидная отсылка к Flash и его покупке? Думайте, прежде чем комментировать, что ли. HomeSite же — случай частный. Сони вон выкупила изначально убыточный Gakai, и перекрафтила его для работы игр предыдущих консолей на PS4.
В любом случае, даже если выкинуть из сравнения DOS — контора даже во времена Билли навыпускала достаточно вещей, достойных считаться винраром. 98SE, Винтукей, XP, Win7, первые, пускай и провальные таблети, и еще куча всего прочего — это все они. Некорректно сравнивать контору с сорокалетней историей с третьекурсником из Сибири и его антивирусом на батниках.
В любом случае, даже если выкинуть из сравнения DOS — контора даже во времена Билли навыпускала достаточно вещей, достойных считаться винраром. 98SE, Винтукей, XP, Win7, первые, пускай и провальные таблети, и еще куча всего прочего — это все они. Некорректно сравнивать контору с сорокалетней историей с третьекурсником из Сибири и его антивирусом на батниках.
Так еще и не вечер. Билл тоже начал бизнес на третьем курсе :))) Может Алексей сейчас накопит деньжат, купит лицензию на бесплатный антивирус и будет выпускать под своей маркой, но за деньги.
[Не относитесь к этому так пугающе серьезно.]
[Не относитесь к этому так пугающе серьезно.]
НЛО прилетело и опубликовало эту надпись здесь
Лол, вы еще и слепой. Пути, видимо, вы считаете невидимыми?
Ладно бы вы еще сравнили с Java, у которой первый апдейт после покупки всего барахла Ораклом заключался сугубо в замене логотипов, изрядно вешая все машины в процессе.
Ладно бы вы еще сравнили с Java, у которой первый апдейт после покупки всего барахла Ораклом заключался сугубо в замене логотипов, изрядно вешая все машины в процессе.
НЛО прилетело и опубликовало эту надпись здесь
Я же сказал, «первый» апдейт. Это вам не ванильная Миранда в последний год, где они версию выпускали при любом минорном коммите, накручивая счетчик версий. Оракл изрядно плюшек в Java принёс с момента покупки.
НЛО прилетело и опубликовало эту надпись здесь
Апдейты не от балды выходят, а из-за большого количества найденных в эти месяцы нуллдеев. Лучше бы, по вашему, они их не патчили?
А по сабжу, почему я не согласен — так потому, что большинство контор, скупающих что-либо, либо не лезут в уже сложившийся огород со своими граблями, и аккуратно продолжают существовавшую линию развития, либо перелопачивают все в лучшую сторону.
Взять тот же Skype (интеграция с Windows и Windows Live), Flash (поддержка ускорения на стороне клиента), Gakai (полный re-purpose сервиса под нужды компании).
Да господи, возьмите тот же Android. При всем уважении, у основателей проекта без денег и возможностей Google шансов на успех было минимум.
А по сабжу, почему я не согласен — так потому, что большинство контор, скупающих что-либо, либо не лезут в уже сложившийся огород со своими граблями, и аккуратно продолжают существовавшую линию развития, либо перелопачивают все в лучшую сторону.
Взять тот же Skype (интеграция с Windows и Windows Live), Flash (поддержка ускорения на стороне клиента), Gakai (полный re-purpose сервиса под нужды компании).
Да господи, возьмите тот же Android. При всем уважении, у основателей проекта без денег и возможностей Google шансов на успех было минимум.
А что в путях про Флэш? Почему не «C:\Program Files\Macromedia\Dreamweaver» и «C:\Program Files\Adobe\Dreamweaver»?
DOS — это тема отдельного разговора. Лицензионным соглашением на DOS Билл деформировал весь мир программного обеспечения, подставив его под копи-райт. Т.е. купил он в одном правовом поле, а продал в другом.
НО все же «Первая версия MS-DOS содержала множество ошибок которые пришлось исправлять программистам IBM». (Википедия) Это по поводу «доработали»…
НО все же «Первая версия MS-DOS содержала множество ошибок которые пришлось исправлять программистам IBM». (Википедия) Это по поводу «доработали»…
Ну, это сейчас не суть важно. Главное то, что Болдженос и эта поделка — абсолютно разные вещи. Поделие Дениса тянет на нарушение GPL в худшем случае (да и то всем было более или менее пофиг, учитывая, что денег он не просил за свою шайтан-хрень).
Этот же Алексей и его Иммунитет — фрод. Деньги берет, что-то там обещает, однако функционал заявленному не соответствует, при этом пациент тщательно отрицает бесполезность своего «изобретения». Статья 159 УК РФ в чистом виде. Никто, конечно, шуршать не будет, учитывая, кто его папаша и всякое такое разное, но квалификация — бесспорна.
Этот же Алексей и его Иммунитет — фрод. Деньги берет, что-то там обещает, однако функционал заявленному не соответствует, при этом пациент тщательно отрицает бесполезность своего «изобретения». Статья 159 УК РФ в чистом виде. Никто, конечно, шуршать не будет, учитывая, кто его папаша и всякое такое разное, но квалификация — бесспорна.
В общем то где то в споре произошла подмена тезиса…
Я, собственно, привел пример на «у нас такие люди, как показывает опыт, с детства обречены на успех, какими бы выдающимися дебилами они б ни были „
И доказывать, что Денис или Алексей правы не собираюсь…
Я, собственно, привел пример на «у нас такие люди, как показывает опыт, с детства обречены на успех, какими бы выдающимися дебилами они б ни были „
И доказывать, что Денис или Алексей правы не собираюсь…
Вы выразили согласие и сравнили условного БГ с условным Алексеем, назвав первого по аналогии со вторым, «дебилом». Я подчеркнул некорректность вашего сравнения, дополнив это живым примером. Всё.
Должен прямо признать. ИМХО уровень «дебилизма» условного Алексея — выше. НО еще не известно, что о Билли его однокурсники думали.
Мать? Gates's maternal grandfather was J. W. Maxwell, a national bank president
Мать тоже по банкам ходила.
А в итоге япошки по совету дедушки приняли на вооружение его ОСь.
Мать тоже по банкам ходила.
А в итоге япошки по совету дедушки приняли на вооружение его ОСь.
НЛО прилетело и опубликовало эту надпись здесь
около 10 в 9й степени знаков после запятой, если не ошибаюсь, удачи в хранении, вспоминается результат деления 1 на 10, который возвращает не 0,1, а 0,1000000001 примерно.
ошибся, извиняюсь, спать надо ложиться.
2^(2^31) знаков после запятой.
2^(2^31) знаков после запятой.
Но сама-то запись числа не 2 ГБ будет. Осталось «малое»: находить такие числа для нужных файлов.
Ну решение в лоб:
берем десятичное представление файла(пусть будет K), считаем количество знаков(n).
далее ищем НОД(K,10^n) 2 искомых числа НОД и K/НОД
Лучше ничего не придумывается, да и это не уверен, что будет работать
Если я правильно понимаю, то в лучшем случае будет НОД около Корень из K
и тогда итоговая запись примерно равна 2*sqrt(K)
берем десятичное представление файла(пусть будет K), считаем количество знаков(n).
далее ищем НОД(K,10^n) 2 искомых числа НОД и K/НОД
Лучше ничего не придумывается, да и это не уверен, что будет работать
Если я правильно понимаю, то в лучшем случае будет НОД около Корень из K
и тогда итоговая запись примерно равна 2*sqrt(K)
The 22.5-megabyte text file containing the full number of digits can be downloaded from the GIMPS website.
Ну если точнее 1/10 даёт 0.0(0011)2, т.е. 0.000110011001100110011… в двоичной записи. Хрестоматийный пример, почему нельзя округлять по одной двоичной цифре.
Да, где-то года 4 назад мы пытались воспользоваться этой методикой, чтобы запихнуть гуид в 10 цифр.
К сожалению, оказалось, что шанс нахождения пары чисел, которые дадут нужную точность и будут подходить по объему — статистически незначимое событие.
То есть я могу представить десятка два файлов, сжатых по такой технологии в десятки раз, но «читаемой информации» в таких файлах не будет.
К сожалению, оказалось, что шанс нахождения пары чисел, которые дадут нужную точность и будут подходить по объему — статистически незначимое событие.
То есть я могу представить десятка два файлов, сжатых по такой технологии в десятки раз, но «читаемой информации» в таких файлах не будет.
НЛО прилетело и опубликовало эту надпись здесь
Если не ошибаюсь у Мураками в «Норвежском лесу» это было описано. Только применительно к представлению всей человеческой жизни в виде одной зарубке на палочке
А я впервые об этом прочитал у Харуки Мураками в «Страна чудес без тормозов и конец света», где наносилась засечка на зубочистку.
Ещё был забавный случай, когда у нас в универе собирался на чтениях выступить человек, который искал слова в числе Пи и видел в этом какой-то смысл. К счастью для него, он не приехал.
Ещё был забавный случай, когда у нас в универе собирался на чтениях выступить человек, который искал слова в числе Пи и видел в этом какой-то смысл. К счастью для него, он не приехал.
«В далеких шестидесятых, когда компьютеры были большими, а 20-мегабайтовые винчестеры напоминали собой стиральные машины, родилась одна из красивейших легенд о зеленом инопланетном существе, прилетевшим со звезд и записавшим всю Британскую энциклопедию на тонкий металлический стержень нежно-серебристого цвета, который существо и увезло с собой.
Сегодня, когда габариты 100 Гб жестких дисков сократились до размеров сигаретной пачки, такая плотность записи информации уже не кажется удивительной и даже вызывает улыбку. Но! Все дело в том, что инопланетное существо обладало технологией записи бесконечного количества информации на бесконечно крошечном отрезке и Британская энциклопедия была выбрала лишь для примера. С тем же успехом инопланетянин мог скопировать содержимое всех серверов Интернета, нанеся на свой металлический стержень всего одну-единственную риску.
Не верите? А зря! Переводим Британскую энциклопедию в цифровую форму, получая огромное-преогромное число. Затем — ставим впереди него запятую, преобразуя записываемую информацию в длиннющую десятичную дробь. Теперь только остается найти два числа A и B, таких, что результат деления A и B как раз и будет равен данному числу с точностью до последнего знака. Запись этих чисел на металлических стержень осуществляется нанесением риски, делящей последний на два отрезка с длинами, кратными величинам А и B соответственно. Для считывания информации достаточно всего лишь измерить длины отрезков А и B, а затем — поделить один на другой. Первый десяток чисел после запятой будет более или менее точен, ну а потом…
Потом жестокая практика опустит абстрактную теорию по самые помидоры, окончательно похоронив последнюю под толстым слоем информационного мусора, возникающего из невозможности точного определения геометрических размеров объектов реального мира.»
Это написал Крис Касперски, причем по-моему еще в конце 90-х.
подбираем 2 таких целочисленных числа, частное которых даст нам искомое число в диапазоне от 0 до 1 с точностью совпадений до последнего знака.
ага, и эти два целочисленных числа потребуют объем памяти больший, чем исходный файл. И вообще, зачем я эту чушь прочитал…
Так, оставить такое на Хабре, у нас тут не новости!
Ничего в этом нет. Вместо одного большого числа будет числитель и знаменатель. В худшем случае с тем же количеством знаков каждый. Вообще если мы приписали к числу 0, в начале, то это уже дробь N/10^(int(log10(N)+1), можно попробовать сократить на наибольший общий делитель (очень быстрый алгоритм), вот только экономия будет копеечная.
А числитель и знаменатель размером с исходный файл.
Ну и вообще, универсального архиватора не существует. Каждый архиватор или работает с потерей точности или хорошо жмёт некоторые последовательности. Алгоритмы подбирают так, чтобы эти последовательности были часто используемыми людьми.
Например код Хаффмена любит неравномерное использование текстов, LZW — повторяющиеся цепочки.
Ничего в этом нет. Вместо одного большого числа будет числитель и знаменатель. В худшем случае с тем же количеством знаков каждый. Вообще если мы приписали к числу 0, в начале, то это уже дробь N/10^(int(log10(N)+1), можно попробовать сократить на наибольший общий делитель (очень быстрый алгоритм), вот только экономия будет копеечная.
А числитель и знаменатель размером с исходный файл.
Ну и вообще, универсального архиватора не существует. Каждый архиватор или работает с потерей точности или хорошо жмёт некоторые последовательности. Алгоритмы подбирают так, чтобы эти последовательности были часто используемыми людьми.
Например код Хаффмена любит неравномерное использование текстов, LZW — повторяющиеся цепочки.
Существуют файлы, для которых коэффициент сжатия этого «алгоритма» очень высок. Пример. Файл: 07692307692307693. Архив: числа 1 и 13 + длина разархивированного файла.
Только вот зачем кому-то может понадобиться сжимать файлы такого вида?
Это всего лишь контрпример к вашему утверждению, что «числитель и знаменатель будут с исходный файл». Не исключаю, что могут существовать осмысленные файлы, которые хорошо сжимаются этим «алгоритмом». Это вопрос отдельного исследования, а пока критика этого алгоритма в основном по уровню аргументации не выше уровня аргументации сабжа.
Эвристически понятно что эффективно сжимаемые последовательности будут абсолютно случайными.
А у сабжа аргументация почему по этому вопросу в принципе отсутствует.
А у сабжа аргументация почему по этому вопросу в принципе отсутствует.
Ещё можно сжимать не целиком файл, а искать последовательности бит, которые хорошо представляются короткими дробями. Плюс можно сжимать с потерей точности, если дробь примерно равна исходной последовательности.
Вообще не очевидно, что это нельзя никак применить. Есть подозрение, что математически точно это не доказать, т. к. и существующие форматы данных математически точно не описаны. Даже если описать (хотя бы самый простой — plaintext с известными частотами букв/слогов/слов/фраз), то замучаешься доказывать, что их не сжать каким-то методом. А это придется отдельно доказывать для каждого формата…
Поэтому метод считаем не рабочим, пока не доказано обратное на практике)
Вообще не очевидно, что это нельзя никак применить. Есть подозрение, что математически точно это не доказать, т. к. и существующие форматы данных математически точно не описаны. Даже если описать (хотя бы самый простой — plaintext с известными частотами букв/слогов/слов/фраз), то замучаешься доказывать, что их не сжать каким-то методом. А это придется отдельно доказывать для каждого формата…
Поэтому метод считаем не рабочим, пока не доказано обратное на практике)
Конечно существуют! Вот только нужны ли они в жизни? Как часто нам надо паковать такие последовательности?
А теперь давайте чуть-чуть изменим конец файла, 076923076923076931. Просто дописали единичку, как это повлияет на алгоритм? Какие надо взять числитель и знаменатель в данном случае?
Тот же LZW счавкает и не подавится.
А теперь давайте чуть-чуть изменим конец файла, 076923076923076931. Просто дописали единичку, как это повлияет на алгоритм? Какие надо взять числитель и знаменатель в данном случае?
Тот же LZW счавкает и не подавится.
Я не знаю ответа на ваш вопрос. Но, подозреваю, что и вы не знаете. Я думаю, что «алгоритм», предложенный Бабушкиным абсолютно не эффективен на практике. Я зашёл на Хабр, ожидая, что тут будут внятные комментарии с корректным обоснованием неэффективности. А я вижу аргументацию уровня не выше, чем та, что цитируется в ролике. Общие слова, которые никак
Что доказывает ваш контрпример? Вы считаете, что не существует примера неэффективности LZW?
Что доказывает ваш контрпример? Вы считаете, что не существует примера неэффективности LZW?
Главное — он не пользуется тем, что это именно видео. А несложно понять, что нельзя написать архиватор, который сжимает все файлы.
Кажется, парень изобрёл арифметическое кодирование?
Эмм… пацан узнал про алгоритм арифметического кодера, и где-то краем ухе даже уловил идею предикторов?) Боюсь что приз Хаттера он с таким алгоритмом не возьмет...PAQ уже затюнили до невозможности и вроде до сих пор не смогли получить сжатый файл с размером, меньше чем 11-12% от исходного.
А он вообще в курсе как числа в компьютере делятся? Погрешности вычислений и прочая «ерунда»…
Это вообще то материал первого курса…
Это вообще то материал первого курса…
Алгоритм этот еще из 80х, смысл такой, подбирается пара чисел например 23 и 43, которые при делении дают какое-то число, в данном случае 23/43=0.534883720930233, если брать за основу например по 3 цифры и создавать из них число, то получится (534,883,720,930,233), т.е. фактически из двух чисел мы получили 5. Компрессия получается в 2-3 раза, но тут бонус, что можно повторно пробовать компрессировать. На практике все упирается в скорость подбора таких чисел.
Очевидно, что размер полученных чисел (которые делим) будет практически всегда больше размера начального числа (дроби, которую получаем).
Поэтому идет выборка и отбираются только те, которые меньше, как в примере наверху.
Не совсем понял, какая выборка? В любом случае, последовательностей бит значительно меньшей длины, чем исходный файл, много меньше, чем последовательностей длины равной файлу. Следовательно, если алгоритм сжимает некоторые файлы, то другие (причём большее количество) он будет увеличивать в размере. Это верно и для обычных архиваторов, но только они в отличие от этого алгоритма используют закономерности в реальных данных, поэтому часто сжимают реальные файлы.
Разговор идет про небольшие участки данных, к которым можно подобрать два числа при делении которых они дают нужную последовательность, при меньшей длинне. Если например для текущего блока подбор таких чисел невозможен, то эти данные можно компрессировать обычным путем.
НЛО прилетело и опубликовало эту надпись здесь
Любой метод сжатия часть исходных данных сжимает, а остальные наоборот увеличивает в размерах.
У хороших методов множество хорошо сжимаемых данных примерно совпадает с разумными вещами (тексты, картинки etc.). У данного же метода это множество скорее всего рандомно, так что никакой пользы он не несет.
У хороших методов множество хорошо сжимаемых данных примерно совпадает с разумными вещами (тексты, картинки etc.). У данного же метода это множество скорее всего рандомно, так что никакой пользы он не несет.
Кстати это плагиат. Это описание встречается в фантастической книге, где инопланетяне увозят всю информацию человечества, сделав засечку на металлическом стержне таким образом, что соотношение частей стержня равно 0, число соответствующее всему объему информации.
Мы тут в узком кругу обсуждали данный способ архивации данных чисто умозрительно, и пришли к выводу что он будет работать в одном единственном случае: если инопланетянине имеют способ БЕСКОНЕЧНО ТОЧНО измерять расстояние, наплевав на все квантовые эффекты атомарные размеры материала.
Мы тут в узком кругу обсуждали данный способ архивации данных чисто умозрительно, и пришли к выводу что он будет работать в одном единственном случае: если инопланетянине имеют способ БЕСКОНЕЧНО ТОЧНО измерять расстояние, наплевав на все квантовые эффекты атомарные размеры материала.
«Алгоритм архивации таков: любой файл представляет собой HEX-последовательность символов, переводим этот HEX в DEC, получаем неебически-большое число, дописываем перед этим число 0, — получаем число в диапазоне от 0 до 1 с огромным числом знаков после запятой, а дальше всё просто — подбираем 2 таких целочисленных числа, частное которых даст нам искомое число в диапазоне от 0 до 1 с точностью совпадений до последнего знака.....»
спасибо, повесилили)
с нетерпением жду хотябы одного примера с результатами работы алгоритма для оч. частного случая (например для простенькой jpeg картинки)
нет, не могу ждать примера, так весело, что сам пытаюсь привести пример:
1) и так мы хотим «заархивировать файл длинною 2 байта „0xE8 0x9A“
2) десятичное представление 232 154 (»неебически-большое число")
3) 0.232154 ( дописываем перед этим число 0, — получаем число в диапазоне от 0 до 1 с огромным числом знаков после запятой)
4) подбираем 2 таких целочисленных числа, частное которых даст нам искомое число в диапазоне от 0 до 1 с точностью совпадений до последнего знака
1/0.232154 = 4.307486 = 4307486 / 1000000 = > упроситим (найдем все простые делители, холявлю пользуюсь функцией «factorize» в R из библиотеки «gmp»)
factorize(1000000) = 2 2 2 2 2 2 5 5 5 5 5 5
factorize(4307486) = 2 23 29 3229
(ура можно сократить 1 делитель = 2)
нашли два числа: 23*29*3229 = 2153743 (знаменатель)
500000 (числитель)
проверяем 500000/2153743 = 0.232154
ЗАШИБИСЬ ЗААРХИВИРОВАЛИ 2 байта «0xE8 0x9A» 2 числами 500000: 2153743
продалжаю смеяться над алгоритмом (
спасибо, повесилили)
с нетерпением жду хотябы одного примера с результатами работы алгоритма для оч. частного случая (например для простенькой jpeg картинки)
нет, не могу ждать примера, так весело, что сам пытаюсь привести пример:
1) и так мы хотим «заархивировать файл длинною 2 байта „0xE8 0x9A“
2) десятичное представление 232 154 (»неебически-большое число")
3) 0.232154 ( дописываем перед этим число 0, — получаем число в диапазоне от 0 до 1 с огромным числом знаков после запятой)
4) подбираем 2 таких целочисленных числа, частное которых даст нам искомое число в диапазоне от 0 до 1 с точностью совпадений до последнего знака
1/0.232154 = 4.307486 = 4307486 / 1000000 = > упроситим (найдем все простые делители, холявлю пользуюсь функцией «factorize» в R из библиотеки «gmp»)
factorize(1000000) = 2 2 2 2 2 2 5 5 5 5 5 5
factorize(4307486) = 2 23 29 3229
(ура можно сократить 1 делитель = 2)
нашли два числа: 23*29*3229 = 2153743 (знаменатель)
500000 (числитель)
проверяем 500000/2153743 = 0.232154
ЗАШИБИСЬ ЗААРХИВИРОВАЛИ 2 байта «0xE8 0x9A» 2 числами 500000: 2153743
продалжаю смеяться над алгоритмом (
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Два байта алгоритм Хаффмана определённо не сожмёт. Хотя бы в силу того, что потребуется передавать таблицу кодов. Ну и не стоит забывать, что в реальном мире при кодировании по Хаффману на любой символ будет отводиться не меньше одного бита.
Хаффману нужно еще рядом с кодом положить получившееся дерево, так что не сожмет
гы-гы-гы)
возьмите не архиватор, а алгоритм архивации и хоть на одном байте эксперементируйте)
p.s. ровно так «в детстве» и заставляли делать на «теории информации»
хорошо, устроим более сложное испытание 10 байт:
1) 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x0A 0x09
2) десятичное представление: 1 2 3 4 5 6 7 8 10 9 (такой хреновый у меня в голове генератор)
3) 0.12345678109
1/0.12345678109 = 8.100001
4) 8100001 = 241*3361
ответ: два числа 1000000:8100001 ого наархивировали!
20 бит + 23 бита заархивировали 10 байт (80 бит). Только вот незадача, кодировали мы 10 4 битных чисел, а не 80 бит и упростили выкинув нолики. Архивация зашибись. Уверен, что автор придумал его (глупости просто придумывать с умными словами), а вот как реализовать не удосужился ( это же «невьебенно-большое число») и почему-то надеется, что будут идеально маленькие числа ))) — ну с кем не бывает
это напомниает собственный «гениальный» (как мне на секунду показалось) алгоритм оптимизации: «перебираем 100 переменных случайными значениями и ждем пока не выпадет оптимальной комбинации» — не находит? блин — выделяем больше ресурсов и ждем месяц (вдруг найдутся крутые оптимальные комбинации) — через месяц смотрим на лучшее, что нашлось — как был мусор так и остался)
возьмите не архиватор, а алгоритм архивации и хоть на одном байте эксперементируйте)
p.s. ровно так «в детстве» и заставляли делать на «теории информации»
хорошо, устроим более сложное испытание 10 байт:
1) 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x0A 0x09
2) десятичное представление: 1 2 3 4 5 6 7 8 10 9 (такой хреновый у меня в голове генератор)
3) 0.12345678109
1/0.12345678109 = 8.100001
4) 8100001 = 241*3361
ответ: два числа 1000000:8100001 ого наархивировали!
20 бит + 23 бита заархивировали 10 байт (80 бит). Только вот незадача, кодировали мы 10 4 битных чисел, а не 80 бит и упростили выкинув нолики. Архивация зашибись. Уверен, что автор придумал его (глупости просто придумывать с умными словами), а вот как реализовать не удосужился ( это же «невьебенно-большое число») и почему-то надеется, что будут идеально маленькие числа ))) — ну с кем не бывает
это напомниает собственный «гениальный» (как мне на секунду показалось) алгоритм оптимизации: «перебираем 100 переменных случайными значениями и ждем пока не выпадет оптимальной комбинации» — не находит? блин — выделяем больше ресурсов и ждем месяц (вдруг найдутся крутые оптимальные комбинации) — через месяц смотрим на лучшее, что нашлось — как был мусор так и остался)
тфу округлил в R криво (
1/0.12345678109 = 8.10000059269
4) 810000059269= 71*181*63030119
ответ: два числа 100 000 000 000/810 000 059 269
2 числа (40 бит и 37 бит) заархивировали 10 байт (80 бит). правда кодировали мы 10 4 битных чисел, а не 80 бит и упростили выкинув нолики.
1/0.12345678109 = 8.10000059269
4) 810000059269= 71*181*63030119
ответ: два числа 100 000 000 000/810 000 059 269
2 числа (40 бит и 37 бит) заархивировали 10 байт (80 бит). правда кодировали мы 10 4 битных чисел, а не 80 бит и упростили выкинув нолики.
Одна беда с вашим алгоритмом архивации — данные из него восстановить не получится, несмотря на то, что 0.12345678109 после 0 совпадает с исходными данными. Как без таблицы расположения исходных чисел понять где заканчивается одно исходное число и начинается следующее?
Мне подобный алгоритм пришел в голову еще в классе десятом, но проведя пару экспериментов убедился, что на практике он работать не будет — устанет компьютер подбирать нужные делители, да и с таблицей размещения байт тоже нужно что-то думать, иначе она будет размером с исходный файл, а то и поболее.
Мне подобный алгоритм пришел в голову еще в классе десятом, но проведя пару экспериментов убедился, что на практике он работать не будет — устанет компьютер подбирать нужные делители, да и с таблицей размещения байт тоже нужно что-то думать, иначе она будет размером с исходный файл, а то и поболее.
с моим алгоритом? боже упаси — я просто смеюсь над ним)))
да, да, уже когда строил тоже подумал, что нужно ещё служебную инфо хранить об интерпретации (но это тонкости) — даже оценка снизу получается полный швах) надежда, что у двух чисел (числителя и знаменателя) сопоставимых по размеру с первоначальным числом, будем много общих делителей (чтобы сильно сократилось) довольно наивная)
в теории чисел не силен и довольно смутно представляю картинку как факторизируются натуральные числа, но первый взгляд на распределение простых числе подсказывает, что надежды что у произвольного числа много делителей 2 и 5 не много (при переводе из десятичной дроби числитель всегда оказывается числом 10 в степени N это означаетс что у него будет по N простых делителей 2 и 5) собственно только на них и может сократиться…
да, да, уже когда строил тоже подумал, что нужно ещё служебную инфо хранить об интерпретации (но это тонкости) — даже оценка снизу получается полный швах) надежда, что у двух чисел (числителя и знаменателя) сопоставимых по размеру с первоначальным числом, будем много общих делителей (чтобы сильно сократилось) довольно наивная)
в теории чисел не силен и довольно смутно представляю картинку как факторизируются натуральные числа, но первый взгляд на распределение простых числе подсказывает, что надежды что у произвольного числа много делителей 2 и 5 не много (при переводе из десятичной дроби числитель всегда оказывается числом 10 в степени N это означаетс что у него будет по N простых делителей 2 и 5) собственно только на них и может сократиться…
НЛО прилетело и опубликовало эту надпись здесь
почему нельзя? обычная дедукция, несколько примеров могут помочь увидить закономерность — могут и не помочь конечно, но в данном случае мне немного помогло (впрочем, как и помогли Ваши сомнения, что ничего не надо делать — пока считал 2й пример для 10 байт ещё немного понял закономерности)
можно же понять как работает алгоритм… это лишь разложение на простые числа числителя и знаменателя,
числитель всегда оказывается числом 10 в степени N (т.к. десятичную дробь хочет чувак анализировать) это означает, что у него будет по N простых делителей 2 и 5) собственно только на них и может сократиться со знаменателем… вероятность, что в простых делителях знаменателя будет много чисел 2 и 5… можете сами посчитать сколько дожно быть этих простых делителей чтобы хотябы до первоночального представления данных добраться))хотя чего себя обанывать — ничего вы считать не будете)))
можно же понять как работает алгоритм… это лишь разложение на простые числа числителя и знаменателя,
числитель всегда оказывается числом 10 в степени N (т.к. десятичную дробь хочет чувак анализировать) это означает, что у него будет по N простых делителей 2 и 5) собственно только на них и может сократиться со знаменателем… вероятность, что в простых делителях знаменателя будет много чисел 2 и 5… можете сами посчитать сколько дожно быть этих простых делителей чтобы хотябы до первоночального представления данных добраться))хотя чего себя обанывать — ничего вы считать не будете)))
НЛО прилетело и опубликовало эту надпись здесь
ключевое слово «эффективное сжатие»,
а тут чувак предлагает глупость (понять что это глупость а не алгоритм сжатия можно и на простом примере)
и если человечеству поставить цель снимать фильтмы, чтобы найти среди них такой, чтобы хоть 1 из них этим алгоритмом было бы можно сжать (хотябы не меньше своего объема) то возможно что до конца дней вселенной не найдется ни одного такого фильма))))
а тут чувак предлагает глупость (понять что это глупость а не алгоритм сжатия можно и на простом примере)
и если человечеству поставить цель снимать фильтмы, чтобы найти среди них такой, чтобы хоть 1 из них этим алгоритмом было бы можно сжать (хотябы не меньше своего объема) то возможно что до конца дней вселенной не найдется ни одного такого фильма))))
348 / 1499
+
да это хорошая новость, что есть надежда, что можно найти получше значения чем факторизацией
правда плохая новость для алгоритма в этом примере, что для хранения двух чисел необходимы 9 + 11 бит (overhead на хранение точности, можно в рассчет не брать) при попытке закодировать 16 бит
Если поиск прямым перебором: то алгоритмическая сложность по-моему получается O(10^2n) — гыгы)
да это хорошая новость, что есть надежда, что можно найти получше значения чем факторизацией
правда плохая новость для алгоритма в этом примере, что для хранения двух чисел необходимы 9 + 11 бит (overhead на хранение точности, можно в рассчет не брать) при попытке закодировать 16 бит
Если поиск прямым перебором: то алгоритмическая сложность по-моему получается O(10^2n) — гыгы)
Я разделяю вашу точку зрения, но ради точности не могу не отметить, что более короткой дробью, равной 0.232154..., будет 361/1555.
Я вам даже больше скажу, что если отказаться от базовой идеи простых дробей и разрешить функции, то можно сжать до
4-35 * Lambda
Где Lambda — это One-Ninth Constant (http://mathworld.wolfram.com/One-NinthConstant.html)
Так как знаки ±/* можно кодировать менее чем 8 бит, а константы вписывать в словарь и тоже максимально коротко записывать, то можно реально сжать. (трудоёмкость будет ужасной, но что делать)
4-35 * Lambda
Где Lambda — это One-Ninth Constant (http://mathworld.wolfram.com/One-NinthConstant.html)
Так как знаки ±/* можно кодировать менее чем 8 бит, а константы вписывать в словарь и тоже максимально коротко записывать, то можно реально сжать. (трудоёмкость будет ужасной, но что делать)
гыгы)
тому кто хоть для одного фильма найдет два таких числа (хоть и толку для архивации никакой — т.к. занимать они будут примерно в 1.5-2 раза больше места чем первоначальный фильм) можно претендовать на премию $150К от (Electronic Frontier Foundation) т.к. возможно что по дороге к применению этого «гениального» алгоритма к 2 гбайтному файлу придется разложить число на простые числа с парой десятков миллиардов цифр и возможно не получится отделаться известными простыми числами в 60 млн. знаков)
«100 million-digit prime number, could fetch a $150,000 prize from the Electronic Frontier Foundation, a San Francisco-based nonprofit.»
тому кто хоть для одного фильма найдет два таких числа (хоть и толку для архивации никакой — т.к. занимать они будут примерно в 1.5-2 раза больше места чем первоначальный фильм) можно претендовать на премию $150К от (Electronic Frontier Foundation) т.к. возможно что по дороге к применению этого «гениального» алгоритма к 2 гбайтному файлу придется разложить число на простые числа с парой десятков миллиардов цифр и возможно не получится отделаться известными простыми числами в 60 млн. знаков)
«100 million-digit prime number, could fetch a $150,000 prize from the Electronic Frontier Foundation, a San Francisco-based nonprofit.»
Не предется, дроби можно сокращать без факторизации множителей.
поиск любого общего делителя это частный случай факторизации, разве нет?
впрочем, что тут обсуждать алгоритм, высосанный из фантазии шарлатана) (судя по всему его высказывания не признак больного ума, а признак «заведомо ложной информации»)
впрочем, что тут обсуждать алгоритм, высосанный из фантазии шарлатана) (судя по всему его высказывания не признак больного ума, а признак «заведомо ложной информации»)
Необязательно, например поиск наибольшего общего делителя двух чисел выполняется за квадратичное время от их длины (алгоритм Евклида).
вы правы, что сокращая 2 произвольных числа нет нужды оба полностью факторизировать, когда можно просто последовательно находить их Наибольшии общие делители) в том варианте который я рассматривал, где дробь ищется через обратное значение и переводится в целое умножением на 10 в степени N, факторизировать два числа нужды нет. И алгоритм евклида это частный способ факторизации)
правда ничего там не нужно факторизировать, чего -то я перемудрил (решая в общем случае, самое простое частное решение не поискал)… проверку делимости на 2 и на 5 можно сделать по последнему знаку)))
правда, как тут и тут уже отметили, возможно найти более компактное представление
правда ничего там не нужно факторизировать, чего -то я перемудрил (решая в общем случае, самое простое частное решение не поискал)… проверку делимости на 2 и на 5 можно сделать по последнему знаку)))
правда, как тут и тут уже отметили, возможно найти более компактное представление
Вышел новый фильм: 1231241241256463/12423534647257568923 — все смотрим!!!
Даже идея есть, неплохо :) а я думал будет типа история, взял сырцы рар и допилил…
Элементарно же. Число пи содержит все возможные последовательности. Надо только смещение найти.
Антивирус Бабушкина