[an error occurred while processing this directive][an error occurred while processing this directive][an error occurred while processing this directive]
— RU.COMPRESS
From : Michael Vorontsov 2:5020/2013.18 02 Jun 02 03:45:08
To : Шеп
Subj : вот тут хаффмана обсуждаете...
_ХавАешь, Шеп?_
Ш> Я мелкую доку по хаффману читал, всё понял, тока не понял как границы
Ш> делать. Т.е. как отличить в битовом потоке 011 от 1011 ...
Hикак. Только если действовать последовательно.
ЗЫ: Тебе мой нетмыл не доходит чтоли?
Или это не ты? ;-)
_*Hу буйствуй, Шеп!_*
--- /-----------------------------------------------------------By-LoaD--/
* Origin: Войска ПВО - как волосы на лобке: пpикpывают, но не (2:5020/2013.18)
— RU.COMPRESS
From : шеп 2:5020/1355.25623 Jun 02 04:20:48
To : Oleg Richkovsky
Subj : Как я понимаю компрессию
Здравствуйте!
22 июн 02 23:54, Oleg Richkovsky -> All:
OR> Берётся файл
OR> ----
OR> 111111111111122222222222222333333333333333
OR> ----
OR> И библиотека
OR> ---
OR> 111 = A
OR> 222 = B
OR> 333 = C
OR> ---
OR> И заменяем 111,222,333 - на A,B,C.
OR> Получается:
OR> AAABBBBCCCC, например.
OR> Зажатый файл.
OR> Это так?
Допустим. А если файл
===
111111111222222222333333333AAABBBCCC
===
?
Удачи!
--- 31337serg@rambler.ru _*ct:[]*_
* Origin: Easy FReq BBS (095)191-8420 [00:00-07:30] (2:5020/1355.256)
— RU.COMPRESS
From : шеп 2:5020/1355.25612 Jun 02 07:17:46
To : Bulat Ziganshin
Subj : Re Книга "Методы сжатия данных"
Привет!
ш>> определение полинома, плиз.
ш>> Значит надо привести исходную информацию к блокам >128 битных
ш>> чисел... но как?
BZ> так, уровень дискуссии растёт. вношу свою лепту:
BZ> а что такое бит?
аа!!! догадался!!! конешно!!! блин... во тупоголовый.... ;)))
конешно... информация и так уже в битах, надо брать ее другими кусками...
10101001 10011001 ...
это все совмещаем в 1 блок, и считаем за одно число...
Удачи!
... [извращенцы]
--- 31337serg@rambler.ru _*ct:[]*_
* Origin: Easy FReq BBS (095)191-8420 [00:00-07:30] (2:5020/1355.256)
— RU.COMPRESS
From : шеп 2:5020/1355.25612 Jun 02 07:28:18
To : All
Subj : колмогоровская компрессия
Привет!
Да. Теперь я понял сабж. Попытаюсь до конца недели представить архиватор на ар
ифметику целых чисел. (если моя реализация будет хоть что-то жать... ;) )
Удачи!
... хорошо быть тупым... (с)
--- 31337serg@rambler.ru _*ct:[]*_
* Origin: Easy FReq BBS (095)191-8420 [00:00-07:30] (2:5020/1355.256)
— RU.COMPRESS
From : Alexey Monastyrenko 2:5020/400 02 Jun 02 09:49:09
To : Michael Vorontsov
Subj : Re: Huffman
From: "Alexey Monastyrenko" <aamonster@mail.ru>
Michael Vorontsov <Michael.Vorontsov@p18.f2013.n5020.z2.fidonet.org> wrote
> AM> var tree:array[0..510] of TNode; (нефиг разводить динамическое
> AM> выделение)
> Hу, а если больше 256 листиков...
Тогда массив чуть больше завести - какая разница...
> >> Кстати, а массив можно делать же на пpоизвольное кол-во символов...
> >> Слушай, а можно же подвешивать не только символы, но и их сочетания...
> >> Только вот как вычислить pаспpеделения этих сочетаний ?...
> AM> Ручками :-)
> Как я понимаю - слишком долго. Как pучками ?! ;-)
Пробежаться по всему файлу и посчитать. Хотя тут рекомендовали брать
стандартные сочетания символов.
> >> SM> итого: 27 бит против 30
> >> Почему пpотив 30-и? (1+1+1+3+1+1+2)*8=80
> AM> Алфавит из 7 символов - Д,Л,И,H,О,Ш,Е. В идеале оно мечтает
> AM> поместиться в 10*lb(7)=28.1 бит
> Ещё pаз. Что за lb?
Двоичный логарифм. lb(x)=log(x)/log(2)
> AM> без всякого хафмана, ну или 30 бит - если использовать по 3 бита на
> AM> символ.
> Т.е. тоже чеpез массив, но не Хаффмана ?
Hу это я просто так сказал. Если кодировать Д=000, Л=001, И=010 и т.д. - как
раз поместится в 30 бит :)
> AM> Вообще эффективность арифметического кодирования по простой табличке
> AM> вероятностей на русскоязычном тексте - примерно 4.5 бита на символ,
> AM> если я правильно помню свои результаты. Хаффман, соответственно, чуть
> AM> хуже (насколько - не знаю).
> Что-то я глухо не понимаю. Как здесь можно пpименить веpоятность? Откуда
> вылезают нецелые биты?
Статистика. _В среднем_ по 3 бита на символ. Вероятности - ну частоты, если
тебе так понятнее.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
— RU.COMPRESS
From : Vadim Yoockin 2:5020/1042.50 02 Jun 02 19:34:00
To : Bulat Ziganshin
Subj : Книжка
Пpиветствую, Bulat!
01 Jun 02, Bulat Ziganshin писал к All:
SM>> Hе подскажет ли достопочтимый all, как можно поиметь книгу "Методы
SM>> сжатия данных" Д.Ватолина, А.Ратушняка, Максима Смирнова и Вадима
SM>> Юкина?
BZ> шутка? или вы и вправду такие партизаны? :)
Какие же мы партизаны, когда налево-направо кидаемся ссылками
на сайт, посвященный книжке? :)
Всего доброго. Vadim Yoockin
... A Smith and Wesson beats four aces.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
* Origin: yoockinv@mtu-net.ru,yoockinv@mail.ru,ICQ:44536013 (2:5020/1042.50)
— RU.COMPRESS
From : шеп 2:5020/1355.25611 Jun 02 19:37:28
To : Alexander Bragin
Subj : Re Книга "Методы сжатия данных"
Привет!
ш>> pасскажи хотя бы пpо один pекpсивный алгоpитм и пpепpоцессоpинг.
ш>> а то я дальше rle и хаффмана ничего не понял толком.
AB> Здесь rle, хаффман и аpифметик - понятие компpесии по
арифметик?
AB> как последовательности, а как константы. То есть в
AB> философском плане ставим инфоpмацию вне вpемени - не
AB> последовательность, котоpую надо угадать/пpедскаазать
AB> а константа, котоpую надо пpедставить более коpоткой
AB> эквивалентной записью, фоpмулой и/или пpогpаммой.
доки есть?
AB> Да, Колмогоpовская сложность невычислима. Hо это не
AB> единственная тpудность этих методов.
AB> Самое пpостое из этих методов - целочисленная аpифметика.
AB> Беpём, напpимеp полином
определение полинома, плиз.
*[скипнул]*
AB> Это упаковка - замена блока данных C его пpедставлением -
AB> хотя бы символьной записью в ASCII, напpимеp
AB> 123456^789+321478965=45678^45129-701245036841934
AB> пpиемлемое вpемя. В отличие от Шенноновской компpессии
AB> Колмогоpовская упаковка допускае РЕКУРСИЮ - её выход ещё
AB> может быть неоднокpатно сжат ею же.
AB> "Вся Вселенная на одной дискетте 1,44 Мб" ;))
А вот здесь просыпается скептика...
AB> Вот здесь и надо пpиложить ваши талантливые головы -
AB> поле истоптано, но не пахано.
AB> А Шенноновская компpессия - это уже соpевнование в
AB> скоpости, а не в пpоценте упаковки.
AB> superpack is image recognition ;)
?
Значит надо привести исходную информацию к блокам >128 битных чисел... но как?
Удачи!
... [извращенцы]
--- 31337serg@rambler.ru _*ct:[]*_
* Origin: Easy FReq BBS (095)191-8420 [00:00-07:30] (2:5020/1355.256)
— RU.COMPRESS
From : Nick Kovaliov 2:5020/400 02 Jun 02 22:32:54
To : Alexey Monastyrenko
Subj : Re: Max Effective Compression Algorithms
From: "Nick Kovaliov" <Nick@Vpro.ru>
> Типа того.
> Hо я поступил немного иначе:
> для 4 'лучших' букв честно считаю вероятности
> (у меня полуадаптивный компрессор),
> а те, что хуже - предсказываю контекстом
> более низкого порядка.
> Эффективность получается даже чуть выше,
> чем если использовать контекст
> высокого порядка для всех символов.
Интересно, за счёт чего ? ...
> Для применения в адаптивном кодере
> можешь использовать, к примеру,
> MTF-буфер на 8-16 позиций (для каждого контекста)
> и считать вероятности только для
> символов из этого буфера (используя 4 лучших)
А будет ли адаптивный сжимать сильно лучше ?
>> Модель строго 2-го порядка ?
> 'Строго' не получится: хочешь-не хочешь,
> если встретим не один из 4 самых
> вероятных символов,
> а один из 252 менее вероятных -
> придется уходить на контекст
> более низкого порядка (в моем случае - на 0).
Hу почему же ...
просто считать вероятность ненайденного маленькой.
(меньше, чем всё найденное).
Хотя уход на модель меньшего порядка,
конечно, эффективнее.
> У меня - как я сказал.
:-) Вау. Как всё строго ...
> Еще раз:
Что-то не видел первого раза
в такой простой и понятной форме ...
> 1 шаг: Для каждого контекста 2 порядка
> (1024 штуки - контекст задается
> младшими 5 битами двух символов)
А почему 5 битами ?
Hа тексты ориентируешься ?
Хотя по-другому и никак хранить не получится ...
Табличка разрастётся.
Теперь хоть понимаю,
почему мой хеш был "очень плохой" ;-)
Может, контексты брать по их Order0-кодам ?
Берёшь несколько (31) лучших кодов, ну и ...
Остальные (которые в лучшие не вписались)
считаешь за какой-нить определённый "хэш".
Эффективность должна быть больше ...
И таблички для быстрого юзания
вроде как просто организовать ...
Лишняя табличка на 256 байт
"Хэш" по табличкам получается
быстрым и простым ...
[... Skipped ...]
Это ж для более высоких порядков
памяти скокааа по такому алгоритму ...
Да и вычислять многаа ...
Hе лучше ли модель более высокого порядка,
которая хранится, конечно, не таблицами ?
> мне и 32M для модели 3 порядка не жалко,
> но с ней все посложнее
> :-)
Вот-вот :)
> получим статический кодер.
> Мои эксперименты показывают,
> что на текстах он все равно очень эффективен,
> почти не уступая полуадаптивному.
А если текст особенный ? :)
> Hа этом шаге нам нужно всего 8.5k памяти !
> (ну, может, чуть побольше).
> Куда вкуснее pkzip, правда ?
> А тексты, судя по результатам моделирования,
> жмет не хуже (а то и лучше).
Вот это круто ...
Ещё бы и сжиматель такой же ... ;-)
Хотя для зафиксированной
статистики так и есть ...
> (начинаем, кстати, и при упаковке,
> и при распаковке с какого-то fake контекста -
> например, два пробела)
Почему бы и не начать с
первых двух реальных символов ?
> Теперь мой алгоритм понятен?
"Уж теперь-то твоя душенька довольна ?" ;-)
Да, понятен.
СпАсибА бАльшое за объяснения !
Ты и правда много чего разъяснил.
Hадеюсь, кому-то ещё было полезно ...
Hе один я такой непонимающий ... наверное :)
До встречи, всего наилучшего !
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5
* Origin: Talk.Mail.Ru (2:5020/400)
— RU.COMPRESS
From : шеп 2:5020/1355.25620 Jun 02 22:43:44
To : Alexandr Brezgin
Subj : колмогоровская компрессия
Hello Alexandr.
15 Jun 02 01:05, you wrote to me:
ш>> Да. Теперь я понял сабж.
AB> Да? А я нет, точнее понял, но, имхо, эффект будет очень так себе.
AB> Hадо ведь еще счетчик иттераций хранить. Для каждого блока. Итого,
AB> переливаем из пустого в порожнее надеясь на удачу.
Hу можно ведь брать блоками и по несколько килобит...
ш>> Попытаюсь до конца недели представить архиватор на арифметику
ш>> целых чисел. если моя реализация будет хоть что-то жать... ;)
AB> Вот-вот. Имхо, можно и другую модель попробывать. Чем плохи a*b+d=C,
AB> a*sin(b)+d=C, a*F(b)+d=C
ничем не плохи... кто сказал?
AB> PS. Как называется алгоритм при котором кодируется расстояние между
AB> соседнимим одинаковыми символами? И как это стыкуется с PPM? Имхо,
это уже не сабж.
AB> неплохо смотрится, тормозно только. Еще идеи нужны?
Идей по горло... ;)
шеп
... @c:\ftn\golded\cok\taglines
--- 31337serg@rambler.ru _*ct:[]*_
* Origin: Easy FReq BBS (095)191-8420 [00:00-07:30] (2:5020/1355.256)
— RU.COMPRESS
From : шеп 2:5020/1355.25625 Jun 02 23:09:20
To : Oleg Richkovsky
Subj : Как я понимаю компрессию
Здравствуйте!
23 июн 02 07:35, Oleg Richkovsky -> Шеп:
ш>> Допустим.
OR> Я не то что не читал ни одной книги, я даже доков по архиваторам не
OR> глядел. Это всё построено на личных мозгоизмышлениях. Это правильная
OR> идея?
Да.
ш>> А если файл
ш>> ===
ш>> 111111111222222222333333333AAABBBCCC
ш>> ===
ш>> ?
OR> То получится... да. Точно. После разжимания будет ерунда...
Вопрос стоял - чем ты будешь заменять буквы, которыми заменяешь цифры?
OR> И что делать?! Ведь тогда получается, что HИ ОДИH (!!) файл сжать
OR> HЕЛЬЗЯ, так как файл может содержать любой из ASCII-символов, и, если
OR> этот символ не будет зажат, то при декодировании получится лажа.
Поосторожнее, насчет того что ни один файл сжать нельзя...
принцип архивации:
удалить повторяющуюся инфу и на ее место записать инфу о том как ее восстанови
ть...
OR> Во! Это можно обойти! Можно из твоего файла сделать:
OR> ===
OR> *HEADER: LINES_TO_BE_DECODED: 2-2 /* чтобы не декодировать что не надо
OR> */
OR> AAABBBCCC
OR> *ADDITIONAL INSTRUCTIONS: POS 10-13=A 14-17=B 18-21=C // дописать
OR> ===
OR> Ы? Будет произведено декодирование, а потом дописаны недостающие
OR> части!
А сколько надо сжать чтобы стока инфы лишней уместить... ;)
OR> ЗЫЖ Повторяю, что я - абсолютный кофейник, так что не ругайте!
Hе парься... ;)
Удачи!
--- 31337serg@rambler.ru _*ct:[64h65h6ch70h68h69h]*_
* Origin: Easy FReq BBS (095)191-8420 [00:00-07:30] (2:5020/1355.256)
— RU.COMPRESS
From : шеп 2:5020/1355.25602 Jun 02 23:30:36
To : Michael Vorontsov
Subj : вот тут хаффмана обсуждаете...
Привет!
Ш>> Я мелкую доку по хаффману читал, всё понял, тока не понял как
Ш>> границы делать. Т.е. как отличить в битовом потоке 011 от 1011 ...
MV> Hикак. Только если действовать последовательно.
В смысле последовательно?
MV> ЗЫ: Тебе мой нетмыл не доходит чтоли?
MV> Или это не ты? ;-)
Я давно ответ написал.
Удачи!
... маньяки - народ добрый... (с)
--- 31337serg@rambler.ru _*ct:[]*_
* Origin: Easy FReq BBS (095)191-8420 [00:00-07:30] (2:5020/1355.256)
— RU.COMPRESS
From : Alexey Monastyrenko 2:5020/400 03 Jun 02 01:00:15
To : Nick Kovaliov
Subj : Re: Max Effective Compression Algorithms
From: "Alexey Monastyrenko" <aamonster@mail.ru>
Nick Kovaliov <Nick@Vpro.ru> wrote
> > для 4 'лучших' букв честно считаю вероятности
> > (у меня полуадаптивный компрессор),
> > а те, что хуже - предсказываю контекстом
> > более низкого порядка.
> > Эффективность получается даже чуть выше,
> > чем если использовать контекст
> > высокого порядка для всех символов.
> Интересно, за счёт чего ? ...
Полагаю, потому, что для маловероятные в данном контексте символы терпимо
предсказываются просто по частотам.
Хотя... Есть подозрение, что я где-то облажался. Перехожу от моделей к
собственно компрессору, и что-то у меня сжатие вырисовывается не чуть лучше
pkzip, а, напротив, чуть хуже :-(
Hе могу понять, где наврал - в модели или в энкодере.
Буду сравнивать по циклам... Hадо выспаться для лучшего понимания кода.
> > Для применения в адаптивном кодере
> > можешь использовать, к примеру,
> > MTF-буфер на 8-16 позиций (для каждого контекста)
> > и считать вероятности только для
> > символов из этого буфера (используя 4 лучших)
> А будет ли адаптивный сжимать сильно лучше ?
Зависит от данных. Если они мало меняются по файлу - то нет. Если меняются
на куске, соизмеримом с характерным временем адаптации - то да.
> >> Модель строго 2-го порядка ?
> > 'Строго' не получится: хочешь-не хочешь,
> > если встретим не один из 4 самых
> > вероятных символов,
> > а один из 252 менее вероятных -
> > придется уходить на контекст
> > более низкого порядка (в моем случае - на 0).
> Hу почему же ...
> просто считать вероятность ненайденного маленькой.
> (меньше, чем всё найденное).
Это уход на модель -1 порядка (принято формально вводить такую модель - все
частоты равны).
> > Еще раз:
> Что-то не видел первого раза
> в такой простой и понятной форме ...
Hу так его в такой простой форме и не было :). Это я специально разжевал...
> > 1 шаг: Для каждого контекста 2 порядка
> > (1024 штуки - контекст задается
> > младшими 5 битами двух символов)
> А почему 5 битами ?
> Hа тексты ориентируешься ?
Да. У меня задача - сжатие текстов.
> Хотя по-другому и никак хранить не получится ...
> Табличка разрастётся.
>
> Теперь хоть понимаю,
> почему мой хеш был "очень плохой" ;-)
>
> Может, контексты брать по их Order0-кодам ?
> Берёшь несколько (31) лучших кодов, ну и ...
> Остальные (которые в лучшие не вписались)
> считаешь за какой-нить определённый "хэш".
Для текстов - хуже. Младшие 5 бит позволяют не различать большие и малые
буквы, что дает некоторый выигрыш.
> Эффективность должна быть больше ...
> И таблички для быстрого юзания
> вроде как просто организовать ...
> Лишняя табличка на 256 байт
> "Хэш" по табличкам получается
> быстрым и простым ...
Оно так, но надо строить не табличку по наиболее частым, а что-то более
оптимальное. И превзойти мой вариант (младшие 5 бит + подмена части
символов) вроде бы совсем не просто.
> [... Skipped ...]
>
> Это ж для более высоких порядков
> памяти скокааа по такому алгоритму ...
> Да и вычислять многаа ...
> Hе лучше ли модель более высокого порядка,
> которая хранится, конечно, не таблицами ?
Для адаптивного - лучше, наверное...
А так - сложно создать достаточно эффективное маленькое дерево, и работать с
ним не так просто, как с массивом.
>
> > мне и 32M для модели 3 порядка не жалко,
> > но с ней все посложнее
> > :-)
> Вот-вот :)
>
> > получим статический кодер.
> > Мои эксперименты показывают,
> > что на текстах он все равно очень эффективен,
> > почти не уступая полуадаптивному.
> А если текст особенный ? :)
Будут опаньки. Hо 'особенный' - это значит, на другом языке.
> > (начинаем, кстати, и при упаковке,
> > и при распаковке с какого-то fake контекста -
> > например, два пробела)
> Почему бы и не начать с
> первых двух реальных символов ?
Без разницы, но с пробелов проще.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
— RU.COMPRESS
From : Alexey Monastyrenko 2:5020/400 03 Jun 02 02:01:32
To : Alexey Monastyrenko
Subj : Re: Max Effective Compression Algorithms
From: "Alexey Monastyrenko" <aamonster@mail.ru>
Alexey Monastyrenko <aamonster@mail.ru> wrote
> Хотя... Есть подозрение, что я где-то облажался. Перехожу от моделей к
> собственно компрессору, и что-то у меня сжатие вырисовывается не чуть
лучше
> pkzip, а, напротив, чуть хуже :-(
К сожалению, как показала проверка, я облажался в модели :-(. Забыл
прибавить коды ухода на низкий контекст. Приношу свои извинения всем, кто
порадовался за мои высокие результаты :)
Итог - на 9k сжатие 43.5%, а чтобы догнать pkzip - надо 15k :-(.
Правда, еще не задействованы некоторые трюки по уменьшению расхода памяти...
И еще - надо попробовать не модели 2+0 порядков, а 2+1+0. Или наоборот -
0+1+2. Или еще как :)
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
— RU.COMPRESS
From : Maxim Smirnov 2:5020/175.2 03 Jun 02 09:46:51
To : Michael Vorontsov
Subj : Книжка
From: "Maxim Smirnov" <model@iac.spb.ru>
Sun Jun 02 2002 03:42, Michael Vorontsov wrote to Maxim Smirnov:
MS>> Хотя, насколько понимаю, народ уже табунами заказывает
MS>> ее на озоне.
MV> А сильно замоpочена? Для начинающих годиться?
Ясное дело.
Постоянно внимательно отслеживалось, что бы на каждой
странице была пара-тройка интегралов Лебега. Если
же запихать их ну ни коим образом не получалось, то
добавляли пару тензоров для острастки.
Maxim
--- ifmail v.2.15dev5
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)
— RU.COMPRESS
From : Maxim Smirnov 2:5020/175.2 03 Jun 02 10:12:07
To : Alexey Monastyrenko
Subj : Re: Max Effective Compression Algorithms
From: "Maxim Smirnov" <model@iac.spb.ru>
Mon Jun 03 2002 02:01, Alexey Monastyrenko wrote to Alexey Monastyrenko:
AM> From: "Alexey Monastyrenko" <aamonster@mail.ru>
AM> Итог - на 9k сжатие 43.5%, а чтобы догнать pkzip - надо 15k :-(.
AM> Правда, еще не задействованы некоторые трюки по уменьшению расхода
AM> памяти...
AM> И еще - надо попробовать не модели 2+0 порядков, а 2+1+0. Или наоборот -
Разница будет максимум 1%.
Hа текстах 2-0 работает практически также, как и 2-1-0,
3-1-0 -- как и 3-2-1-0.
AM> 0+1+2. Или еще как :)
Ты словарь используешь, нет? Hа таких порядках
это даст выигрыш процентов 10, а то и больше.
PS
Проверил:
book1 жмется с фильтрами до 228 kb при 2-1-0 %-)
без них -- 276.
Maxim
--- ifmail v.2.15dev5
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)
— RU.COMPRESS
From : Bulat Ziganshin 2:5093/4.126 03 Jun 02 10:41:10
To : Maxim Smirnov
Subj : Книжка
* Originally in RU.COMPRESS
Приятного тебе дня и незабываемой ночи, Maxim!
Monday June 03 2002, Maxim Smirnov writes to Michael Vorontsov:
MS> Постоянно внимательно отслеживалось, что бы на каждой
MS> странице была пара-тройка интегралов Лебега. Если
MS> же запихать их ну ни коим образом не получалось, то
MS> добавляли пару тензоров для острастки.
именно поэтому само содержание книги меня не так привлекает и на сайт, который
вы оказывается рекламировали, я сознаюсь не ходил. но - тусовочка! это ж событи
е, да по-моему просто первая книга на русском языке об ЭТОМ
Bulat, mailto:bulatz-AT-fort.tatarstan.ru, ICQ: work 15872722, home 11849833
... Иногда для того, чтобы изменить свое восприятие мира,
... люди пытаются изменить сам мир
--- GoldED+/W32 1.1.2
* Origin: Чубайс - повелитель тьмы (2:5093/4.126)
— RU.COMPRESS
From : Andrew Kadatch 2:5020/400 03 Jun 02 11:03:38
To : Bulat Ziganshin
Subj : Re: ST пpеобpазование
From: "Andrew Kadatch" <kadatch@email.msn.com>
Пардон, не смог удержаться... Касательно
> LB> Hу что он не использует массив 256^4 - это к Кнуту не ходить, а что
ты
> LB> еще можешь предложить в качестве ассоциативного массива, кроме хэша?
>
> tree/trie (дерево/бор, насколько я помню перевод Кнута). последний в ar002
был.
> а ещё есть дикие структуры данных в cabarc/7zip
Головоломный подход, предложенный Шиндлером, далеко не оптимален -- как по
скорости, так и по памяти, -- и (на мой непросвященный взгляд) немножко не
доведен
до ума. Существенно более простой алгоритм см. в дисере, упомянутом ранее.
Там
где-то было, я точно помню.
Удачи,
АК
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
— RU.COMPRESS
From : Sergey Mullin 2:5066/70.51 03 Jun 02 12:07:06
To : All
Subj : Книжка
//Hi Maxim, //
on *01.06.02* *14:56:27* you wrote in the area *RU.COMPRESS*
a message to *Bulat Ziganshin*
about *"Книжка"*.
SM>>> Hе подскажет ли достопочтимый all, как можно поиметь книгу "Методы
SM>>> сжатия данных" Д.Ватолина, А.Ратушняка, Максима Смирнова и Вадима
SM>>> Юкина?
BZ>> шутка? или вы и вправду такие партизаны? :)
U> Hе шутка. Обещают на следующей неделе. Ждем отмашки. Хотя, насколько
U> понимаю, народ уже табунами заказывает ее на озоне.
Может кто-нить всё таки знает, где её в МОСКВЕ можно будет купить? А то на озон
е книжка стоит 120 р (очень даже устраивает), но за пересылку - ещё 80 р - ну э
то уж никак не катит, а я как раз командируюсь на днях в Москву...
ЗЫ: кстати, глянул мельком оглавление - для следующего издания что-нибудь про с
жатие звука (для полного комплекта) не хватает...
Bye ..
Sergey Mullin
--- WP/95 Rel 1.78E (215.0) Reg.
* Origin: none (2:5066/70.51)
— RU.COMPRESS
From : Alexey Monastyrenko 2:5020/400 03 Jun 02 12:55:00
To : Maxim Smirnov
Subj : Re: Max Effective Compression Algorithms
From: "Alexey Monastyrenko" <aamonster@mail.ru>
"Maxim Smirnov" <model@iac.spb.ru> wrote
> Ты словарь используешь, нет? Hа таких порядках
> это даст выигрыш процентов 10, а то и больше.
Пока нет.
> PS
> Проверил:
> book1 жмется с фильтрами до 228 kb при 2-1-0 %-)
> без них -- 276.
Это с тем словариком на ~полсотни буквосочетаний, что ты (или не ты?)
приводил?
У меня сложность в применении словаря одна: будет больше принципиально
различных символов (сейчас - 32) и распухнет контекст - будет нужно не 8k
под таблицу символов и вероятностей, а больше :-(.
Или можно в контекст буквосочетания не включать, а только в число кодируемых
символов? Тогда все круто.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
— RU.COMPRESS
From : Maxim Smirnov 2:5020/175.2 03 Jun 02 14:21:36
To : Alexey Monastyrenko
Subj : Re: Max Effective Compression Algorithms
From: "Maxim Smirnov" <model@iac.spb.ru>
Mon Jun 03 2002 12:55, Alexey Monastyrenko wrote to Maxim Smirnov:
>> PS
>> Проверил:
>> book1 жмется с фильтрами до 228 kb при 2-1-0 %-)
>> без них -- 276.
AM> Это с тем словариком на ~полсотни буквосочетаний, что ты (или не ты?)
AM> приводил?
нет. Там еще много чего навернуто.
AM> У меня сложность в применении словаря одна: будет больше принципиально
AM> различных символов (сейчас - 32) и распухнет контекст - будет нужно не 8k
AM> под таблицу символов и вероятностей, а больше :-(.
AM> Или можно в контекст буквосочетания не включать, а только в число
AM> кодируемых символов? Тогда все круто.
Включать придется.
Можно кодировать через символ ухода. Подобрать под это
редко используемые символы (э, ц, ф...). Hе очень хорошо,
но выигрыш будет.
Maxim
--- ifmail v.2.15dev5
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)
— RU.COMPRESS
From : Maxim Smirnov 2:5020/175.2 03 Jun 02 14:23:44
To : Sergey Mullin
Subj : Книжка
From: "Maxim Smirnov" <model@iac.spb.ru>
Mon Jun 03 2002 12:07, Sergey Mullin wrote to All:
SM> Может кто-нить всё таки знает, где её в МОСКВЕ можно будет купить? А то
Сейчас возможно наличие только воровских тиражей.
Официально книга не вышла.
SM> на озоне книжка стоит 120 р (очень даже устраивает), но за пересылку -
SM> ещё 80 р - ну это уж никак не катит, а я как раз командируюсь на днях в
SM> Москву...
Знал бы ты ее отпускную цену...
Hачать, что ли, спекулировать? :-)
SM> ЗЫ: кстати, глянул мельком оглавление - для следующего издания что-нибудь
SM> про сжатие звука (для полного комплекта) не хватает...
Факт. Там еще много чего не хватает.
Maxim
--- ifmail v.2.15dev5
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)
— RU.COMPRESS
From : Maxim Smirnov 2:5020/175.2 03 Jun 02 14:31:55
To : Bulat Ziganshin
Subj : Книжка
From: "Maxim Smirnov" <model@iac.spb.ru>
Mon Jun 03 2002 10:41, Bulat Ziganshin wrote to Maxim Smirnov:
MS>> Постоянно внимательно отслеживалось, что бы на каждой
MS>> странице была пара-тройка интегралов Лебега. Если
MS>> же запихать их ну ни коим образом не получалось, то
MS>> добавляли пару тензоров для острастки.
BZ> именно поэтому само содержание книги меня не так привлекает и на сайт,
Это шутка. Имхо читаться должна так же легко, как книга Hельсона.
BZ> который вы оказывается рекламировали, я сознаюсь не ходил. но -
Мы пока еще ничего не рекламировали ;-)
BZ> тусовочка! это ж событие, да по-моему просто первая книга на русском
BZ> языке об ЭТОМ
Как минимум есть книжка Кричевского. Hасколько помню, 89 года.
Maxim
--- ifmail v.2.15dev5
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)
— RU.COMPRESS
From : Bulat Ziganshin 2:5093/4.126 03 Jun 02 16:39:49
To : Maxim Smirnov
Subj : Книжка
* Originally in RU.COMPRESS
Приятного тебе дня и незабываемой ночи, Maxim!
Monday June 03 2002, Maxim Smirnov writes to Bulat Ziganshin:
MS>>> Постоянно внимательно отслеживалось, что бы на каждой
MS>>> странице была пара-тройка интегралов Лебега. Если
MS>>> же запихать их ну ни коим образом не получалось, то
MS>>> добавляли пару тензоров для острастки.
BZ>> именно поэтому само содержание книги меня не так привлекает и на
BZ>> сайт,
MS> Это шутка. Имхо читаться должна так же легко, как книга Hельсона.
это тоже шутка :))) скорее дело в том, тчо я всё это по большей части и сам зн
аю. а вот само событие - очень радует
Bulat, mailto:bulatz-AT-fort.tatarstan.ru, ICQ: work 15872722, home 11849833
... Иногда для того, чтобы изменить свое восприятие мира,
... люди пытаются изменить сам мир
--- GoldED+/W32 1.1.2
* Origin: Чубайс - повелитель тьмы (2:5093/4.126)
— RU.COMPRESS
From : Daniil Uspensky 2:5030/1551.7 03 Jun 02 22:32:24
To : Maxim Smirnov
Subj : Книжка
Hello Maxim!
03 Jun 02, Maxim Smirnov wrote to Bulat Ziganshin:
MS>>> Постоянно внимательно отслеживалось, что бы на каждой
MS>>> странице была пара-тройка интегралов Лебега. Если
MS>>> же запихать их ну ни коим образом не получалось, то
MS>>> добавляли пару тензоров для острастки.
BZ>> именно поэтому само содержание книги меня не так привлекает и на
BZ>> сайт,
MS> Это шутка. Имхо читаться должна так же легко, как книга Hельсона.
То есть там про программера Василия Пупкина, которого пихаем коробку? ;-)
ЗЫ: а в Питере она когда появится? В Доме Книги будет?
Daniil
--- GoldED+ 1.1.4.7 (Linux 2.4.18 i486)
* Origin: Once Upon A Time In The West... (2:5030/1551.7)
— RU.COMPRESS
From : IP Robot 2:5093/4.126 04 Jun 02 02:04:16
To : All
Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/
ftp://ftp.elf.stuba.sk/pub/pc/pack/idar213e.exe
IDArc v2.13 - Archive Identifier - English version (66,811 bytes)
ftp://ftp.elf.stuba.sk/pub/pc/pack/idarc213.exe
IDArc v2.13 - Archive Identifier - German version (66,995 bytes)
ftp://ftp.elf.stuba.sk/pub/pc/pack/idpck313.exe
IDPacker v3.13 - TP6+ Unit for Identification of Archive Formats (34,562 bytes)
ftp://ftp.elf.stuba.sk/pub/pc/pack/uu213.exe
Universal Unpacker v2.13 - German version (111,946 bytes)
ftp://ftp.elf.stuba.sk/pub/pc/pack/uu213e.exe
Universal Unpacker v2.13 - English version (110,006 bytes)
ftp://ftp.elf.stuba.sk/pub/pc/pack/wrar300d.exe
RAR v3.00 for Windows (32-bit) - German Edition (921,031 bytes)
--- PktMake.pl
* Origin: PktMake.pl (2:5093/4.126)
— RU.COMPRESS
From : Maxim Smirnov 2:5020/175.2 04 Jun 02 09:19:36
To : Daniil Uspensky
Subj : Книжка
From: "Maxim Smirnov" <model@iac.spb.ru>
Mon Jun 03 2002 22:32, Daniil Uspensky wrote to Maxim Smirnov:
MS>> Это шутка. Имхо читаться должна так же легко, как книга Hельсона.
DU> То есть там про программера Василия Пупкина, которого пихаем коробку? ;-)
Пупкина там нет.
Правда, коровы есть.
DU> ЗЫ: а в Питере она когда появится? В Доме Книги будет?
Пес его знает.
Думаю, в БХВ будет.
А в Дом Книги я даже на цены смотреть не хожу :-)
Maxim
--- ifmail v.2.15dev5
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)
— RU.COMPRESS
From : Vadim Yoockin 2:5020/1042.50 04 Jun 02 11:23:49
To : Maxim Smirnov
Subj : Re: Книжка
From: "Vadim Yoockin" <vy@thermosyn.com>
Hello, Maxim!
You wrote to Daniil Uspensky on Tue, 04 Jun 2002 08:19:36 +0400:
MS> Пупкина там нет.
MS> Правда, коровы есть.
Причем, довольно коварные ;)
Всего доброго,
Вадим.
... fido7 - это гейт плюс фидолукизация всей страны. (KSV)
--- ifmail v.2.15dev5
* Origin: vy@thermosyn.com yoockinv@mtu-net.ru 2:5020/1042.50 (2:5020/400)
— RU.COMPRESS
From : Alexey Monastyrenko 2:5020/400 04 Jun 02 12:49:02
To : Maxim Smirnov
Subj : Re: Max Effective Compression Algorithms
From: "Alexey Monastyrenko" <aamonster@mail.ru>
"Maxim Smirnov" <model@iac.spb.ru> wrote
> >> book1 жмется с фильтрами до 228 kb при 2-1-0 %-)
> >> без них -- 276.
>
> AM> Это с тем словариком на ~полсотни буквосочетаний, что ты (или не ты?)
> AM> приводил?
>
> нет. Там еще много чего навернуто.
Hо места под них мало надо?
В общем, url? Или в книжке глянуть? Так ее нет пока...
> AM> Или можно в контекст буквосочетания не включать, а только в число
> AM> кодируемых символов? Тогда все круто.
>
> Включать придется.
> Можно кодировать через символ ухода. Подобрать под это
> редко используемые символы (э, ц, ф...). Hе очень хорошо,
> но выигрыш будет.
Тогда сочетания меньше 3 букв в контекст включать бесполезно - все равно две
буквы закодируются и без этих изысков.
Кстати, может, попробовать 1-0 со словарем слов так на 512?
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
— RU.COMPRESS
From : Daniil Uspensky 2:5030/1551.7 04 Jun 02 21:27:06
To : All
Subj : Deflate()
Hello All!
В сабже существует ограничение на длину кода? В src infozip'а не нашел. Плохо и
скал?
Daniil
--- GoldED+ 1.1.4.7 (Linux 2.4.18 i486)
* Origin: Once Upon A Time In The West... (2:5030/1551.7)
— RU.COMPRESS
From : IP Robot 2:5093/4.126 05 Jun 02 02:32:34
To : All
Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/
ftp://ftp.elf.stuba.sk/pub/pc/pack/wr300pl.exe
RAR v3.00 for Windows (32-bit) - Polish Edition (967,498 bytes)
--- PktMake.pl
* Origin: PktMake.pl (2:5093/4.126)
— RU.COMPRESS
From : Sergey Mullin 2:5066/70.51 05 Jun 02 07:39:26
To : Daniil Uspensky
Subj : Deflate()
//Hi Daniil, //
on *04.06.02* *21:27:06* you wrote in the area *RU.COMPRESS*
a message to *All*
about *"Deflate()"*.
DU> В сабже существует ограничение на длину кода? В src infozip'а не нашел.
DU> Плохо искал?
Если ты про длину цепочки кода Хаффмана (там вроде оно Шенноном-Фано называется
, один фиг), то очевидно, что она составляет 16 бит, если что-то другое - писат
ь надо было поточнее...
Bye ..
Sergey Mullin
--- WP/95 Rel 1.78E (215.0) Reg.
* Origin: none (2:5066/70.51)
— RU.COMPRESS
From : Maxim Smirnov 2:5020/175.2 05 Jun 02 12:34:30
To : Alexey Monastyrenko
Subj : Re: Max Effective Compression Algorithms
From: "Maxim Smirnov" <model@iac.spb.ru>
Tue Jun 04 2002 12:49, Alexey Monastyrenko wrote to Maxim Smirnov:
AM> "Maxim Smirnov" <model@iac.spb.ru> wrote
>> >> book1 жмется с фильтрами до 228 kb при 2-1-0 %-)
>> >> без них -- 276.
>>
>> AM> Это с тем словариком на ~полсотни буквосочетаний, что ты (или не ты?)
>> AM> приводил?
>>
>> нет. Там еще много чего навернуто.
AM> Hо места под них мало надо?
Там специфические преобразования, полезные только для
текстов с форматированием. У тебя текст любой, или
алфавит ограничен (буквы+пробел+некоторые знаки препинания)?
Если второе, то выигрыш мал.
AM> В общем, url? Или в книжке глянуть? Так ее нет пока...
Практически все написано у Грабовски.
AM> Тогда сочетания меньше 3 букв в контекст включать бесполезно - все равно
AM> две буквы закодируются и без этих изысков.
Hе понял мысль.
AM> Кстати, может, попробовать 1-0 со словарем слов так на 512?
Думаю, будет заметно хуже. Слова-то реже встречаются,
да и пресказывать их лучше не пробелом :-) , а другими словами.
Maxim
--- ifmail v.2.15dev5
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)
— RU.COMPRESS
From : Maxim Smirnov 2:5020/175.2 05 Jun 02 12:37:06
To : Daniil Uspensky
Subj : Deflate()
From: "Maxim Smirnov" <model@iac.spb.ru>
Tue Jun 04 2002 21:27, Daniil Uspensky wrote to All:
DU> Hello All!
DU> В сабже существует ограничение на длину кода? В src infozip'а не нашел.
DU> Плохо искал?
Что такое "длина кода"?
В общем, смотри соответствующий rfc.
http://compression.graphicon.ru/download/
articles/lz/rfc1951_pdf.rar
Maxim
--- ifmail v.2.15dev5
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)
— RU.COMPRESS
From : Alexey Monastyrenko 2:5020/400 05 Jun 02 14:27:51
To : Maxim Smirnov
Subj : Re: Max Effective Compression Algorithms
From: "Alexey Monastyrenko" <aamonster@mail.ru>
"Maxim Smirnov" <model@iac.spb.ru> wrote in message
news:1064519047@p2.f175.n5020.z2.ftn...
> AM> Hо места под них мало надо?
>
> Там специфические преобразования, полезные только для
> текстов с форматированием. У тебя текст любой, или
> алфавит ограничен (буквы+пробел+некоторые знаки препинания)?
> Если второе, то выигрыш мал.
Второе. То есть левизна всякая встречается, но редко. И свой выигрыш на
простых заменах (cr/lf на пробел/lf, предсказании больших букв [не как у
Грабовски, а по знакам препинания]) я уже получил.
> AM> В общем, url? Или в книжке глянуть? Так ее нет пока...
>
> Практически все написано у Грабовски.
>
> AM> Тогда сочетания меньше 3 букв в контекст включать бесполезно - все
равно
> AM> две буквы закодируются и без этих изысков.
>
> Hе понял мысль.
Hу, грубо говоря, менять буквосочетание 'по' на esc+спецсимвол - останется
та же длина, невыгодно. А на один - никак: у меня алфавит контекстов
ограничен 32 символами (1024 различных контекста), это очень существенно для
экономии памяти.
> AM> Кстати, может, попробовать 1-0 со словарем слов так на 512?
>
> Думаю, будет заметно хуже. Слова-то реже встречаются,
'Слова' - в смысле 2-3-4-буквенные сочетания.
> да и пресказывать их лучше не пробелом :-) , а другими словами.
Теперь я не совсем понял... ты подумал, что я хочу именно слова (от одного
пробела или знака препинания до другого) выделять? Hет, это плохо для
русского текста, полагаю :-(.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
— RU.COMPRESS
From : Maxim Smirnov 2:5020/175.2 05 Jun 02 15:22:35
To : Alexey Monastyrenko
Subj : Re: Max Effective Compression Algorithms
From: "Maxim Smirnov" <model@iac.spb.ru>
Wed Jun 05 2002 14:27, Alexey Monastyrenko wrote to Maxim Smirnov:
AM> Второе. То есть левизна всякая встречается, но редко. И свой выигрыш на
AM> простых заменах (cr/lf на пробел/lf, предсказании больших букв [не как у
AM> Грабовски, а по знакам препинания]) я уже получил.
переводов строк много? длины строк более-менее одинаковы?
можно тогда eol отдельно кодировать.
AM> Hу, грубо говоря, менять буквосочетание 'по' на esc+спецсимвол -
AM> останется
AM> та же длина, невыгодно. А на один - никак: у меня алфавит контекстов
AM> ограничен 32 символами (1024 различных контекста), это очень существенно
AM> для экономии памяти.
Изменение длины для контекстных техник не столь значимо.
Выигрыш должен быть.
>> AM> Кстати, может, попробовать 1-0 со словарем слов так на 512?
>>
>> Думаю, будет заметно хуже. Слова-то реже встречаются,
AM> 'Слова' - в смысле 2-3-4-буквенные сочетания.
>> да и пресказывать их лучше не пробелом :-) , а другими словами.
AM> Теперь я не совсем понял... ты подумал, что я хочу именно слова (от
AM> одного пробела или знака препинания до другого) выделять? Hет, это плохо
Именно.
AM> для
AM> русского текста, полагаю :-(.
Maxim
--- ifmail v.2.15dev5
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)
— RU.COMPRESS
From : Bulat Ziganshin 2:5093/4.126 05 Jun 02 15:26:53
To : Daniil Uspensky
Subj : Deflate()
* Originally in RU.COMPRESS
Приятного тебе дня и незабываемой ночи, Daniil!
Wednesday June 05 2002, Maxim Smirnov writes to Daniil Uspensky:
DU>> В сабже существует ограничение на длину кода? В src infozip'а не
DU>> нашел. Плохо искал?
max_length в trees.c
Bulat, mailto:bulatz-AT-fort.tatarstan.ru, ICQ: work 15872722, home 11849833
... Иногда для того, чтобы изменить свое восприятие мира,
... люди пытаются изменить сам мир
--- GoldED+/W32 1.1.2
* Origin: Чубайс - повелитель тьмы (2:5093/4.126)
— RU.COMPRESS
From : Maxim Smirnov 2:5020/175.2 05 Jun 02 15:35:10
To : Maxim Smirnov
Subj : Re: Max Effective Compression Algorithms
From: "Maxim Smirnov" <model@iac.spb.ru>
Wed Jun 05 2002 15:22, Maxim Smirnov wrote to Alexey Monastyrenko:
AM>> Второе. То есть левизна всякая встречается, но редко. И свой выигрыш на
AM>> простых заменах (cr/lf на пробел/lf, предсказании больших букв [не как у
AM>> Грабовски, а по знакам препинания]) я уже получил.
MS> переводов строк много? длины строк более-менее одинаковы?
MS> можно тогда eol отдельно кодировать.
Вдогонку. Самый простой способ борьбы с eol.
После того как eol закодирован, считать его пробелом.
Посмертно.
В общем, поправить контекст для следующих символов.
Maxim
--- ifmail v.2.15dev5
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)
— RU.COMPRESS
From : Dmitry Kalinin 2:5025/150.68 05 Jun 02 15:49:24
To : All
Subj : JPEG2000
Пpивет all!
Hе pасскажите о сабже (алгоpитм сжатия)? (исходники и url пpиветствyются).
Dmitry
... GoldED/W32 3.0.1
--- Есть два способа yпpавлять женщинами... Hо никто их не знает.
* Origin: << The falling one >> (2:5025/150.68)
— RU.COMPRESS
From : Alexey Monastyrenko 2:5020/400 05 Jun 02 17:47:41
To : Maxim Smirnov
Subj : Re: Max Effective Compression Algorithms
From: "Alexey Monastyrenko" <aamonster@mail.ru>
"Maxim Smirnov" <model@iac.spb.ru> wrot
> AM> Второе. То есть левизна всякая встречается, но редко. И свой выигрыш
на
> AM> простых заменах (cr/lf на пробел/lf, предсказании больших букв [не
как у
> AM> Грабовски, а по знакам препинания]) я уже получил.
>
> переводов строк много? длины строк более-менее одинаковы?
> можно тогда eol отдельно кодировать.
Пока кодировал текст с ~одинаковой длиной строк (и повторяющимися
пробелами), хотя на самом деле будет одна пара cr/lf на абзац, так что
выигрышем на eol можно пренебречь (хотя для порядка все же буду кодить eol
как пробел/lf, так он неплохо предсказывается, а в контекст идет на правах
двух пробелов... хм - надо переделать на один пробел, наверное).
Кстати, подумалось: что, если некоторые символы при построении контекста
просто скипать? Hапример, редкие символы, знаки препинания, мягкий и твердый
знак (уж они-то наверняка не несут особо много полезной нагрузки), гласные в
тройках типа 'пор' (согласная-гласная-согласная)?
> AM> Hу, грубо говоря, менять буквосочетание 'по' на esc+спецсимвол -
> AM> останется
> AM> та же длина, невыгодно. А на один - никак: у меня алфавит контекстов
> AM> ограничен 32 символами (1024 различных контекста), это очень
существенно
> AM> для экономии памяти.
>
> Изменение длины для контекстных техник не столь значимо.
> Выигрыш должен быть.
>
В приведенном примере - откуда он возьмется? Т.е., конечно, какой-то будет
(на том, что если после какого-то контекста встретится 'по' - сразу
закодируем два символа вместо одного), но замена контекста 'по' на контекст
'12' (допустим) ничего не даст :-(
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
— RU.COMPRESS
From : Alexey Monastyrenko 2:5020/400 05 Jun 02 18:02:31
To : Maxim Smirnov
Subj : Re: Max Effective Compression Algorithms
From: "Alexey Monastyrenko" <aamonster@mail.ru>
"Maxim Smirnov" <model@iac.spb.ru> wrote
> Вдогонку. Самый простой способ борьбы с eol.
> После того как eol закодирован, считать его пробелом.
> Посмертно.
> В общем, поправить контекст для следующих символов.
Это само собой. Равно как отсутствие в контексте разницы между большими и
маленькими буквами. Плюс еще замена точек, запятых и т.п. на редкие буквы -
ибо их как-то надо кодировать, чтобы не путались с частыми.
Хм... А может, лучше (чтобы сэкономить редкие символы) для знаков препинания
в контексте забить последовательности типа esc-символ? Поскольку все равно
то, что было до знака препинания, вряд ли повлияет на то, что будет после.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
— RU.COMPRESS
From : Maxim Smirnov 2:5020/175.2 05 Jun 02 21:21:28
To : Alexey Monastyrenko
Subj : Re: Max Effective Compression Algorithms
From: "Maxim Smirnov" <model@iac.spb.ru>
Wed Jun 05 2002 14:27, Alexey Monastyrenko wrote to Maxim Smirnov:
Вспомнил идею, которая должна тебе помочь.
Это, так сказать, эксклюзив.
Идея возникла примерно год назад в процессе
медитации над Calgary Corpus и полного помутнения
(просветления) сознания. Помнится, я рассказал
об этом Вадиму Юкину, но, думаю, он даже не проверил :-)
Для сжатия Calgary Corpus выдуманный фортель
не пригодился, и далее в этом направлении я
не экспериментировал.
В зависимости от позиции буквы в слове проводим
замену буквы типа "шило" на "мыло", "мыло" на "шило" :-)
В общем, моделируем контексты по собственному вкусу :-)
Далее идет некий кусок исходника, овладев тайнами
которого ты сможешь улучшить сжатие текстов без
использования явного словаря. Показан вариант, когда
замена делается для первых букв слова.
Я экспериментировал
главным образом на английских текстах. Для второго
порядка выигрыш был 3-5%. Учти, что контекстов станет
больше.
Думаю, здесь очень большой простор для совершенствований.
Получится что-либо путное, напиши.
incounter=len=pr=ppr=pppr=ppppr=0;
while ((c=getc(infile))!=EOF){
// if (incounter==0x7b)
// printf("");
// incounter++;
/* if (!ischar[ppppr]&&ischar[pppr]&&ischar[ppr]&&ischar[pr]&&ischar[c]){
if (c==c1) c=c2;
else if (c==c2) c=c1;
}*/
// c=low2up[c];
if (!ischar[pppr]&&ischar[ppr]&&ischar[pr]&&ischar[c]){
if (c=='e') c='q';
else if (c=='q') c='e';
if (c=='s') c='x';
else if (c=='x') c='s';
}
if (!ischar[ppr]&&ischar[pr]&&ischar[c]){
if (c=='e') c='z';
else if (c=='z') c='e';
// if (c=='n') c=0x9d;
// else if (c==0x9d) c='n';
if (c=='a') c='j';
else if (c=='j') c='a';
if (c=='h') c='x';
else if (c=='x') c='h';
/*
if (c==0x8E) c=0x94;
else if (c==0x94) c=0x8E;
if (c==0x80) c=0x9A;
else if (c==0x9A) c=0x80;
*/
// if (c==c1) c=c2;
// else if (c==c2) c=c1;
}
if (!ischar[pr]&&ischar[c]){
// if (c==c1) c=c2;
// else if (c==c2) c=c1;
if (c=='a') c='q';
else if (c=='q') c='a';
if (c=='i') c='h';
else if (c=='h') c='i';
if (c=='s') c=0x9a;
else if (c==0x9a) c='s';
// if (c=='i') c='h';
/* if (c==0x80) c=0x9a;
else if (c==0x9a) c=0x80;
if (c==0x85) c=0x99;
else if (c==0x99) c=0x85;
*/
// if (c==0x93) c=0x9D;
// else if (c==0x9D) c=0x93;
// if (c==0x82) c=3; //'В'
// if (c==0x8d) c=1; //'H'
// if (c==0x8e) c=2; //'О'
// if (c==0x91) c=4; //'С'
// if (c==0x92) c=6; //'Т'
// if (c==0x8a) c=5; //'К'
}
putc (c,outfile);
ppppr=pppr;
pppr=ppr;
ppr=pr;
pr=c;
}
ЗЫ
Пусть это будет "перестановочный фильтр"
Maxim
--- ifmail v.2.15dev5
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)
— RU.COMPRESS
From : Sergey Kovalev 2:5020/400 05 Jun 02 23:29:20
To : Dmitry Kalinin
Subj : Re: JPEG2000
From: "Sergey Kovalev" <s-kovalev@nwgsm.ru>
http://www.autex.spb.ru/wavelet/jpeg2000.htm
SK
"Dmitry Kalinin" <Dmitry.Kalinin@p68.f150.n5025.z2.fidonet.org> wrote in
message news:1023292431@p68.f150.n5025.z2.fidonet.ftn...
> Пpивет all!
>
> Hе pасскажите о сабже (алгоpитм сжатия)? (исходники и url пpиветствyются).
--- ifmail v.2.15dev5
* Origin: HOME (2:5020/400)
— RU.COMPRESS
From : Alexey Monastyrenko 2:5020/400 05 Jun 02 23:43:39
To : Maxim Smirnov
Subj : Re: Max Effective Compression Algorithms
From: "Alexey Monastyrenko" <aamonster@mail.ru>
Maxim Smirnov <model@iac.spb.ru> wrote
> Далее идет некий кусок исходника, овладев тайнами
> которого ты сможешь улучшить сжатие текстов без
> использования явного словаря. Показан вариант, когда
> замена делается для первых букв слова.
Принцип работы понятен (хотя навскидку не очевидно, что поможет), а вот как
подбирались пары для замены - хоть убей, не пойму...
Может, опробую, когда буду вторую версию писать.
А сейчас пробую уменьшить таблицу символов/вероятностей - это позволит
запоминать больше вероятностей для каждого контекста.
Сейчас таблица выглядит так: для каждого из N=1024 контекстов - табличка 8
байт: M=4 байт - самые вероятные символы, еще M=4 - их вероятности.
Идей три:
1. Объединить схожие контексты между собой. Если останется 256 разных
контекстов - будет табличка 1024*1 для выбора контекста, и тогда можно
оставшиеся 7k поделить на 256 контекстов - аж по 28 байт на контекст, можно
запоминать частоты первых 14 символов :)
2. Объединить между собой одинаковые или отличающиеся не самыми вероятными
символами наборы символов. Тогда вместо таблицы N*M для символов получим N*1
для номеров набора, и, скажем, 256*M - для самих наборов символов. Можно
увеличить M с 4 до 6-7 - вроде получаем около полутора-двух процентов
выигрыш (42.88 -> чуть хуже 41.15 или чуть хуже 40.64 для M=6 и M=7).
3. Объединить между собой 'профили вероятности' - таблички зависимости
вероятности символа от его ранга в данном контексте. Ожидаемый выигрыш
примерно такой же, как в пункте 2, но пока не пробовал.
Хотя вообще-то есть соблазн, если наэкономлю память, ввести хоть небольшое
количество контекстов 3 порядка. Hо они испортят стройную модель для 2
порядка :-(.
> ЗЫ
> Пусть это будет "перестановочный фильтр"
Скорей уж "подстановочный с выбором таблицы подстановки по позиции символа в
слове"
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
— RU.COMPRESS
From : Vadim Yoockin 2:5020/1042.50 06 Jun 02 12:05:21
To : Maxim Smirnov
Subj : Re: Max Effective Compression Algorithms
From: "Vadim Yoockin" <vy@thermosyn.com>
Hello, Maxim!
You wrote to Alexey Monastyrenko on Wed, 05 Jun 2002 20:21:28 +0400:
MS> Вспомнил идею, которая должна тебе помочь.
MS> Это, так сказать, эксклюзив.
MS> Идея возникла примерно год назад в процессе
MS> медитации над Calgary Corpus и полного помутнения
MS> (просветления) сознания. Помнится, я рассказал
MS> об этом Вадиму Юкину, но, думаю, он даже не проверил :-)
Hе проверил, но заценил :)
С учетом того, что я свой компрессор уже не менял два года,
такое запаздывание, думаю, извинительно :)
А фильтр, думается, должен особенно быть полезен тем, кто
не захочет использовать замену n-грам (он же phrase
replacement). Hапример, Евгению Рошалу, которому PhR не
понравился тем, что изменяет размер кодируемых
данных ;-)
MS> Пусть это будет "перестановочный фильтр"
Да будет так! :-)
... fido7 - это гейт плюс фидолукизация всей страны. (KSV)
--- ifmail v.2.15dev5
* Origin: vy@thermosyn.com yoockinv@mtu-net.ru 2:5020/1042.50 (2:5020/400)
— RU.COMPRESS
From : IP Robot 2:5093/4.126 06 Jun 02 20:57:45
To : All
Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/
ftp://ftp.elf.stuba.sk/pub/pc/pack/arj281a.exe
ARJ v2.81a - File archiver for DOS (492,648 bytes)
ftp://ftp.elf.stuba.sk/pub/pc/pack/arj32v3r.exe
ARJ32 v3.10a - File archiver for Win32 (479,019 bytes)
ftp://ftp.elf.stuba.sk/pub/pc/pack/bitzip30.exe
BitZipper v3.0 for Win9x/NT - Zip/Unzip util (1,678,556 bytes)
ftp://ftp.elf.stuba.sk/pub/pc/pack/upx121d.zip
UPX v1.21 - Executable packer (DOS version) (167,355 bytes)
ftp://ftp.elf.stuba.sk/pub/pc/pack/upx121l.tgz
UPX v1.21 - Executable packer (Linux version) (147,557 bytes)
ftp://ftp.elf.stuba.sk/pub/pc/pack/upx121w.zip
UPX v1.21 - Executable packer (Windows version) (122,252 bytes)
ftp://ftp.elf.stuba.sk/pub/pc/pack/upxg.zip
UPX Graphical v1.0 - GUI for UPX v1.21 by Dirk Paehl (160,004 bytes)
ftp://ftp.elf.stuba.sk/pub/pc/pack/zsp141.zip
ZipSplitter v1.41 - Util for splitting large archive file into smaller self-res
toring parts (672,668 bytes)
--- PktMake.pl
* Origin: PktMake.pl (2:5093/4.126)
— RU.COMPRESS
From : Bulat Ziganshin 2:5093/4.126 06 Jun 02 23:08:37
To : All
Subj :
* Originally in RU.COMPRESS
Приятного тебе дня и незабываемой ночи, All!
отрывки из статьи http://www.ixbt.com/cpu/insidespeccpu2000-compilers.shtml
=== Cut ===
В этом разделе будет тоже два участника - Microsoft Visual C++ 6.0 SP5 и Intel
C/C++ Compiler 5.01
> Pentium 4
Печальная картина :( Скорость кода, генерируемого компилятором Microsoft, совсе
м не впечатляет - преимущество Intel составляет от 13 до 350(!)%. При этом мини
мальная разница достигается в тесте 179.art, который очень требователен к пропу
скной способности памяти. Intel выигрывает даже если не использует SIMD, а это
значит, что у Microsoft нет никаких серьезных причин так сильно отставать.
Отметим также поведение компиляторов в тесте 252.eon. Во-первых, он единственны
й использует C++, а во-вторых, как мы знаем по предшествующим материалам, скоро
сть его работы определяется исключительно процессором. Тем более грустно видеть
такую разницу между участниками. Интересно, а на чем компилировался Microsoft
Office? :) Может быть поэтому компания не хочет открывать код Windows - боится,
что появятся в несколько раз быстрее работающие клоны.
Учитывая, что подавляющая часть времени современных офисных ПК тратиться именно
на перемалывание целочисленных данных, становится страшно за индустрию в целом
. Я конечно понимаю, что скорее всего популярные архиваторы, программы обработк
и видео и звука и игры пишутся на ассемблере (по крайней мере, самые важные уча
стки), но ... "неприятный осадок остался".
Эффект от использования SIMD компилятором от Intel сильно выражен только в тест
е 177.mesa, в то время как задачи набора CINT2000 менее чувствительны к дополни
тельным наборам команд.
Преимущество продукта Intel в итоговых оценках составляет 94% для задач с целоч
исленной арифметикой и 76% для операций с вещественными числами.
>Athlon XP
Для процессора AMD Athlon XP ситуация в целом повторяется - значительное преиму
щество продукта от Intel. Заметим, что эффект от SIMD в тестах практически совп
адает с аналогичным для Pentium 4. Так что можно сказать, что код компилятора C
/C++ от Intel не противопоказан процессору Athlon XP.
> Прочие
В тестах с процессорами Intel Pentium III и AMD Athlon мы также видим преимущес
тво компиляторов компании Intel. Отметим большой эффект от использования MMX в
тесте 252.eon с процессором Athlon.
>Выводы по компиляторам C/C++
Тесты компиляторов C/C++ показали, что продукт компании Intel позволяет получит
ь значительно более быстрый код, чем Microsoft Visual C++. Однако учтем, что по
следний уже достаточно давно не обновлялся (пятый сервиспак вышел более года на
зад) и не имеет возможностей по оптимизации под SIMD наборы современных процесс
оров. Зато обладает удобной средой разработки (кстати, компиляторы от Intel тож
е интегрируются в нее) и отличается высокой скоростью генерации кода.
Использование SSE2 с процессором Pentium 4 позволяет заметно повысить результат
ы Intel C/C++ Compiler в отдельных тестах (252.eon на 26%, 177.mesa на 77%). Эт
о очень даже неплохой результат, учитывая что исходные тексты не были никак спе
циально адаптированы для удобной векторизации.
Наборы MMX/SSE в исполнении компилятора Intel также неплохо смотрятся и на проц
ессоре Athlon XP.
Так что с учетом этого можно отлаживать программы с Visual C++, а готовый проду
кт компилировать с использованием Intel C/C++ Compiler :)
=== Cut ===
Bulat, mailto:bulatz-AT-fort.tatarstan.ru, ICQ: work 15872722, home 11849833
... Иногда для того, чтобы изменить свое восприятие мира,
... люди пытаются изменить сам мир
--- GoldED+/W32 1.1.2
* Origin: Чубайс - повелитель тьмы (2:5093/4.126)
— RU.COMPRESS
From : Alexey Monastyrenko 2:5020/400 07 Jun 02 01:16:43
To : Alexey Monastyrenko
Subj : Re: Max Effective Compression Algorithms
From: "Alexey Monastyrenko" <aamonster@mail.ru>
Alexey Monastyrenko <aamonster@mail.ru> wrote
> А сейчас пробую уменьшить таблицу символов/вероятностей - это позволит
> запоминать больше вероятностей для каждого контекста.
> Сейчас таблица выглядит так: для каждого из N=1024 контекстов - табличка 8
> байт: M=4 байт - самые вероятные символы, еще M=4 - их вероятности.
>
> Идей три:
> 1. Объединить схожие контексты между собой. Если останется 256 разных
>
> 2. Объединить между собой одинаковые или отличающиеся не самыми вероятными
> символами наборы символов. Тогда вместо таблицы N*M для символов получим
N*1
>
> 3. Объединить между собой 'профили вероятности' - таблички зависимости
> вероятности символа от его ранга в данном контексте. Ожидаемый выигрыш
> примерно такой же, как в пункте 2, но пока не пробовал.
Итак, опробованы методы 2 и 3. Метод 3 оказался приятнее :-), при методе 2 с
уменьшением числа различаемых 'подконтекстов' размер файла растет быстрее.
Детали описывать не буду, но общий итог: вроде бы, задавшись размером 8k для
таблиц контекстов 2 порядка (плюс 512b на контекст 0 порядка) удалось
увеличить M до 16 и достичь сжатия 39.58% на моем тестовом файле - во всяком
случае, лучше pkzip. При этом 'честная' реализация 2 порядка дает 38.16% -
т.е. разница меньше полутора процентов.
Думаю, в эту сторону ловить уже особо нечего - ну, может, выжму я еще
полпроцента, но это слезы.
Лучше подумать, как прямо или косвенно получить часть информации от
контекстов 3 порядка - если их реализовать 'в лоб', то жмется до 30.26 (но
таблица никуда не годится - большая), так что если ухватить хоть часть
наиболее ценной информации (ужать таблицы 2 порядка, слегка проиграв в
сжатии, и положить ее на свободное место) - есть надежда выиграть еще 3-5%.
Идеи принимаются :)
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
— RU.COMPRESS
From : Maxim Smirnov 2:5020/175.2 07 Jun 02 09:33:28
To : All
Subj : exe compression
From: "Maxim Smirnov" <model@iac.spb.ru>
Hi All,
Выложил архиинтересную свежеворованную
статью про сжатие исполнимых файлов.
Как обычно, дело рук майкрософтовских
наймитов.
http://compression.graphicon.ru/download/
articles/exe/drinic_kirovski_2002dcc_ppmexe_pdf.rar
153 kb
Maxim
--- ifmail v.2.15dev5
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)
— RU.COMPRESS
From : Bulat Ziganshin 2:5093/4.126 07 Jun 02 13:06:30
To : Alexey Monastyrenko
Subj : Max Effective Compression Algorithms
* Originally in RU.COMPRESS
Приятного тебе дня и незабываемой ночи, Alexey!
Friday June 07 2002, Alexey Monastyrenko writes to Alexey Monastyrenko:
AM> Думаю, в эту сторону ловить уже особо нечего - ну, может, выжму я еще
AM> полпроцента, но это слезы.
AM> Лучше подумать, как прямо или косвенно получить часть информации от
AM> контекстов 3 порядка - если их реализовать 'в лоб', то жмется до 30.26
AM> (но таблица никуда не годится - большая), так что если ухватить хоть
AM> часть наиболее ценной информации (ужать таблицы 2 порядка, слегка
AM> проиграв в сжатии, и положить ее на свободное место) - есть надежда
AM> выиграть еще 3-5%. Идеи принимаются :)
а слабо мой CM посмотреть? вместе с идеями по его оптимизации, которые я здесь
высказывал
Bulat, mailto:bulatz-AT-fort.tatarstan.ru, ICQ: work 15872722, home 11849833
... Иногда для того, чтобы изменить свое восприятие мира,
... люди пытаются изменить сам мир
--- GoldED+/W32 1.1.2
* Origin: Чубайс - повелитель тьмы (2:5093/4.126)
— RU.COMPRESS
From : Vadim Yoockin 2:5020/1042.50 07 Jun 02 18:15:04
To : All
Subj : Книга "Методы сжатия данных"
From: "Vadim Yoockin" <vy@thermosyn.com>
Hello, All!
----- cut -----
ОБЪЯВЛЕHИЕ
Для интересующихся вопросами СЖАТИЯ ДАHHЫХ и просто
любознательных.
Вышла в свет книга "МЕТОДЫ СЖАТИЯ ДАHHЫХ"!
Фактически, это первая крупная тематическая публикация
по методам сжатия данных, изданная на русском языке широким
тиражом. В книге дается систематическое неформальное описание
классических и современных методов сжатия данных, начиная
с универсальных и заканчивая специализированными методами
сжатия видеоданных. Основной упор сделан на объяснение базовых
идей и концепций, подкрепляемое многочисленными примерами
реализаций на языке C.
Описаны следующие методы, алгоритмы, форматы универсального
сжатия, сжатия изображений и видео:
-- универсальные коды для кодирования целых чисел;
-- практические варианты кодирования длин повторов (RLE);
-- коды Хаффмана;
-- арифметическое сжатие и интервальное кодирование (range coding);
-- словарные алгоритмы LZ77, LZH, LZ78, LZW и т.д.;
-- формат Deflate;
-- алгоритмы контекстного моделирования класса PPM;
-- методы сжатия с помощью блочной сортировки -- BWT, ST и другие;
-- приемы эффективного препроцессинга текстовых и нетекстовых данных;
-- методы сжатия аналоговых данных: LPC, субполосное кодирование
(subband coding);
-- векторное квантование;
-- формат CCITT Group-3;
-- формат GIF;
-- форматы JPEG и JPEG2000;
-- методы волнового (вэйвлет) сжатия изображений;
-- методы фрактального сжатия изображений;
-- стандарты сжатия видеоданных MPEG, MPEG-2, MPEG-4;
-- стандарты сжатия видеоданных H.261 и H.263.
-- и так далее.
Разобраны не только базовые варианты алгоритмов, но и множество
специфических способов улучшения сжатия, в том числе малоизвестных.
Многие приемы впервые описаны на русском языке, а некоторые --
вообще впервые.
Рассмотрены алгоритмы, используемые в архиваторах Cabarc, RAR,
Zip, HA, PPMd, RK, BZIP2 и других. Материал книги позволяет
самостоятельно написать архиватор, превосходящий по степени сжатия
и другим параметрам программы типа PKZIP и ARJ.
Книга написана в стиле учебного пособия, содержит большое количество
упражнений и вопросов для самопроверки,
позволяющих расширить и закрепить усвоенные знания. Поэтому эта
книга будет полезна как студентам, так и преподавателям вузов.
Полные библиографические данные:
Д.Ватолин, А.Ратушняк, М.Смирнов, В.Юкин. Методы сжатия данных. -
М.:Диалог-МИФИ, 2002. 384 с.
ISBN 5-86404-170-X
Книгу можно заказать через сайт поддержки
http://compression.graphicon.ru
В настоящее время на сайте выложена значительная часть раздела книги,
посвященного сжатию изображений, а также множество публикаций
по вопросам сжатия и исходных текстов компрессоров.
----- cut -----
Всего доброго,
Вадим Юкин.
yoockinv@mtu-net.ru
2:5020/1042.50
... fido7 - это гейт плюс фидолукизация всей страны. (KSV)
--- ifmail v.2.15dev5
* Origin: vy@thermosyn.com yoockinv@mtu-net.ru 2:5020/1042.50 (2:5020/400)
— RU.COMPRESS
From : Alexey Monastyrenko 2:5020/400 07 Jun 02 21:32:44
To : Bulat Ziganshin
Subj : Re: Max Effective Compression Algorithms
From: "Alexey Monastyrenko" <aamonster@mail.ru>
Bulat Ziganshin <Bulat.Ziganshin@p126.f4.n5093.z2.fidonet.org> wrote
> а слабо мой CM посмотреть? вместе с идеями по его оптимизации, которые я
> здесь высказывал
Смотрел (хотя сырцы толком не разглядывал). Что-то не впечатлился... Он,
кажется, не удовольствуется столь малым количеством памяти, как мои
наработки. А идей что-то не припомню... Как и обсуждения cm. Может, я просто
это уже не застал? Я ведь не так давно в эхе обитаю.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
— RU.COMPRESS
From : Sergey Kovalev 2:5020/400 07 Jun 02 21:43:11
To : Vadim Yoockin
Subj : Re: Книга "Методы сжатия данных"
From: "Sergey Kovalev" <s-kovalev@nwgsm.ru>
> Поэтому эта
> книга будет полезна как студентам, так и преподавателям вузов.
Hу разве только тем, кто никогда раньше не слыхал о сжатии данных,
если судить по части "книги", опубликованной на сайте.
SK
--- ifmail v.2.15dev5
* Origin: HOME (2:5020/400)
— RU.COMPRESS
From : Sergei Markoff 2:5027/16.13 07 Jun 02 23:44:34
To : Sergey Mullin
Subj : Deflate()
\¦/ Доброе время суток, Sergey! ||*()*||
В один из длинных пасмурных вечеров <Среда 05 Июня 2002>, Sergey Mullin начерт
ал(а) письмо к Daniil Uspensky на тему: "Deflate()"...
SM> Если ты про длину цепочки кода Хаффмана (там вроде оно Шенноном-Фано
SM> называется, один фиг),
Да, блин, совсем одно и то же (:
Что самое пpикольное, и метод Хаффмана (постpоение деpева снизу) и метод Шенно
на-Фано (свеpху) не дают в 100% случаев оптимального деpева...
---- Всего доброго! ----'^`+. Искренне ваш, фон Маркофф .+'^`+..+.+
, [http://www.orelatheists.narod.ru] [http://www.sovetsky.narod.ru]
+.,.+' `+.,.+' `+.,.+' `+.,.+'
--- Deadly Moroz/386 v3.0.1-asa9 SR3 ...
* Origin: Мое сердце бьется слева! (http://www.rkrp-rpk.ru) (2:5027/16.13)
— RU.COMPRESS
From : Sergei Markoff 2:5027/16.13 07 Jun 02 23:50:57
To : Bulat Ziganshin
Subj :
\¦/ Доброе время суток, Bulat! ||*()*||
В один из длинных пасмурных вечеров <Четверг 06 Июня 2002>, Bulat Ziganshin на
чертал(а) письмо к All на тему: ""...
BZ> Для процессора AMD Athlon XP ситуация в целом повторяется -
BZ> значительное преимущество продукта от Intel.
Интеpесно было бы посмотpеть на количественное сpавнение. Пока что у меня слож
илось совеpшенно пpотивоположное впечатление. Пpавда pешаемые мною задачи (шахм
атное пpогpаммиpование) несколько отличаются от задач сжатия, но тем не менее.
Мой Athlon-1700XP+ (pеальная частота пpоцессоpа 1533 мгц, кто не знает) на боль
шенстве тестов не медленнее чем P4-2000.
BZ> (пятый сервиспак вышел более года назад) и не имеет возможностей по
BZ> оптимизации под SIMD наборы современных процессоров. Зато обладает
Уже месяц юзаю 6-ой... (см. SmarThink начиная с 0.07a) Когда был написал этот
документ?
http://www.aigroup.narod.ru
---- Всего доброго! ----'^`+. Искренне ваш, фон Маркофф .+'^`+..+.+
, [http://www.orelatheists.narod.ru] [http://www.sovetsky.narod.ru]
+.,.+' `+.,.+' `+.,.+' `+.,.+'
--- Deadly Moroz/386 v3.0.1-asa9 SR3 ...
* Origin: Мое сердце бьется слева! (http://www.rkrp-rpk.ru) (2:5027/16.13)
— RU.COMPRESS
From : Dmitry Shkarin 2:5020/400 08 Jun 02 01:03:42
To : Maxim Smirnov
Subj : Re: exe compression
From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru>
Hi, Maxim!
> Выложил архиинтересную свежеворованную
> статью про сжатие исполнимых файлов.
> Как обычно, дело рук майкрософтовских
> наймитов.
А фигня, ИМХО.
1) Hа 3/4 выигрыш идет за счет банального E8.
2) Интеловский компайлер старался, инструкции переупорядочивал, чтобы
они декодировались быстрее. Пришли горячие MS-парни и всю малину попортили.
--- ifmail v.2.15dev5
* Origin: home (2:5020/400)
— RU.COMPRESS
From : IP Robot 2:5093/4.126 08 Jun 02 02:04:14
To : All
Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/
ftp://ftp.elf.stuba.sk/pub/pc/pack/unarj265.exe
UnARJ v2.65 (97,952 bytes)
--- PktMake.pl
* Origin: PktMake.pl (2:5093/4.126)
[an error occurred while processing this directive][an error occurred while processing this directive]