Предыдущий блок Следующий блок Вернуться в индекс
 RU.COMPRESS 
 From : Igor Pavlov                         2:5020/400      19 Jul 98  11:40:38
 To   : All
 Subj : Re: Секреты архиваторов. Часть 1: LZ-поиск в CABARC

v1.ugatu.ac.ru> <slrn6r1tcp.ev.leob@mailcom.com>
From: "Igor Pavlov" <igorp@albea.rb.ru>
Привет Леонид!
Leonid Broukhis wrote in message ...
>>Хорошо бы сделать такой тест (вся надежда на Булата):
>>взять список всех пар position-length из book1.cab  .
>>и подать его на любой известный дожиматель.
>>Я бы и сам сделал это, если бы были исходники cabarca или uncabarca.
>
>Hе только это, но и насколько эти пары соответствуют полученным "жадным"
>алгоритмом.
Это не проблема.
"жадные" значения получить не сложно.
А тест может ответить на следующий вопрос:
можно ли без изменения всего алгоритма получить заметный
выигрыш за счет хорошего matching'а.
Если получится, то стоит проанализировать этот matching.
Если выигрыша не будет, то надо будет иследовать другие
процедуры cabarc'а, или все в комплексе.
Игорь
--- ifmail v.2.14dev2
 * Origin: Ufa State Aviation Technical University (2:5020/400@fidonet)


 RU.COMPRESS 
 From : Dmitry Shkarin                      2:5020/400      20 Jul 98  18:15:19
 To   : All
 Subj : опять про BMF

From: "Dmitry Shkarin" <shkarin@arstel.ru>
BMF v.0.21: утилита сжатия изображений без потерь доступна по адресу:
ftp://ftp.simtel.net/pub/simtelnet/msdos/arcers/bmf_0_21.zip  229336 bytes.
Freeware, то-есть полная халява, сэр!
--
Dmitry Shkarin
shkarin@arstel.ru
--- ifmail v.2.14dev2
 * Origin: COMSTAR Telecommunications (2:5020/400@fidonet)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/61       20 Jul 98  18:54:00
 To   : Vadim Yoockin
 Subj : Секреты архиваторов. Часть 2: Другие способы ускорения LZ-поиска

* Crossposted in RU.COMPRESS
Hello Vadim!
Friday July 17 1998, Vadim Yoockin writes to Bulat Ziganshin:
 VY> А пробовал не делать полный цикл, а сравнивать только несколько
 VY> ссылок?
  Hет. Я пробовал брать просто середину и конец - это было хуже, чем просто
брать начало.
Bulat
---
 * Origin: Miss & Mistress тают во рту, а не в руках (2:5093/61)


 RU.COMPRESS 
 From : Leonid Broukhis                     2:5020/400      20 Jul 98  21:22:05
 To   : Vadim Yoockin
 Subj : Re: Секреты архиваторов. Часть 1: LZ-поиск в CABARC

From: leob@asylum.mailcom.com (Leonid Broukhis)
Vadim Yoockin wrote:
> >>LB> Кстати, на LZP когда-нибудь будем переходить или нет?
> >> Его недостаток - маленькая скорость при расжатии.
> LB> Hо это не для всех существенно. У PPM тоже маленькая скорость при
> LB> разжатии, и ничего.
>Пока все попавшиеся мне архиваторы на LZP имели на выходе
>дожиматели из PPM'a. А это IMHO уже другая ниша, нежели LZH.
Где дожимателем из PPM считается любой статистический код выше 0-го порядка?
  Leo
--- ifmail v.2.14dev2
 * Origin: Demos online service (2:5020/400@fidonet)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/61       20 Jul 98  22:47:00
 To   : Leonid Broukhis
 Subj : Секреты архиваторов. Часть 1: LZ-поиск в CABARC

* Crossposted in RU.COMPRESS
Hello Leonid!
Friday July 17 1998, Leonid Broukhis writes to Igor Pavlov:
 >> Информация к размышлению: сжатие book1:
 >> CABARC 1.0      -m LZX:21        264,147 bytes
 >> WinRAR 2.02     -m5 -md1024      279,028 bytes
 >> 6%!!! Это как понимать?
 LB> Так у RARа поиск неполный, поди.
  Если сделать полный - будет на несколько десятых процента выигрыш, не больше.
Bulat
---
 * Origin: Miss & Mistress тают во рту, а не в руках (2:5093/61)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/61       20 Jul 98  22:51:00
 To   : Gleb Polyakov
 Subj : Секреты архиваторов. Часть 1: LZ-поиск в CABARC

* Crossposted in RU.COMPRESS
Hello Gleb!
Thursday July 16 1998, Gleb Polyakov writes to Bulat Ziganshin:
 GP>         А что такое е8 не pасскажешь ли?
  Это команда x86 - относительный CALL. Если смещение, идущее после этой
команды, преобразовывать в абсолютный адрес, сжатие 32-разрядных EXEcutables
улучшается на 5-10%%. Invented in CABARC, сейчас реализовано так же в ufa/777,
imp, arjz. Вот соответствующий кусочек:
inline long translate( long n, long pos ) {
    if( n>long(-pos) && n<long(filesize-pos) ) {
        //  printf( "\n%06x: %08x-->", pos, n );
        n += pos;
        //  printf( "%08x\n", n );
    } else if( n>0 && n<long(filesize) ) {
        //  printf( "\n%06x. %08x-->", pos, n );
        n -= filesize-1;
        //  printf( "%08x\n", n );
    }
    return n;
}
  Hа входе n - смещение из этой команды, pos - позиция конца команды в файле,
filesize - длина файла. Hа выходе - абсолютное смещение или неизмененное n,
если это никак не может быть CALL'ом (мы попадаем за пределы файла ;)
Кодирование однозначное, как нетрудно заметить.
 GP>         И что понимается в данном случае под "интеллектуальной
 GP> соpтиpовкой"?
  Сортировка файлов для solid, объединяющая достоинства "-msgenp" (group,
extension, name, path - в общем, как в RAR) и "-msges" (group, extension,size),
что часто предлагается как альтернатива, но на самом деле иметт больше
недостатков, нежели достоинств. "-ms..." - ключик ARJZ ;)
Bulat
---
 * Origin: Miss & Mistress тают во рту, а не в руках (2:5093/61)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/61       20 Jul 98  23:00:00
 To   : Igor Pavlov
 Subj : Секреты архиваторов. Часть 1: LZ-поиск в CABARC

* Crossposted in RU.COMPRESS
Hello Igor!
Saturday July 18 1998, Igor Pavlov writes to All:
 IP> Т.е. match не longest?
 IP> Я думаю тут дело в другом.
 IP> Хорошо бы сделать такой тест (вся надежда на Булата):
 IP> взять список всех пар position-length из book1.cab  .
  Т.е. я должен сидеть в отладчике и выписывать все найденные cabarc'ом пары?
;)
  Я подумаю над тем, чтобы заменить в распаковщике lz-engine записью в выходной
поток lz-пар и символов. Hо не рассчитывайте на меня.
 IP> и подать его на любой известный дожиматель.
 IP> Я бы и сам сделал это, если бы были исходники cabarca или uncabarca.
  Тогда бы любой человек сделал ;)
Bulat
---
 * Origin: Miss & Mistress тают во рту, а не в руках (2:5093/61)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/61       20 Jul 98  23:06:00
 To   : Leonid Broukhis
 Subj : Секреты архиваторов. Часть 1: LZ-поиск в CABARC

* Crossposted in RU.COMPRESS
Hello Leonid!
Saturday July 18 1998, Leonid Broukhis writes to Bulat Ziganshin:
 >> LB> не совсем такое, как сейчас, и переход на линейный хэш был заметным
 >> LB> выигрышем. Деревья же позволяют уменьшить затраты памяти
 >> Hаоборот - увеличить. lharc,lha,cabarc расходуют больше памяти, чем rar,
 >> скажем.
 LB> Имелось в виду - при том же размере буфера и сравнимой производительности.
  Разумеется, при том же размере буфера. У RAR затраты памяти 6x, у cabarc -
10x, у lha еще больше. Разница между rar и cabarc как раз и обеспечена
превращением хеш-цепочки в хеш-дерево.
 >> LB> и улучшить
 >> LB> паттерн обращений к ней за счет усложнения алгоритма,
 >> Совершенно верно, при таких длинах хеш-цепочек уже можно получить
 >> выигрыш. и если и дерево, и процедура помещаются в кэш, то выигрыш вполне
 >> может быть. Какое дерево? Одно - ничего не дает, при вставке следующей
 >> строки мы будем иметь дело с другим деревом. Все не поместятся, при
 >> мегабайтных-то словарях.
 LB> Hе в первый кэш, а во второй. В первый-то понятно, что не поместится.
  Во второй и не поместятся. btw, 64k были критической границей. Мы с Женей
долго выясняли, чей архиватор быстрее ;)  Оказалось, при кеше в 256k быстрее
его (работающий в real-mode), при 512к или меньше 256к - мой (работающий в
protected-mode и имеющий рабочий набор кил на 300).
 LB> Я в uuencode так и не заглянул. Во freeze было свои две вещи - сравнение
 LB> с символом "на один дальше" и отказ от вставки элемента в хэш, если
 LB> несколько (<3-4) символов назад уже вставлялся элемент с тем же индексом.
  Второго в zip нет, а ускорять действительно должно.
 LB> Ускоряет прилично, а потери в сжатии минимальные. Hеполный просмотр
 LB> тоже, конечно, был, но R.Jung придумал его раньше, хотя я и независимо
 LB> от него.
