Автор: Shelwien,
01 сентября 2003 года в 02:58:16
В ответ на : Re: полный pm от Олег Набатов
в 31 августа 2003 года в 23:46:59:
> ppm все равно предполагает одномерный >файл, а к примеру обнаружить что это >двумерная таблица и превратиться в >двумерный ppm не может. Кто тебе сказал? ;) Посмотри paq1,paq1sse, шкаринский bcdr. Уверяю тебя, даже текст - это вовсе не линейный объект и никто с ним, как с таковым, давно не работает. > Тогда как файлы >или уж точно наборы файлов это >вероятнее >всего строчные развертки каких-то >многомерных объектов. Фильтры может >что-то и находят, но они представляют >собой статичное распределение. Понятное дело, что фильтры - это простая аппроксимация. >Это >закончится огромным архиватором со >всеми >возможными фильтрами, дающим >минимальный >архив с dll-ками, так не лучше ли >сделать этот архиватор типа >самораспаковывающимся при запуске? 1. Лично я надеюсь, что "это закончится" архиватором с базой форматов и алгоритмом сборки модели для файла по описанию его структуры из моделей для конкретных типов данных. 2. Архивы многих современных компрессоров можно считать "самораспаковывающимися" в том смысле, что они читают оттуда какие-то данные для настройки модели. >Или я не понимаю о чем речь. Вроде того. Сначала либо разберись, как работает какой-нибудь ppmonstr, slim, или epm, либо сам сделай лучше. >В сегодняшнем траффике объемы >архиваторов >не заметны и в то же время >тиражи такие >что стоит по-паковать получше. По-моему, мы говорили об SFX'ах. Сжатый в колмогоровский x86-код файл - это SFX. > > Оказывается, таким образом, что > > халявы нет и тут. Чтобы создать > > "язык сжатия", имеет смысл сначала > > научиться вручную сжимать данные, > > сгенерированные известным методом. > > Проанализировав результаты, мы > > получим множество "операторов", в > > терминах которых можно описать > > созданные модели. Вот после этого > > действительно появится возможность > > достичь максимального сжатия > > за счет "колмогоровского" подхода. > Ага, как-то так. Ну чем мои 8 бит > не инструкция :) Тем, что сжимать текст лучше ppmonstr'а такие "инструкции" тебе не помогут. > > ...Не хочу тебя расстраивать, но > > в современных PPM-компрессорах, в > > какой-то мере, это уже сделано ;) > Да ничего там не сделано. Вот >если бы архиватор трудился неделю >над файлом в сто байт, я бы поверил. А ты посмотри на мои кодеры в bfa1.rar - они являются солидным шагом в этом направлении ;) Или вот еще beeopt, epmopt - хорошие штуки. На опции дурилки, опять же, посмотри ;) На самом деле, создать такой архиватор - не проблема. Просто масса более важных вещей до сих пор непонятна, для исследования которых приемлемы и большие скорости ;) > > А теперь можешь устроить опрос. > > Интересно, сколько людей согласятся > > использовать архиватор, способный > > по собственному желанию выдавать > > столь разнообразные результаты? ;) > Как ни странно я описал то что на >самом деле и происходит, но >вручную. В архиватор эту не особо >интеллектуальную >работу не загнали только потому >что нет такого архиватора. 1. А ты изучил интерфейсы всех этих StuffIt'ов и *Zip, да? ;) 2. Лично мне от архиватора такой "интеллект" не нужен. Да и не об архиваторе, собственно, тут речь. Вот в интернетовских протоколах встроенное сжатие - да, не помешало бы. Особенно, если с секьюрной системой обновления кодеков и т.п. Если тебе это интересно - займись разработкой и внедрением ;) А собственно архиватор - это программа для выполнения вполне конкретной работы.
|