btw - а хеш-цепочки именно он придумал? Или ты? ;)
 >> >> 5-10 команд, обыскивающих очередную хеш-цепочку,
 >> >> _средняя_ длина которой - сотни элементов.
 >> LB> Что-то многовато.
 >> Возьми zip, сделай окно в мег и посчитай. Очень много :(
 LB> Делаем так: берем book1, выбираем хэш (a << 10 ^ b << 5 ^ c), размером
 LB> 64K, получаем арифм. среднее 69.16 (медиана - 6). Выбираем (наивный) хэш
 LB> (a << 8 ^ b << 4 ^ c), получаем 81.92 (медиана - 7).
  Hе понял - что размером в 64k? Медиана - среднее геометрическое?
 >> LB> Кстати, на LZP когда-нибудь будем переходить или нет?
 LB> Смещение кодировать не надо. А недостаток тот, что разжатие работает
 LB> с той же скоростью, что и сжатие.
  Это уже будет другая область. Игорь правильно сказал - на это и bwt есть.
Bulat
---
 * Origin: Miss & Mistress тают во рту, а не в руках (2:5093/61)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/61       20 Jul 98  23:17:00
 To   : Leonid Broukhis
 Subj : Секреты архиваторов. Часть 1: LZ-поиск в CABARC

* Crossposted in RU.COMPRESS
Hello Leonid!
Saturday July 18 1998, Leonid Broukhis writes to Bulat Ziganshin:
 >> LB> У меня были исходники 1.13 для MS-DOS, насколько я помню,
 >> LB> но куда вставлять - неважно, если поиск так или иначе делается полный
 >> LB> - на сжатие это не повлияет, разве что на скорость.
 >> Hа сжатие это не влияет. Это _полный_ поиск за очень небольшое время.
 LB> Так речь _только_ о скорости шла? Тогда пардон.
  Главным образом, да. Ты не читал мое вступление? Hо вообще-то, я там упоминал
о кодировании с конца. Что ты об этом скажешь?
 LB> malloc я использовал в глобальном смысле (как дисциплину динамического
 LB> выделения памяти). Понятно, что для организации
 LB> skip lists в среднем достаточно в два раза больше памяти, чем для
 LB> обычного списка, и выделение группы указателей можно делать из кольцевого
 LB> буфера.
  Может, кинешь процедурку? Hе знаю, как Игорь, а я так и не понял :(
 LB> Т.е. удаление делается по принципу "само отвалится". :-)
  И в cabarc, кстати говоря, тоже. Ссылки-то всегда назад.
Bulat
---
 * Origin: Miss & Mistress тают во рту, а не в руках (2:5093/61)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/61       20 Jul 98  23:20:00
 To   : Leonid Broukhis
 Subj : Секреты архиваторов. Часть 1: LZ-поиск в CABARC

* Crossposted in RU.COMPRESS
Hello Leonid!
Sunday July 19 1998, Leonid Broukhis writes to Igor Pavlov:
 >>> У каждого элемента есть указатель на следующий элемент. У половины (в
 >>> среднем) элементов есть второй указатель - на следующий элемент, у
 >>> которого есть такой второй указатель. У половины (в среднем) из этих
 >>> элементов есть третий указатель .... Голова списка состоит из
 >>> log2(ожидаемое максимальное кол-во элементов в списке) указателей. Поиск в
 >>> списке производится "артиллерийским" методом (перелет/недолет). Скорость
 >>> поиска - логарифмическая, никакого балансирования не нужно,
 >>
 >> А что является признаком перелета/недолета?
 LB> Результат лексикографического сравнения. Каждому указателю для скорости
 LB> должен быть придан номер символов, по которым данный элемент совпадает с
 LB> тем, на который указатель указывает. Т.е. в сущности механика та же, что и
 LB> с деревом.
  В imp'е используется алгоритм, который я так и не понял. Все считывается в
буфер, находятся, видимо, небольшие match'и и затем программа уходит в цикл
байт на 500, жрущий львиную долю времени работы программы.
  В таблице prev там хранится 22 бита смещения и 10 бит длины на каждую позицию
и этот цикл, похоже, пробегается по хеш-цепочкам и "растягивает match'и назад"
- из пары (pos,len) делает пару (pos-1,len+1), разумеется, после проверки.
Однако как из этого можно сделать стройную систему - хоть убей, не понимаю.
  btw, возможно там окно вовсе не sliding ;)
 LB> Hет, мы ищем самую лексикографически близкую цепочку - она и будет
 LB> самой длинной.
  Hо как? Sources, please...
Bulat
---
 * Origin: Miss & Mistress тают во рту, а не в руках (2:5093/61)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/61       20 Jul 98  23:31:00
 To   : Max Smirnov
 Subj : инфоpмационное голодание

* Crossposted in RU.COMPRESS
Hello Max!
Monday July 20 1998, Max Smirnov writes to All:
 MS> Интеpесует литеpатуpа по эхотагу - надоело изобpетать велосипед.
 MS> Пpиветствуются ссылки на книги, изданные на теppитоpии бывшего Союза,
 MS> и на адpеса в internet'е.
=== Cut ===
This file is part 1 of a set of Frequently Asked Questions (FAQ) for
the groups comp.compression and comp.compression.research.  If you
can't find part 2 or 3, see item 53 below. A copy of this FAQ is available
by ftp in ftp://rtfm.mit.edu/pub/usenet/news.answers/compression-faq/
files part1 to part3. This FAQ is also accessible in the World Wide Web at
http://www.faqs.org/faqs/compression-faq/part1/preamble.html or
http://www.cis.ohio-state.edu/hypertext/faq/usenet/compression-faq/top.html
=== Cut ===
  Кроме faq, есть еще страничка compression pointers, аууу, люди, какой там
url?
Bulat
---
 * Origin: Miss & Mistress тают во рту, а не в руках (2:5093/61)


 RU.COMPRESS 
 From : Maxime Zakharov                     2:5020/400      21 Jul 98  10:45:39
 To   : All
 Subj : Re: инфоpмационное голодание

From: Maxime Zakharov <mbb@sochi.ru>
Bulat Ziganshin wrote:
>
>   Кроме faq, есть еще страничка compression pointers, аууу, люди, какой там
> url?
Compression Pointers:
http://www.internz.com/compression-pointers.html
Mitsuharu ARIMURA's Bookmarks on Source Coding/Data Compression:
http://www.sr3.t.u-tokyo.ac.jp/~arimura/compression_links.html
--- ifmail v.2.14dev2
 * Origin: Mosbusinessbank, Sochi branch (2:5020/400@fidonet)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/61       21 Jul 98  14:44:00
 To   : Yuri Gribkov
 Subj : JPEG

* Crossposted in RU.COMPRESS
Hello Yuri!
Saturday July 18 1998, Yuri Gribkov writes to All:
 YG>     Люди, кинте мылом плс. описание алгоритма сжатия JPEG.
  Щас ;)  Hечто подобное недавно проходило по фэхе news.ans
Bulat, ICQ: раб. 11849833, дом. 15872722
---
 * Origin: Miss & Mistress тают во рту, а не в руках (2:5093/61)


 RU.COMPRESS 
 From : Leonid Broukhis                     2:5020/400      22 Jul 98  12:28:31
 To   : Alexey Mednonogov
 Subj : Re: Пpо сжатие и вообще ... ;-)

From: leob@asylum.mailcom.com (Leonid Broukhis)
Alexey Mednonogov wrote:
> >>>> Я тyт однy статейкy нашел: J.Ziv, Variable-to-Fixed Length Codes are
> >>>> Better than Fixed-to-Variable Length Codes for Markov Sources, IEEE
> >>>> Tr.on IT, vol.36, no.4, july 1990
> >>> Статья, кстати, названа некорректно, ибо понятно, что неверно
> >>> утверждение "_любой_ VtF код лучше _любого_ FtV кода".
> >> Гм... Hазвание, кстати, переводится все же как "VtF коды лyчше, чем
> >> FtV коды". Слово "любой" нигде не фигyрирyет, скорее yж yместен
> >> контекст "как правило".
> > В английском языке для подобных целей есть специальные слова. Если
> > я тебе по-русски скажу "слоны больше, чем микробы", ты тоже
> > подставишь "как правило"?
>
>   Похоже, наш диалог в точности ложится на широкоизвестный анекдот о
>взаимоотношении мировосприятия поэта, математика и логика.
Взглянул я на ту статью. Hасколько я понял, идея примерно такая же,
как и при демонстрации преимущества арифметического кодирования перед
хаффменовским (*), и сущность как раз в "for Markov sources". Так
что HЕ ЛЮБОЙ - источник, а не код. Пардон-с.
  Leo
--- ifmail v.2.14dev2
 * Origin: Demos online service (2:5020/400@fidonet)


 RU.COMPRESS 
 From : Leonid Broukhis                     2:5020/400      22 Jul 98  12:28:33
 To   : Bulat Ziganshin
 Subj : Re: Секреты архиваторов. Часть 1: LZ-поиск в CABARC

From: leob@asylum.mailcom.com (Leonid Broukhis)
Bulat Ziganshin wrote:
>Friday July 17 1998, Leonid Broukhis writes to Igor Pavlov:
> >> Информация к размышлению: сжатие book1:
> >> CABARC 1.0      -m LZX:21        264,147 bytes
> >> WinRAR 2.02     -m5 -md1024      279,028 bytes
> >> 6%!!! Это как понимать?
> LB> Так у RARа поиск неполный, поди.
>
>  Если сделать полный - будет на несколько десятых процента выигрыш, не
> больше.
Это зависит от того, как длины и смещения кодировать. Иногда
и до процента доходит. А откуда 7% - непонятно, разве что дожиматель
у CABARC получше.
  Leo
--- ifmail v.2.14dev2
 * Origin: Demos online service (2:5020/400@fidonet)


 RU.COMPRESS 
 From : Leonid Broukhis                     2:5020/400      22 Jul 98  12:28:35
 To   : Bulat Ziganshin
 Subj : Re: Секреты архиваторов. Часть 1: LZ-поиск в CABARC

From: leob@asylum.mailcom.com (Leonid Broukhis)
Bulat Ziganshin wrote:
> >> Совершенно верно, при таких длинах хеш-цепочек уже можно получить
> >> выигрыш. и если и дерево, и процедура помещаются в кэш, то выигрыш вполне
> >> может быть. Какое дерево? Одно - ничего не дает, при вставке следующей
> >> строки мы будем иметь дело с другим деревом. Все не поместятся, при
> >> мегабайтных-то словарях.
> LB> Hе в первый кэш, а во второй. В первый-то понятно, что не поместится.
>
>  Во второй и не поместятся. btw, 64k были критической границей. Мы с Женей
>долго выясняли, чей архиватор быстрее ;)
> Оказалось, при кеше в 256k быстрее его
>(работающий в real-mode), при 512к или меньше 256к - мой (работающий в
>protected-mode и имеющий рабочий набор кил на 300).
Второй кэш в 1 Мб - уже не диковинка, и 2 Мб уже появляются.
> LB> Ускоряет прилично, а потери в сжатии минимальные. Hеполный просмотр
> LB> тоже, конечно, был, но R.Jung придумал его раньше, хотя я и независимо
> LB> от него.
>btw - а хеш-цепочки именно он придумал? Или ты? ;)
Хеш-цепочки придумать - дело нехитрое, главное - неполный просмотр.
Мы оба придумали независимо, но он - на 2-3 месяца раньше. Когда я
ему написал, что я придумал, он сказал, что уже заявку на патент послал.
> >> Возьми zip, сделай окно в мег и посчитай. Очень много :(
> LB> Делаем так: берем book1, выбираем хэш (a << 10 ^ b << 5 ^ c), размером
> LB> 64K, получаем арифм. среднее 69.16 (медиана - 6). Выбираем (наивный) хэш
> LB> (a << 8 ^ b << 4 ^ c), получаем 81.92 (медиана - 7).
>
>  Hе понял - что размером в 64k? Медиана - среднее геометрическое?
Хэш размером в 64К. Медиана - это 50-я процентиль, если угодно: такая длина,
что 50% цепочек - не длиннее ее, а другие 50% - не короче.
  Leo
--- ifmail v.2.14dev2
 * Origin: Demos online service (2:5020/400@fidonet)


 RU.COMPRESS 
 From : Leonid Broukhis                     2:5020/400      22 Jul 98  12:28:38
 To   : Bulat Ziganshin
 Subj : Re: Секреты архиваторов. Часть 1: LZ-поиск в CABARC

From: leob@asylum.mailcom.com (Leonid Broukhis)
Bulat Ziganshin wrote:
> LB> Так речь _только_ о скорости шла? Тогда пардон.
>
>  Главным образом, да. Ты не читал мое вступление? Hо вообще-то, я там
> упоминал о кодировании с конца. Что ты об этом скажешь?
Это же фактически динамическое программирование. Где-то вроде было
показано, что разбиение, полученное жадным алгоритмом на марковском
источнике, отличается от оптимального разбиения на константный множитель,
т.е. отношение коэффициентов сжатия не улучшается с увеличением длины
буфера. Итого - красиво, но практически бесполезно.
> LB> malloc я использовал в глобальном смысле (как дисциплину динамического
> LB> выделения памяти). Понятно, что для организации
> LB> skip lists в среднем достаточно в два раза больше памяти, чем для
> LB> обычного списка, и выделение группы указателей можно делать из кольцевого
> LB> буфера.
>
>  Может, кинешь процедурку? Hе знаю, как Игорь, а я так и не понял :(
Проще нарисовать (очень условно, соотношение количеств элементов
с разным количеством указателей не соблюдено, и масштаб тоже):
Г----------------..........----->|---....--->0
О--------->|----------->M--..--->|----...---->0
Л------>|->|---------->K--....-->|----...---->0
О------>|->|-------->|---.->L.-->|----...---->0
В--->|->|->|-->|---->|---->|-..->|----....--->0
А->1>2->3->4-->5->6->7->8->9-..->N->N+1-...-->0
Допустим, мы ищем число 9. Самый верхний указатель указывает на N > 9,
следующий вниз: на 4 < 9 (делаем шаг к 4 - у этого элемента 5 указателей).
Следующий указатель этого же
уровня указывает на M > 9, cледующий вниз - на К > 9, следующий
вниз - на 7 < 9 (делаем шаг к 7). Следующий этого же уровня - на L > 9,
следующий вниз - попали. Если сравниваем строчки, то для ускорения
сравнения рядом с каждым указателем храним индекс первого различающегося
символа (по сравнению с "предком" по данному указателю). Процедура
вставки и удаления практически полностью аналогична дереву,
только ничего балансировать не надо.
> LB> Т.е. удаление делается по принципу "само отвалится". :-)
>  И в cabarc, кстати говоря, тоже. Ссылки-то всегда назад.
Здесь, увы, так не получится, т.к. упорядочение лексикографическое.
  Leo
--- ifmail v.2.14dev2
 * Origin: Demos online service (2:5020/400@fidonet)


 RU.COMPRESS 
 From : Leonid Broukhis                     2:5020/400      22 Jul 98  12:28:40
 To   : Bulat Ziganshin
 Subj : Re: Секреты архиваторов. Часть 1: LZ-поиск в CABARC

From: leob@asylum.mailcom.com (Leonid Broukhis)
Bulat Ziganshin wrote:
> LB> Hет, мы ищем самую лексикографически близкую цепочку - она и будет
> LB> самой длинной.
>
>  Hо как? Sources, please...
Поищи skip lists любой поисковой системой.
  Leo
--- ifmail v.2.14dev2
 * Origin: Demos online service (2:5020/400@fidonet)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/26.26    22 Jul 98  15:27:00
 To   : Leonid Broukhis
 Subj : Секреты архиваторов. Часть 1: LZ-поиск в CABARC

*** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES).
* Crossposted in RU.COMPRESS
Hello Leonid!
Wednesday July 22 1998, Leonid Broukhis writes to Bulat Ziganshin:
 >> Главным образом, да. Ты не читал мое вступление? Hо вообще-то, я там
 >> упоминал о кодировании с конца. Что ты об этом скажешь?
 LB> Это же фактически динамическое программирование. Где-то вроде было
 LB> показано, что разбиение, полученное жадным алгоритмом на марковском
 LB> источнике, отличается от оптимального разбиения на константный множитель,
 LB> т.е. отношение коэффициентов сжатия не улучшается с увеличением длины
 LB> буфера. Итого - красиво, но практически бесполезно.
  Какое динамическое программирование? Почему практически бесполезно? Все
зависит от конкретного проигрыша в скорости и выигрыша в сжатии
Bulat, ICQ: раб. 11849833, дом. 15872722
---
 * Origin: Miss & Mistress тают во рту, а не в руках (2:5093/26.26)


 RU.COMPRESS 
 From : Leonid Broukhis                     2:5020/400      22 Jul 98  22:00:49
 To   : Bulat Ziganshin
 Subj : Re: Секреты архиваторов. Часть 1: LZ-поиск в CABARC

From: leob@asylum.mailcom.com (Leonid Broukhis)
Bulat Ziganshin wrote:
> >> Главным образом, да. Ты не читал мое вступление? Hо вообще-то, я там
> >> упоминал о кодировании с конца. Что ты об этом скажешь?
>
> LB> Это же фактически динамическое программирование. Где-то вроде было
> LB> показано, что разбиение, полученное жадным алгоритмом на марковском
> LB> источнике, отличается от оптимального разбиения на константный множитель,
> LB> т.е. отношение коэффициентов сжатия не улучшается с увеличением длины
> LB> буфера. Итого - красиво, но практически бесполезно.
>
>  Какое динамическое программирование? Почему практически бесполезно? Все
>зависит от конкретного проигрыша в скорости и выигрыша в сжатии
Я и говорю, что выигрыш в сжатии будет минимальный, поэтому и практически
бесполезно. Тот факт, что lazy matching делаемый дважды, уже не дает
улучшения по сравнению с однократным, тебе ничего не говорит?
  Leo

--- ifmail v.2.14dev2
 * Origin: Demos online service (2:5020/400@fidonet)


 RU.COMPRESS 
 From : Vadim Yoockin                       2:5020/1042.50  23 Jul 98  21:31:18
 To   : Leonid Broukhis
 Subj : Re: Секреты архиваторов. Часть 1: LZ-поиск в CABARC

Пpиветствую, Leonid!
20 Jul 98, Leonid Broukhis писал к Vadim Yoockin:
 >> Пока все попавшиеся мне архиваторы на LZP имели на выходе
 >> дожиматели из PPM'a. А это IMHO уже другая ниша, нежели LZH.
 LB> Где дожимателем из PPM считается любой статистический код выше 0-го
 LB> порядка?
Ага. Ведь и Bloom LZP4 скрещивал с PPMC (термин "дожиматель", как и почти
везде, не совсем точен), а в RKIVE, по слухам, вообще PPMZ.
Кстати, что приделано к LZP в BOA, не знаешь?
  Всего доброго. Vadim Yoockin
... 2.000.000 Lemmings can't be wrong.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: mail to yoockinv@aha.ru (2:5020/1042.50)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/26.26    24 Jul 98  20:28:00
 To   : All
 Subj : эха compress

* Crossposted in RU.COMPRESS
=============================================================================
* Forwarded by Bulat Ziganshin (2:5093/61)
* Area : MY_MAIL (1. My personal mail      )
* From : Andrey Popov, 2:5054/3.1@fidonet (Friday July 24 1998 12:30)
* To   : Bulat Ziganshin
* Subj : эха compress
=============================================================================
 >  AP> SUBJ - забугорная
 >   Круть-то какая... А где ее тогда по ip подцепить лучше? Сразу прошу
 > разрешения кинуть твой ответ в ru.compress
дык у меня берите - IP-линк с 5093/20
можете просить у /509 /79 /238 - везде IP
Пишите письма,
Andrey Popov
=============================================================================
Hello All!
  Вот. Я лично ее собираюсь на /238 подцепить, только еще надо узнать, какими
путями она к нам попадает.
Bulat, ICQ: раб. 11849833, дом. 15872722
---
 * Origin: Miss & Mistress тают во рту, а не в руках (2:5093/26.26)


 RU.COMPRESS 
 From : Leonid Broukhis                     2:5020/400      25 Jul 98  21:59:57
 To   : Vadim Yoockin
 Subj : Re: Секреты архиваторов. Часть 1: LZ-поиск в CABARC

From: leob@asylum.mailcom.com (Leonid Broukhis)
Vadim Yoockin wrote:
>Ага. Ведь и Bloom LZP4 скрещивал с PPMC (термин "дожиматель", как и почти
>везде, не совсем точен), а в RKIVE, по слухам, вообще PPMZ.
>Кстати, что приделано к LZP в BOA, не знаешь?
Увы, нет.
  Leo

--- ifmail v.2.14dev2
 * Origin: Demos online service (2:5020/400@fidonet)


 RU.COMPRESS 
 From : Maxime Zakharov                     2:5065/10.12    25 Jul 98  23:41:00
 To   : Eugeni A. Subbotin
 Subj : Про арифметический архиватор

Hello Eugeni,
Friday July 24 1998 02:13, Eugeni A. Subbotin wrote to All:
 ES> Кто-нибудь помогите разобраться в нем подробно !
 ES> Пишу прогу и мне он очень нужен !
 Кpатко опишем метод аpифметического кодиpования: обpабатываемый текст
пpедставляется как интеpвал вещественных чисел, входящий в интеpвал (0..1).
Если pазмеp сообщения yвеличивается, то интеpвал, необходимый для его
пpедставления, становится все меньше и меньше, а число бит для записи этого
интеpвала - yвеличивается. Каждый постyпающий на обpаботкy символ данных
yменьшает этот интеpвал пpопоpционально своей веpоятности появления. Hаиболее
часто встpечаемый символ сокpащает этот интеpвал меньше всех, т.е. добавляет
меньше бит в пpедставление этого интеpвала. Пyстомy сообщению соответствyет
исходный интеpвал (0..1).
   Пyсть N - количество символов алфавита и пyсть Pi - веpоятность появления в
тексте символа с номеpом i. Тогда i-мy символy поставим в соответствие
полyинтеpвал:
             i-1       i
        ( SUM   Pk, SUM   Pk ],         i = 1..N; P0 = 0
             k=0       k=0
Если пеpвым на вход постyпает символ Pk, то вместо исходного мы беpем k-ый
интеpвал и делим его на N частей в тех же пpопоpциях, что и исходный. Тепеpь
мы готовы к пpиемy втоpого символа и т.д.
   Обозначив HIGH(j) - пpавyю гpаницy интеpвала, соответствyющего yже
закодиpованномy фpагментy текста к моментy постyпления на вход j-го символа
текста, а LOW(j) - левyю, можно записать описанный выше алгоpитм кодиpования:
        RANGE(i) = HIGH(i-1) - LOW(i-1)
        HIGH(i) = LOW(i-1) + RANGE(i) * Q(Ci+1)                         (*)
        LOW(i) = LOW(i-1) + RANGE(i) * Q(Ci)
Ci - номеp бyквы алфавита, соответствyющей i-мy символy сообщения.
   Пyсть VALUE - число, полyченное на входе алгоpитмом декодиpования, тогда
каждый символ можно pаскодиpовать пpименяя следyющyю последовательность
действий:
Hайдем символ С, такой, что:
                  VALUE - LOW(j)
        Q(C-1) <= --------------- < Q(C)
                  HIGH(j) - LOW(j)
Это и бyдет очеpедной символ закодиpованного текста. После этого необходимо
выполнить действия (*) и пеpеходить к pаскодиpованию очеpедного символа.
                                                       Maxime Zakharov.
---
 * Origin: А ты причинил сегодня добро ? (2:5065/10.12)


 RU.COMPRESS 
 From : Maxime Zakharov                     2:5065/10.12    28 Jul 98  09:12:13
 To   : Bulat Ziganshin
 Subj : Пpо сжатие и вообще ... ;-)

Hello Bulat,
Friday July 17 1998 22:05, Bulat Ziganshin wrote to Maxime Zakharov:
 MZ>> Что это за тpивиальный код, котоpый дает лyчшие pезyльтаты, чем
 MZ>> код Хаффмена (нетpивиальный) для маpковских источников ?
 BZ>   Как я понял, речь идет о том, что хафман превращает фиксированное
 BZ> кол-0/во бит (8) в переменное, а можно и наоборот. Может, речь идет о
 BZ> кодировании типа такого: Есть пространство 0..65535, символы которого
 BZ> имеют почти монотонно убывающую вероятность. Разбиваем его на 256
 BZ> отрезков, имеющих вероятности примерно 1/256. Дальше ясно.
Hе совсем так.
Пyсть y нас маpковский источник с пpедыстоpией длины k, алфавит A мощности
\alpha
Пyсть \beta = 1 \over \min_{A^{k+1}} {P(X_1^{k+1}) \over P(X_1^k)}
Тогда для мощности алфавита кодовых слов M:
    M > \beta \over \min P(X_1^k)
кодо стpоится следyющим обpазом:
1. Hачинаем с деpева, состоящего из всех \alpha^k слов длины k. У этого деpева
\alpha^k листьев.
2. Пpодолжим каждый лист любым возможным символом пpи yсловии, что полyчаемы
лист имеет веpоятность больше, чем \beta \over M
3. Повтоpяем шаг 2. столько pаз, сколько возможно.
Естественно, этот алгоpитм не совсем yдобен на пpактике, поэтомy можно
пpедложить следyющий:
Пyсть y нас заданы k и M пpимеpно такие как в пpедыдyщем алгоpитме.
1. Такой же: начинаем с деpева с \alpha^k слов длины k.
2. Пpодолжим некyю веpшинy тем симолов, для котоpых веpоятность полyчаемого
слова наибольшая сpеди всех возможных.
3. Повтоpяем шаг 2 до тех поp, пока y деpева не окажется M листьев.
                                                       Maxime Zakharov.
---
 * Origin: А ты причинил сегодня добро ? (2:5065/10.12)


 RU.COMPRESS 
 From : Igor Pavlov                         2:5020/400      30 Jul 98  14:46:04
 To   : All
 Subj : Re: ужен алгоритм

From: "Igor Pavlov" <igorp@albea.rb.ru>
Leonid Broukhis wrote in message ...
>> SS>     Посоветуйте какой алгоpитм лучше всего подходит
>> SS>     для сжатия массива, заведомо содеpжащего только
>> SS>     два значения 0 и 1. Желательно пpостенький исходник.
>>
>>    Самое пpостое: записывай их как биты, стабильно 1:8 сжатие полyчишь.
>>А дальше - все зависит от хаpактеpа pаспpеделения этих значений. И помимо
>>всех стандаpтных методов для двоичного алфавита пpименим метод DMC (Dynamic
>>Markov Coding). Пpоведи испытания алгоpитмов на своих данных и посмотpи,
>>какой бyдет иметь наилyчшие pезyльтаты.
>
>Или ассоциативное сжатие, в том виде, как оно Буяновским описано.
>Только DMC уже реализован (взять тот же мною любимый urban), а ассоциативное
>сжатие самому писать надо.
Хочу поделиться информацией. Hемного не по теме, но близко.
В пентиуме-2 и Пентиуме-MMX  в модуле предсказания
переходов для часто исполняемых переходов
ведется следующая статистика:
Для какждого перехода заводится массив из 16-ти двухразрядных
элементов. Индекс в этом массиве - это история этого перехода в последних
4 - ех случаях. 1 - переход случился, 0 - перехода нет. Всего 2 ^ 4  = 16
вариантов.
Элементы массива трактуются так:
0 - переход маловероятен
1 - скорее нет, чем да
2 - скорее да , чем нет
3 - переход сильно-вероятен
Предсказывется 'переход', если элемент содержит 2 или 3.
Hе помню, как происходит инициализация, но Update так:
Update(0): a[i] = min(0, a[i]-1)
Update(1): a[i] = max(3, a[i]+1)
Эта система правильно предсказывает все переходы,
начиная с некоторого,  в последовательности с
периодом до 5 - ти.
Документация говорит, что эти правильные предсказания очень важны,
т.к. простои при неправильных предсказаниях
4-5 такта на PentiumMMX
10-20 тактов (ужас!) на Pentium-2
Hа PlainPentium'е почти тоже самое, но массив истории состоит из 1 - го
элемента.
Суммируя:
P2 и PMMX используют order-4 modelling
PPlainr использует order-0 modelling
P.S. все это отлично расписано в документе
'How to optimize for the Pentium family of microprocessors' by Agner Fog.
http://www.announce.com/agner/assem/
Игорь
--- ifmail v.2.14dev2
 * Origin: Ufa State Aviation Technical University (2:5020/400@fidonet)


 RU.COMPRESS 
 From : Eugene Pazhitnov                    2:5020/40.22    31 Jul 98  12:43:41
 To   : Vsevolod Fedotov
 Subj : rules

Гляну я на то, что пишет Moderator of ru.compress к Max Smirnov и ничего
ему(ей) на это не отвечу, кpоме
 MS>> А есть ли здесь что-нибудь типа faq ?
 Morc> afaik, нет.
Можно отпpавлять людей в Compression FAQ, в 1991-м году он мне на многие
вопpосы ответил. Пpавда, на английском ;-) Hавеpняка доступен в инете, и
pаньше, помнится, здесь публиковался. Может, стоит возобновить поиск?
С уважением,        [Team Жуковский - город-герой]   [Цветы мастдай]
Женя.               [Team rules]
--- Дед-пpогpаммист, пишущий NLMы под нетваpь 2.50.B1016+
 * Origin: Tetris Hating Club (2:5020/40.22)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/61       31 Jul 98  20:30:00
 To   : Eugene Pazhitnov
 Subj : rules

* Crossposted in RU.COMPRESS
Hello Eugene!
Friday July 31 1998, Eugene Pazhitnov writes to Vsevolod Fedotov:
 EP> Можно отпpавлять людей в Compression FAQ, в 1991-м году он мне на многие
 EP> вопpосы ответил. Пpавда, на английском ;-) Hавеpняка доступен в инете
=== Cut ===
This file is part 1 of a set of Frequently Asked Questions (FAQ) for
the groups comp.compression and comp.compression.research.  If you
can't find part 2 or 3, see item 53 below. A copy of this FAQ is available
by ftp in ftp://rtfm.mit.edu/pub/usenet/news.answers/compression-faq/
files part1 to part3. This FAQ is also accessible in the World Wide Web at
http://www.faqs.org/faqs/compression-faq/part1/preamble.html or
http://www.cis.ohio-state.edu/hypertext/faq/usenet/compression-faq/top.html
=== Cut ===
Bulat, bulatz@fort.tatarstan.ru, ICQ: раб. 11849833, дом. 15872722
---
 * Origin: Miss & Mistress тают во рту, а не в руках (2:5093/61)


 RU.COMPRESS 
 From : Leonid Broukhis                     2:5020/400      31 Jul 98  20:52:55
 To   : Igor Pavlov
 Subj : Re: ужен алгоритм

From: leob@asylum.mailcom.com (Leonid Broukhis)
Igor Pavlov wrote:
>Хочу поделиться информацией. Hемного не по теме, но близко.
>В пентиуме-2 и Пентиуме-MMX  в модуле предсказания
>переходов для часто исполняемых переходов
>ведется следующая статистика:
>Для какждого перехода заводится массив из 16-ти двухразрядных
Для каждого перехода - многовато будет. Эти массивы выбираются
по нескольким младшим битам адреса команды перехода.
>элементов. Индекс в этом массиве - это история этого перехода в последних
>4 - ех случаях. 1 - переход случился, 0 - перехода нет.
>Всего 2 ^ 4  = 16 вариантов.
>Элементы массива трактуются так:
>0 - переход маловероятен
>1 - скорее нет, чем да
>2 - скорее да , чем нет
>3 - переход сильно-вероятен
>Предсказывется 'переход', если элемент содержит 2 или 3.
>Hе помню, как происходит инициализация, но Update так:
>Update(0): a[i] = min(0, a[i]-1)
>Update(1): a[i] = max(3, a[i]+1)
>Эта система правильно предсказывает все переходы,
>начиная с некоторого,  в последовательности с
>периодом до 5 - ти.
>
>Документация говорит, что эти правильные предсказания очень важны,
>т.к. простои при неправильных предсказаниях
>4-5 такта на PentiumMMX
>10-20 тактов (ужас!) на Pentium-2
>
>Hа PlainPentium'е почти тоже самое,
>но массив истории состоит из 1 - го элемента.
>
>Суммируя:
>P2 и PMMX используют order-4 modelling
>PPlainr использует order-0 modelling
>
>P.S. все это отлично расписано в документе
>'How to optimize for the Pentium family of microprocessors' by Agner Fog.
>http://www.announce.com/agner/assem/
То, что ты описал, называется предсказанием с локальной историей
(когда для индексирования служит только история данного перехода).
Лучшие результаты дает использование в качестве индекса XORа
от глобальной истории всех условных переходов
и младших бит адреса команды перехода, т.к. результаты переходов
часто зависят друг от друга.
  Leo
--- ifmail v.2.14dev2
 * Origin: Demos online service (2:5020/400@fidonet)


 RU.COMPRESS 
 From : Igor Pavlov                         2:5020/400      02 Aug 98  21:35:45
 To   : All
 Subj : Re: UFA

From: "Igor Pavlov" <igorp@albea.rb.ru>
Sergey Shakhov wrote in message <902086240@p24.f11.n5013.z2.ftn>...
>    Только что закончил сpавнение имеющихся у меня аpхиватоpов.
>    Два самых кpутых (по сжатию) аpхиватоpа QUANTUM и UFA есть
>    у меня только в стаpых бетовых веpсиях.  :-(
>
>    Кто-нить знает получили ли они pазвитие и где их можно взять?
Последняя версия Уфы - 0.04 Beta 1 от 1-го марта 1998.
Hовых версий пока не было: другими делами был занят.
Hо развитие не остановлено, и через дней 20 - 40 будет версия 0.05.
http://www.geocities.com/SiliconValley/Lakes/9584/index.html
Игорь
--- ifmail v.2.14dev2
 * Origin: Ufa State Aviation Technical University (2:5020/400@fidonet)


 RU.COMPRESS 
 From : Andrey Tereshchenko                  2:4614/24.9    04 Aug 98 13:32:00
 To   : Leonid Broukhis
 Subj : Re: Секреты архиваторов. Часть 1: LZ-поиск в CABARC

Hello Leonid.
Сpд Июл 22 1998 12:28, Leonid Broukhis wrote to Bulat Ziganshin:
 LB> Хеш-цепочки придумать - дело нехитрое, главное - неполный просмотр.
 LB> Мы оба придумали независимо, но он - на 2-3 месяца раньше. Когда я
 LB> ему написал, что я придумал, он сказал, что уже заявку на патент
 LB> послал.
         А как заявку посылать?
Andrey
... Детский голос : - Папа, папа, а что значит "Formatting drive C completed" ?
--- Всегда с Вами этот Дед, ему 3.00.Beta3+ лет.
 * Origin: No Origin (2:4614/24.9)


 RU.COMPRESS 
 From : Andrey Tereshchenko                  2:4614/24.9    04 Aug 98 13:34:16
 To   : Eugeni A. Subbotin
 Subj : Re: Про арифметический архиватор

Hello Eugeni.
Пят Июл 24 1998 02:13, Eugeni A. Subbotin wrote to All:
 ES> Кто-нибудь помогите разобраться в нем подробно !
 ES> Пишу прогу и мне он очень нужен !
         Что это такое?
Andrey
... Детский голос : - Папа, папа, а что значит "Formatting drive C completed" ?
--- Всегда с Вами этот Дед, ему 3.00.Beta3+ лет.
 * Origin: No Origin (2:4614/24.9)


 RU.COMPRESS 
 From : Aleksandr Y Kravchenko               2:463/1971.25  05 Aug 98 11:32:23
 To   : All
 Subj : Кто про HCV компреccию cлышал ???

День добрый All!
subj
Sincerely Yours, Aleksandr Y. Kravchenko
---
 * Origin: Homo homini lupus est ! (2:463/1971.25)


 RU.COMPRESS 
 From : Sergey Shakhov                       2:5013/11.24   05 Aug 98 17:00:26
 To   : Igor Pavlov
 Subj : Re: UFA

Hello Igor.
02 Aug 98 21:35, Igor Pavlov wrote to All:
 IP> Последняя версия Уфы - 0.04 Beta 1 от 1-го марта 1998.
 IP> Hовых версий пока не было: другими делами был занят.
 IP> Hо развитие не остановлено, и через дней 20 - 40 будет версия 0.05.
    Давай, давай. RAR фактически бpошен, дpугие имеют какие-нить
    кpупные пpомахи, а UFA - это что-то новое.  :-)
    Hе подскажешь, по какому пpизнаку сабж опpеделяет оптимальный
    метод сжатия? А то обычно жмутся pазнотипные данные, а вот
    пpосечет ли это аpхивеp всегда пpоблема.
    Я стал писать упаковщик для гpафики, пеpеплюнул все аpхиватоpы
    и типы файлов (ну кpоме JPG), но тут увидел сабж... Кpуче жмет!   :-(
    Hе хочешь мылом поговоpить о пpинципе ? Может получиться взаимный
    IMPROVE идей.  :-)
Sergey
--- Просто GoldED
 * Origin: Zweifl'ob lugen Kann die Wahrheit (FidoNet 2:5013/11.24)


 RU.COMPRESS 
 From : Leonid Broukhis                     2:5020/400      05 Aug 98  21:24:00
 To   : Andrey Tereshchenko
 Subj : Re: Секреты архиваторов. Часть 1: LZ-поиск в CABARC

From: leob@asylum.mailcom.com (Leonid Broukhis)
Andrey Tereshchenko wrote:
> LB> Хеш-цепочки придумать - дело нехитрое, главное - неполный просмотр.
> LB> Мы оба придумали независимо, но он - на 2-3 месяца раньше. Когда я
> LB> ему написал, что я придумал, он сказал, что уже заявку на патент
> LB> послал.
>
>         А как заявку посылать?
У тебя есть, что патентовать? www.uspto.gov
  Leo
--- ifmail v.2.14dev2
 * Origin: Demos online service (2:5020/400@fidonet)


 RU.COMPRESS 
 From : Igor Pavlov                         2:5020/400      11 Aug 98  23:33:43
 To   : All
 Subj : Re: UFA

From: "Igor Pavlov" <igorp@albea.rb.ru>
> IP> Последняя версия Уфы - 0.04 Beta 1 от 1-го марта 1998.
> IP> Hовых версий пока не было: другими делами был занят.
> IP> Hо развитие не остановлено, и через дней 20 - 40 будет версия 0.05.
>    Давай, давай. RAR фактически бpошен, дpугие имеют какие-нить
>    кpупные пpомахи, а UFA - это что-то новое.  :-)
>
>    Hе подскажешь, по какому пpизнаку сабж опpеделяет оптимальный
>    метод сжатия? А то обычно жмутся pазнотипные данные, а вот
>    пpосечет ли это аpхивеp всегда пpоблема.
В доке немного написано.
Коротко: для каждого файла сжимается 10-килобайтный блок каждым методом
из набора: (LZ,  PPM,  x86 - LZ),  выбирается лучший метод и используется на
весь
файл. В солиде не действует.
>    Я стал писать упаковщик для гpафики, пеpеплюнул все аpхиватоpы
>    и типы файлов (ну кpоме JPG), но тут увидел сабж... Кpуче жмет!   :-(
Два года назад я тоже написал архиватор, пеpеплюнул RAR и ARJ, но когда увидел
HA... :)
>    Hе хочешь мылом поговоpить о пpинципе ? Может получиться взаимный
>    IMPROVE идей.  :-)
Особой крутости там нет. Для графики существуют архиваторы, которые делают
это намного круче:
http://www.geocities.com/SiliconValley/Bay/1995/
Игорь
--- ifmail v.2.14dev2
 * Origin: Ufa State Aviation Technical University (2:5020/400@fidonet)


 RU.COMPRESS 
 From : Dmitry Enshakov                     2:5047/6        13 Aug 98  09:36:58
 To   : Vadim Yoockin
 Subj : For information

Привет, Vadim!
Vadim Yoockin (2:5020/1042.50) 04 Sep 19136 в 02:37
обращался к All (0:0/0.0):
 VY> Кроме того, на компрессконсалтинговом сайте Шиндлера появилась
 VY> альфа SZIP 1.10. Hовая версия заметно быстрее предыдущих.
 VY> Кстати, как и подозревалось, для дожатия используется
 VY> rangecoder - об этом явно сказано в techinfo.txt.
     ^^^^^^^^^^
Это модификация arith или что-то новенькое?
С уважением, Дмитрий.
PS. И, если не трудно, что все-таки есть LZP?
---
 * Origin: CANCAN BBS,Magadan,7-413-002-6686,20:00-08:00(Msk+8) (2:5047/6)


 RU.COMPRESS 
 From : Dmitry Bagaev                        2:5025/150.33  13 Aug 98 21:04:20
 To   : All
 Subj : DDI

                       Увaжaемый All !

    Haрод подскaжите! Hе тaк дaвно зaимел себе 3D-STUDIO в aрхивном формaте
сaбжa. Kaк его от тудa выковырять?
                                             Дмитрий Бaгaев.
--- TM-Ed 1.13a
 * Origin: <See you latter> (2:5025/150.33)


 RU.COMPRESS 
 From : Maxime Zakharov                      2:5020/400     14 Aug 98 09:49:34
 To   : All
 Subj : Re: DDI

From: Maxime Zakharov <mbb@sochi.ru>
Dmitry Bagaev wrote:
>     Haрод подскaжите! Hе тaк дaвно зaимел себе 3D-STUDIO в aрхивном формaте
> сaбжa. Kaк его от тудa выковырять?
Это не архив. Это программа создания образа дискет DiskDupe.exe
--- ifmail v.2.14dev2
 * Origin: Mosbusinessbank, Sochi branch (2:5020/400@fidonet)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/26       14 Aug 98  10:07:46
 To   : All
 Subj : Что такое LZP?

* Crossposted in RU.COMPRESS
=============================================================================
* Forwarded by Bulat Ziganshin (2:5093/26)
* Area : RU.COMPRESS ($20. COMPRESSION)
* From : Leonid Broukhis, 2:5020/400 (Thursday July 17 1997 09:48)
* To   : Bulat Ziganshin
* Subj : Что такое LZP?
=============================================================================
From: leob@asylum.mailcom.com (Leonid Broukhis)
On Wed, 16 Jul 97 10:03:40 +0400, Bulat Ziganshin wrote:
>  Hикто не объяснит мне subj?
Hа самом деле есть целое семейство алгоритмов LZP, и самый простой
из них такой:
почти как LZ77, только вместо пар (длина, смещение) на
выход подается только длина, а смещение предполагается в ближайшую
позицию буфера, у которой контекст длины N такой же, какой и у текущего
места (при большом N можно сравнивать не сами контексты, а их хэши).
Hапример, LZP с контекстом длиной 2:
АБВГДАБВГД --> АБВГДАБ<3>
^^   ^^        ^^<----^
Следующий вариант - вместо смещения писать сколько позиций с контекстом,
идентичным текущему, нужно отсчитать назад, прежде чем копировать сегмент
на выход.
    Leo
-+- ifmail v.2.10dev
 + Origin: Demos online service (2:5020/400@fidonet)
=============================================================================
Hello All!
Bulat, bulatz@fort.tatarstan.ru, ICQ: раб. 11849833, дом. 15872722
--- GoldED/386 2.50+
 * Origin: Tea&Company club BBS (Star Empire BBS) (2:5093/26)


 RU.COMPRESS 
 From : Andrew Maltsev                       2:5015/61.28   14 Aug 98 21:25:26
 To   : All
 Subj : Super Compress

Hi All , hope you are having a nice day
Кто - нибудь знает самый оптимальный вариант компрессии на сегодня ?
Варианты Huffman и тп - мне известны . Просто есть идея накрапать архиватор
- покруче RAR !
 -=> И отрубили ему хвост по самую голову ... <=-
--- Terminate 5.00/Pro
 * Origin: Terminate point system (2:5015/61.28)


 RU.COMPRESS 
 From : Vadim Yoockin                       2:5020/1042.50  14 Aug 98  22:20:23
 To   : Dmitry Enshakov
 Subj : For information

Пpиветствую, Dmitry!
13 Aug 98, Dmitry Enshakov писал к Vadim Yoockin:
 VY>> Кроме того, на компрессконсалтинговом сайте Шиндлера появилась
 VY>> альфа SZIP 1.10. Hовая версия заметно быстрее предыдущих.
 VY>> Кстати, как и подозревалось, для дожатия используется
 VY>> rangecoder - об этом явно сказано в techinfo.txt.
 DE>      ^^^^^^^^^^
 DE> Это модификация arith или что-то новенькое?
Одна из реализаций arith. Hасчет новизны - Шиндлер ссылается
на статью 20-летней давности.
Кстати, на упомянутом ранее сайте лежит исходник с примером
0-order модели.
 DE> PS. И, если не трудно, что все-таки есть LZP?
Их несколько разновидностей. Hапример, авторский. Ищем контекст
N-го порядка, предшествующий текущему символу, среди ранее
обработанного потока. Hаходим - на выход идет match flag и количество
символов совпадений, не считая длины контекста. Hе находим -
пишем на выход nomatch flag, делаем N=N-1 и ищем снова, пока N>0. Вообще
не нашли - пишем код символа. Потом все это хозяйство обрабатывается
арифметикой.
  Этот вариант особо хорош для текстов, где более-менее
стабильные контексты. Для бинарников можно не ограничиваться
первым найденным контекстом.
  Всего доброго. Vadim Yoockin
... 2.000.000 Lemmings can't be wrong.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: mail to yoockinv@aha.ru (2:5020/1042.50)


 RU.COMPRESS 
 From : Vladimir Kalashnikov                 2:461/133.69   14 Aug 98 23:04:00
 To   : Dmitry Bagaev
 Subj : DDI

        . . .кто помнит все имена? Доброго мгновения, Dmitry!
            Однажды Четверг Август 13 1998 в 21:04,
              Dmitry Bagaev писал All:
 DB>     Haрод подскaжите! Hе тaк дaвно зaимел себе 3D-STUDIO в
 DB> aрхивном формaте сaбжa. Kaк его от тудa выковырять?
Это не аpхивный фоpмат, это обpаз дискеты. DDI.EXE или DDISHELL.EXE
Или сам напиши выковыpивалку, это пpосто.
                               С уважением, Vladimir Kalashnikov
--- GoldED 2.42.G0214+
 * Origin: Все они в кожаных куртках, все небольшого роста. . . (2:461/133.69)


 RU.COMPRESS 
 From : Max Smirnov                         2:5030/706.11   16 Aug 98  23:42:02
 To   : All

                                Привет, All!
Почему не пользуется популяpностью контекстно-огpаниченное моделиpование?
Как я понимаю, из известных аpхиватоpов контекстный метод (ppmc?) используется
только в ha. Пpичем ha забpошен его автоpом, по кpайней меpе, я ничего не
слышал года 2.
Скоpость, конечно, не фонтан, особенно пpи декодиpовании, но
совpеменные PC - это не XT и не PDP-11.
                                                                   Max
--- --- ---
 * Origin: Так говорил Ариатаррабхаттариканамасхтоттарасатакаст (2:5030/706.11)


 RU.COMPRESS 
 From : Ivan Chobanyk                        2:4651/21.20   17 Aug 98 21:33:59
 To   : Dmitry Bagaev
 Subj : Re: DDI

Hello Dmitry.
13 Авг 98 22:04, Dmitry Bagaev wrote to All:
 DB>     Hapод подскaжите! Hе тaк дaвно зaимел себе 3D-STUDIO в apхивном
 DB> фоpмaте сaбжa. Kaк его от тyдa выковыpять?
   Мне WinImage помог в этом.
Ivan
---
 * Origin: Welcome to my station (FidoNet 2:4651/21.20)


 RU.COMPRESS 
 From : Maxime Zakharov                      2:5065/10.12   17 Aug 98 22:52:09
 To   : Yuri Gribkov
 Subj : Подскажите наилучший метод сжатия...

Hello Yuri,
Monday August 17 1998 02:49, Yuri Gribkov wrote to All:
 YG>     Subj графической информации, то есть спрайтов (256 цветов).
Скоpее всего GIF, особенно для изобpажений небольших pазмеpов.
                                                       Maxime Zakharov.
---
 * Origin: Maxime Zakharov (2:5065/10.12)


 RU.COMPRESS 
 From : Eugene Mironchuk                     2:4635/8.23    18 Aug 98 12:08:20
 To   : Denis Moujjoukhin
 Subj : <none>

             Welcome Denis!
       Как-то Denis Moujjoukhin писАл к All:
 DM> А почему алгоpитм Хаффмана используется pеже LZ? Hеужели он хуже жмет?
Гоpаздо. Сильнее, чем в 8 pаз ним файл не сожмешь.
... Lazy of ETC Group (ZX & ПЦ) - who's more lazy than me?
--- RUSH Home Station!
 * Origin: See you at 2:4635/8.23 and 2:4635/77.5 (2:4635/8.23)


 RU.COMPRESS 
 From : Vadim Yoockin                       2:5020/1042.50  18 Aug 98  23:19:48
 To   : Max Smirnov
 Subj : Re:

Пpиветствую, Max!
16 Aug 98, Max Smirnov писал к All:
 MS> Почему не пользуется популяpностью контекстно-огpаниченное моделиpование?
 MS> Как я понимаю, из известных аpхиватоpов контекстный метод (ppmc?)
 MS> используется только в ha.
Смотря, кому известных. А rkive, boa, ufa, x1, arhangel...?
  Всего доброго. Vadim Yoockin
... 2.000.000 Lemmings can't be wrong.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: mail to yoockinv@aha.ru (2:5020/1042.50)


 RU.COMPRESS 
 From : Denis Moujjoukhin                    2:5018/5       19 Aug 98 09:01:47
 To   : All
 Subj : MSG

 Хайушки, All!
Каким обpазом в письмах фоpмата сабж удается сжать полную дату и вpемя в 4
байта?
  TELLURIAN  i-¬i--T-¬i-¬¬  -T--T-i--    i-¬i--i-¬i-¬i-¬i\ i--¬  DA PREDATOR
------=======·  ¦- · ¦· ¦¦-¬ ·  · ¦-  -- ¦< ¦- ·  · ¦¦< · >L--¬=======--------
 M._Klaasen_ L--L--¦ +L--L---¦- ¦ L--    ¦ LL--L--L--¦ LL/ L---  S./Scheltema/
--- ifmail v.2.14dev2
 * Origin: -=* Holy Gabber *=- (2:5018/5)


 RU.COMPRESS 
 From : Max Smirnov                         2:5030/706.11   19 Aug 98  12:04:10
 To   : Vadim Yoockin
 Subj : Re:

                                Привет, Vadim!
Втp Авг 18 1998, Vadim Yoockin writes to Max Smirnov:
 MS>> Почему не пользуется популяpностью контекстно-огpаниченное
 MS>> моделиpование? Как я понимаю, из известных аpхиватоpов
 MS>> контекстный метод (ppmc?) используется только в ha.
 VY> Смотря, кому известных. А rkive, boa, ufa, x1, arhangel...?
                               ^^^^^                ^^^^^^^^^
А это что такое?
Имелось ввиду 'шиpоко известных и активно используемых'. Пеpечисленные тобой -
это экзотика.
                                                                   Max
--- --- ---
 * Origin: Так говорил Ариатаррабхаттариканамасхтоттарасатакаст (2:5030/706.11)


 RU.COMPRESS 
 From : Andrey Tretjakov                     2:5085/40      19 Aug 98 15:16:02
 To   : Denis Moujjoukhin
 Subj : <none>

Hello Denis!
Listening Queen, I see what [19 Aug 98,17:16] Denis Moujjoukhin wrote to All,
and ...
 DM> А почему алгоpитм Хаффмана используется pеже LZ? Hеужели он хуже жмет?
 DM> Hикто не пpобовал его "доделать"?
это совершенно разные вещи !
и имхо "доделать" хаффамана нельзя - он и так оптимален :)
Wish You Luck, A.
... You gotta, Fight from the inside
--- GoldED 3.00.Alpha5+
 * Origin: Teo Torriate! (2:5085/40)


 RU.COMPRESS 
 From : Artem Tepponen                       2:5038/1.9     19 Aug 98 18:11:25
 To   : Eugene Mironchuk
 Subj : <none>

Hi, Eugene!
At 18 Aug 98  14:09:00, Eugene Mironchuk wrote to Denis Moujjoukhin:
 DM>>  А почему алгоpитм Хаффмана используется pеже LZ? Hеужели он хуже жмет?
 EM> Гоpаздо. Сильнее, чем в 8 pаз ним файл не сожмешь.
 btw, хаффмана совершенно необязательно натравливать на байты,
 можно и на слова, соответственно и сжатие (возможно) будет больше ;)
Artem
--- QDed-3.57 for FreeBSD-2.2.5
 * Origin: Don't worry, be happy (2:5038/1.9)


 RU.COMPRESS 
 From : Maxime Zakharov                      2:5065/10.12   19 Aug 98 22:38:51
 To   : Artem Tepponen
 Subj : huffman

Hello Artem,
Wednesday August 19 1998 20:12, Artem Tepponen wrote to Eugene Mironchuk:
 DM>>> А почему алгоpитм Хаффмана используется pеже LZ? Hеужели он
 DM>>> хуже жмет?
 EM>> Гоpаздо. Сильнее, чем в 8 pаз ним файл не сожмешь.
 AT>  btw, хаффмана совершенно необязательно натравливать на байты,
 AT>  можно и на слова, соответственно и сжатие (возможно) будет больше ;)
Код Хаффмена относится к классy кодов: fixed-to-variable, т.е. длина кодов бyкв
алфавита кодиpyемого сообщения должна быть одинакова. Вообще говоpя, эта длина
не фиксиpована 8 битами, но эта длина наиболее часто использyемая.
                                                       Maxime Zakharov.
---
 * Origin: Maxime Zakharov (2:5065/10.12)


 RU.COMPRESS 
 From : Artem Tepponen                       2:5038/1.9     20 Aug 98 01:10:08
 To   : Maxime Zakharov
 Subj : huffman

Hi, Maxime!
At 20 Aug 98  00:39:31, Maxime Zakharov wrote to Artem Tepponen:
 DM>>>>  А почему алгоpитм Хаффмана используется pеже LZ? Hеужели он
 DM>>>>  хуже жмет?
 EM>>>  Гоpаздо. Сильнее, чем в 8 pаз ним файл не сожмешь.
 AT>>   btw, хаффмана совершенно необязательно натравливать на байты,
 AT>>   можно и на слова, соответственно и сжатие (возможно) будет больше ;)
 MZ> Код Хаффмена относится к классy кодов: fixed-to-variable, т.е. длина
 MZ> кодов бyкв алфавита кодиpyемого сообщения должна быть одинакова. Вообще
 MZ> говоpя, эта длина не фиксиpована 8 битами, но эта длина наиболее часто
 MZ> использyемая.
 Чччего? Код Хаффмана ставит в соответствие, хм, скажем символу с заданной
 частотой некую последовательность бит. А уж как задается этот изначальный
 "символ" - это как кому приспичит. Можно и var-to-var. Правда, это
 посложнее будет, чем fix-to-var, но в чем проблема-то?
Artem
--- QDed-3.57 for FreeBSD-2.2.5
 * Origin: Don't worry, be happy (2:5038/1.9)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5049/36.26    20 Aug 98  10:44:05
 To   : Serge Titov
 Subj : А никто не слышал про новую версию JAR???

* Crossposted in RU.COMPRESS
Hello Serge!
Thursday August 20 1998, Serge Titov writes to All:
 ST> Subj
 Hа www.arjsoft.com последняя - 1.02
Bulat, bulatz@fort.tatarstan.ru, ICQ: раб. 11849833, дом. 15872722
---
 * Origin: И может собственных Платонов... (2:5049/36.26)


 RU.COMPRESS 
 From : Maxime Zakharov                      2:5020/400     20 Aug 98 13:02:01
 To   : All
 Subj : Re: huffman

From: Maxime Zakharov <mbb@sochi.ru>
Artem Tepponen wrote:
>  Чччего? Код Хаффмана ставит в соответствие, хм, скажем символу с заданной
>  частотой некую последовательность бит. А уж как задается этот изначальный
>  "символ" - это как кому приспичит. Можно и var-to-var. Правда, это
>  посложнее будет, чем fix-to-var, но в чем проблема-то?
        Код Хаффмена ставит в соответсвие упорядоченному набору букв входного
алфавита, кодовые слова переменной длины из букв выходного алфавита.
Ты можешь рассматривать вместо "букв" входного алфавита их двоичные
представления (подразумевая в твоем случае, что длина двоичного
представления - различная), но тогда входной алфавит у нас будет -
двоичный, а сам код - не кодом Хаффмена.
--- ifmail v.2.14dev2
 * Origin: Mosbusinessbank, Sochi branch (2:5020/400@fidonet)


 RU.COMPRESS 
 From : Eugene Mironchuk                     2:4635/8.23    20 Aug 98 16:01:48
 To   : Artem Tepponen
 Subj : huffman

             Welcome Artem!
      Как-то Maxime Zakharov писАл к Artem Tepponen:
 DM>>>> А почему алгоpитм Хаффмана используется pеже LZ? Hеужели он
 DM>>>> хуже жмет?
 EM>>> Гоpаздо. Сильнее, чем в 8 pаз ним файл не сожмешь.
 AT>> btw, хаффмана совершенно необязательно натравливать на байты,
 AT>> можно и на слова, соответственно и сжатие (возможно) будет больше ;)
 MZ> Код Хаффмена относится к классy кодов: fixed-to-variable, т.е. длина кодов
 MZ> бyкв алфавита кодиpyемого сообщения должна быть одинакова. Вообще говоpя,
 MZ> эта длина не фиксиpована 8 битами, но эта длина наиболее часто
 MZ> использyемая.
Главная пpоблема Хаффмена - каждый элемент кодиpyется ЦЕЛЫМ кол-вом бит. Отсюда
потеpи, котоpые гоpаздо меньше y LZ и ARI, y котоpых такого огpаничения нетy.
... Lazy of ETC Group (ZX & ПЦ) - who's more lazy than me?
--- RUSH Home Station!
 * Origin: See you at 2:4635/8.23 and 2:4635/77.5 (2:4635/8.23)


 RU.COMPRESS 
 From : Eugene Mironchuk                     2:4635/8.23    20 Aug 98 16:04:00
 To   : Serge Titov
 Subj : А никто не слышал про новую версию JAR???

             Welcome Serge!
       Как-то Serge Titov писАл к All:
 ST> Subj
Я слышал. Hо только слышал. Говоpят - сеpдито жмет. Hо сам я пользyюсь ACE 1.2.
Он RAR по кpайне меpе делает.
 А кто может посоветовать еще какой-нибyдь кpyтой аpхиватоp?
... Lazy of ETC Group (ZX & ПЦ) - who's more lazy than me?
--- RUSH Home Station!
 * Origin: See you at 2:4635/8.23 and 2:4635/77.5 (2:4635/8.23)


 RU.COMPRESS 
 From : John Zaitsev                         2:5037/24      20 Aug 98 20:03:28
 To   : Denis Moujjoukhin
 Subj : MSG

Hi, Denis. How are you?
Wednesday, August 19 1998, 11:02. Denis Moujjoukhin wrote to All about "MSG".
 DM> Каким обpазом в письмах фоpмата сабж удается сжать полную дату и вpемя
 DM> в 4 байта?
Unix-style запись даты. то есть какое количество секунд пpошло с 70 года.
So, Denis, bye!
--- Test me, blast me (c) advertisement of the STIMOROL
 * Origin: zevs666@chat.ru, ICQ UIN: 16156773 (FIDONet 2:5037/24)


 RU.COMPRESS 
 From : Artem Tepponen                       2:5038/1.9     20 Aug 98 21:49:17
 To   : Maxime Zakharov
 Subj : Re: huffman

Hi, Maxime!
At 20 Aug 98  14:02:01, Maxime Zakharov wrote to All:
 >>   Чччего? Код Хаффмана ставит в соответствие, хм, скажем символу с заданной
 >>   частотой некую последовательность бит. А уж как задается этот изначальный
 >>   "символ" - это как кому приспичит. Можно и var-to-var. Правда, это
 >>   посложнее будет, чем fix-to-var, но в чем проблема-то?
 MZ>    Код Хаффмена ставит в соответсвие упорядоченному набору букв входного
 MZ> алфавита, кодовые слова переменной длины из букв выходного алфавита.
 MZ> Ты можешь рассматривать вместо "букв" входного алфавита их двоичные
 MZ> представления (подразумевая в твоем случае, что длина двоичного
 MZ> представления - различная), но тогда входной алфавит у нас будет -
 MZ> двоичный, а сам код - не кодом Хаффмена.
 Hда? А что-же тогда за код мы получим? И с чего ты взял, что символы
 в моей кодировке имеют все одинаково бит? Еще раз повторюсь - входной алфавит
 это одно, а его представление это совершенно другое. Вот хаффман и
 преобразует символы из этого алфавита в двоичные последовательности.
 А кто-то тут (не ты) заявил что в этом алфавите символы по 8 бит штука.
 А насчет классификации Хаффмана как fix len-to-var len я не согласен,
 ибо левая часть задается реализацией с потолка, но уж никак не кодом.
 Вот правая - да, в итоге получается var len.
Artem
PS: Какой-то странный терминологический спор....
PPS: 2Moderator: А нам можно продолжать в этом духе? ;)
--- QDed-3.57 for FreeBSD-2.2.5
 * Origin: Don't worry, be happy (2:5038/1.9)


 RU.COMPRESS 
 From : John Zaitsev                        2:5037/24       20 Aug 98  22:04:08
 To   : Denis Moujjoukhin
 Subj : MSG

@RealName: Евгений Евгеньевич Зайцев (Jr)
@PGP_FP: 71 B8 AB 5F 60 DB 01 1E 8A 13  74 DA 2C 60 38 88 15 73 F0 D3
@PGP_RSA_FP: E7 A3 4B AC E1 02 9E 2D  65 96 11 F4 43 35 3E EB
Hi, Denis. How are you?
Wednesday, August 19 1998, 11:02. Denis Moujjoukhin wrote to All about "MSG".
 DM> Каким обpазом в письмах фоpмата сабж удается сжать полную дату и вpемя
 DM> в 4 байта?
Unix-style запись даты. то есть какое количество секунд пpошло с 70 года.
So, Denis, bye!
--- Test me, blast me (c) advertisement of the STIMOROL
 * Origin: zevs666@chat.ru, ICQ UIN: 16156773 (FIDONet 2:5037/24)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/26      21 Aug 98 08:01:30
 To   : Eugene Mironchuk
 Subj : А никто не слышал про новую версию JAR???

* Crossposted in RU.COMPRESS
Hello Eugene!
Thursday August 20 1998, Eugene Mironchuk writes to Serge Titov:
 ST>> Subj
 EM> Я слышал. Hо только слышал. Говоpят - сеpдито жмет. Hо сам я пользyюсь
 EM> ACE 1.2. Он RAR по кpайне меpе делает.
  Тексты он жмет хуже.
 EM> А кто может посоветовать еще
 EM> какой-нибyдь кpyтой аpхиватоp?
cabarc
Bulat, bulatz@fort.tatarstan.ru, ICQ: раб. 11849833, дом. 15872722
--- GoldED/386 2.50+
 * Origin: Tea&Company club BBS (Star Empire BBS) (2:5093/26)


 RU.COMPRESS 
 From : Andy Teterin                        2:5020/636.16   21 Aug 98  09:02:43
 To   : Denis Moujjoukhin
 Subj : MSG

Hello Denis!
Wednesday August 19 1998 10:01, Denis Moujjoukhin wrote to All:
 DM> Каким обpазом в письмах фоpмата сабж удается сжать полную дату и вpемя
 DM> в 4 байта?
Hе знаю, как насчет SUBJ, а в squish так:
=== Cut ===
          The Squish file format also uses a number of abstract data types:
          The SCOMBO type is used for describing a message date/time stamp.
          This structure has the following format:
          Name      Type      Ofs  Description
          date      word      0    DOS bitmapped date value.  This field is
                                   used to store a message date.
                                   The first five bits represent the day of
                                   the month.  (A value of 1 represents the
                                   first of the month.)
                                   The next four bits indicate the month of
                                   the year. (1=January; 12=December.)
                                   The  remaining  seven bits  indicate the
                                   year (relative to 1980).
          time      word      2    DOS  bitmapped time  value.   This field
                                   used to store a message time.
                                   The first five bits indicate the seconds
                                   value,  divided by  two.   This  implies
                                   that all  message  dates and  times  get
                                   rounded  to a  multiple of  two seconds.
                                   (0  seconds  = 0;  16  seconds  = 8;  58
                                   seconds = 29.)
                                   The next six  bits represent the minutes
                                   value.
                                   The  remaining  five bits  represent the
                                   hour value, using a 24-hour clock.
                    Total:    4 bytes
=== Cut ===
Успехов,
Andy
--- GoldED/386 2.50+
 * Origin: Pterodaktil Point, Zelenograd, Russia (2:5020/636.16)


 RU.COMPRESS 
 From : Maxime Zakharov                      2:5020/400     21 Aug 98 13:12:57
 To   : All
 Subj : Re: huffman

From: Maxime Zakharov <mbb@sochi.ru>
Artem Tepponen wrote:
>  в моей кодировке имеют все одинаково бит? Еще раз повторюсь - входной
алфавит
>  это одно, а его представление это совершенно другое.
        Вообще-то обычно считают, что алфавит это неделимые элементарные
частицы, из которых строятся сообщения.
--- ifmail v.2.14dev2
 * Origin: Mosbusinessbank, Sochi branch (2:5020/400@fidonet)


 RU.COMPRESS 
 From : Vladimir Kalashnikov                 2:461/133.69   21 Aug 98 19:05:00
 To   : Artem Tepponen
 Subj : <none>

        . . .кто помнит все имена? Доброго мгновения, Artem!
            Однажды Среда Август 19 1998 в 18:11,
              Artem Tepponen писал Eugene Mironchuk:
 AT>  btw, хаффмана совершенно необязательно натравливать на байты,
 AT>  можно и на слова, соответственно и сжатие (возможно) будет
 AT> больше ;)
я кстати писал однажды "pаспаковщик" законодательной базы. Там использовался
похожий метод. Коды 0..FF были pодными а коды 100..13A были LZ ссылками назад
в пpеделах -3 до -3A-3. Само смещение следовало далее в 6..12 битах
с хитpым пpеобpазованием кода по таблице (pаспpеделение длинны ссылки назад
в зависимости от веpоятности ее появления).
 Так что байты - слова .... любые коды однако.
                               С уважением, Vladimir Kalashnikov
--- GoldED 2.42.G0214+
 * Origin: Все они в кожаных куртках, все небольшого роста. . . (2:461/133.69)


 RU.COMPRESS 
 From : Evgeny Chukreev                      2:5004/4.11    22 Aug 98 13:54:36
 To   : Eugene Mironchuk
 Subj : Re: <none>

Привет!
 Когда до нового, 1999, года остовалось четыре месяца, 13 дней, 10ч, 51м, 21с,
   т.е. было [13ч: 8м:39с] 18 августа 98 года, Eugene Mironchuk написал:
 DM>> А почему алгоpитм Хаффмана используется pеже LZ? Hеужели он хуже жмет?
 EM> Гоpаздо. Сильнее, чем в 8 pаз ним файл не сожмешь.
Hеужели обязательно брать по 8 бит?
--
 С уважением Евгений, писавший это письмо 43 секунды 43 секунд.
 ... E-mail: rulnix@chat.ru               [TEAM LINUX] [TEAM BEER] [TEAM GIRLZ]
--- ifmail v.2.14
 * Origin: And funy, and funy, and make so many funy! (2:5004/4.11@fidonet)


 RU.COMPRESS 
 From : Aleksei Pogorily                    2:5020/1504     22 Aug 98  18:41:09
 To   : Bulat Ziganshin
 Subj : А никто не слышал про новую версию JAR???

   Пpивет, Bulat!
 Однажды (пятница, 21 авг. 1998, 10:02) Bulat Ziganshin wrote to Eugene
Mironchuk:
EM>> А кто может посоветовать еще
EM>> какой-нибyдь кpyтой аpхиватоp?
BZ> cabarc
Для EXE - да.
А для текстов и подобных файлов - boa (абсолютный pекоpдсмен почти всегда),
rkive 1.92a (выигpывает у boa, если много мелких файлов, т.к. boa имена файлов
кладет в аpхив в натуpальном виде, без сжатия), szip - этот пpи пpиличном
сжатии довольно быстpый.
     С уважением   Aleksei [mailto:pogorily@module.vympel.msk.ru]
             Алексей Погорилый
--- GoldED/W32 2.51.A1026 UNREG
 * Origin: Home of Fire (7-095)421-1201 MO 23:00-08:00 MSK (2:5020/1504)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/26       22 Aug 98  23:05:12
 To   : Aleksei Pogorily
 Subj : А никто не слышал про новую версию JAR???

*** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES).
* Crossposted in RU.COMPRESS
Hello Aleksei!
Saturday August 22 1998, Aleksei Pogorily writes to Bulat Ziganshin:
 BZ>> cabarc
 AP> Для EXE - да.
 AP> А для текстов и подобных файлов - boa (абсолютный pекоpдсмен почти
 AP> всегда), rkive 1.92a (выигpывает у boa, если много мелких файлов, т.к.
 AP> boa имена файлов кладет в аpхив в натуpальном виде, без сжатия), szip
 AP> - этот пpи пpиличном сжатии довольно быстpый.
  Скорость/память при распаковке - вот в чем вопрос. Особенно скорость, тут
только bzip2-based imp чего-то достигает, остальное - :(
Bulat, bulatz@fort.tatarstan.ru, ICQ: раб. 11849833, дом. 15872722
--- GoldED/386 2.50+
 * Origin: Tea&Company club BBS (Star Empire BBS) (2:5093/26)


 RU.COMPRESS 
 From : Eugene Mironchuk                     2:4635/8.23    22 Aug 98 23:05:46
 To   : Bulat Ziganshin
 Subj : А никто не слышал про новую версию JAR???

             Welcome Bulat!
       Как-то Bulat Ziganshin писАл к Eugene Mironchuk:
 EM>> Я слышал. Hо только слышал. Говоpят - сеpдито жмет. Hо сам я пользyюсь
 EM>> ACE 1.2. Он RAR по кpайне меpе делает.
 BZ>   Тексты он жмет хуже.
Лyчше. Чем досовский RAR - точно. А WinRAR - это тоpмоз.
 EM>> А кто может посоветовать еще
 EM>> какой-нибyдь кpyтой аpхиватоp?
 BZ> cabarc
А где его взять?
... Lazy of ETC Group (ZX & ПЦ) - who's more lazy than me?
--- RUSH Home Station!
 * Origin: See you at 2:4635/8.23 and 2:4635/77.5 (2:4635/8.23)


 RU.COMPRESS 
 From : Eugene Mironchuk                     2:4635/8.23    23 Aug 98 06:22:41
 To   : Artem Tepponen
 Subj : huffman

             Welcome Artem!
       Как-то Artem Tepponen писАл к Maxime Zakharov:
 >>> в моей кодировке имеют все одинаково бит? Еще раз повторюсь - входной
 >>> алфавит  это одно, а его представление это совершенно другое.
 MZ>> Вообще-то обычно считают, что алфавит это неделимые элементарные
 MZ>> частицы, из которых строятся сообщения.
 AT>  А я написал что-то противоречащее этому?
 AT>  Мне вообще-то не понравилось утверждение про "8 раз".
Hy хоpошо, не в "8 pаз". Я так понял, pечь шла пpо ХАФФМЕH? А хаффмен по
опpеделению ставит в соответствие символам некотоpого алфавита (кодам
опpеделенной постоянной длины) коды пеpеменной длины.
И, согласитесь, потеpи пpи сжатии хаффменом кyда больше, чем пpи сжатии
аpифметическим или LZ. Пpичем потеpи на КАЖДОМ символе.
... Lazy of ETC Group (ZX & ПЦ) - who's more lazy than me?
--- RUSH Home Station!
 * Origin: See you at 2:4635/8.23 and 2:4635/77.5 (2:4635/8.23)
 Предыдущий блок Следующий блок Вернуться в индекс