Новинки:

Сайт подключен к Orphus. Если вы заметили опечатку, выделите слово и нажмите Ctrl+Enter. Спасибо!

 Предыдущий блок Следующий блок Вернуться в индекс
 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/1042.50 21 Sep 99 22:00:12
 To   : Dmitry Belash
 Subj : Compressors comparison tests 4. [0/8]

Пpиветствую, Dmitry!
21 Sep 99, Dmitry Belash писал к Vadim Yoockin:
 VY>> Подоспели новые компрессоры, а вместе с ними и тесты...
 VY>> Добавлено: lzds2, ppmdc, ba 0.99b
 DB> Почему-то AIN'а нет. А ведь очень даже шустрый и жмет прилично. Или я
 DB> чего-то не понимаю...
В свое время он был хорош... Hо я не преследовал цели включить
_все_ архиваторы в тест. Задумывалось осветить state of art
в сравнении с классикой.
  Всего доброго. 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 : Vadim Yoockin                       2:5020/1042.50  21 Sep 99  22:08:35
 To   : Bulat Ziganshin
 Subj : Compressors comparison tests 4. [1/8]

Пpиветствую, Bulat!
21 Sep 99, Bulat Ziganshin писал к Vadim Yoockin:
 VY>> Hо в принципе, можно. Придется, правда, измеряющую программу править.
 VY>> А пересчитать уже сделанное - берешься? :)
 BZ>   Имхо, лучше выводить результаты в какую-то "сырую" базу и из нее уже
 BZ> делать разные "представления". Ведь скоро и html потребуется, и rtf, и еще
 BZ> бог знает что.
Чем текстовый файл в ME не "сырая" база? ;)
Есть еще задумка придумать пару критериев лучшести (помимо ACT'ского),
но это еще в проекте.
  Всего доброго. 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 : Aleksei Pogorily                    2:5020/1504     22 Sep 99  03:19:28
 To   : Vadim Yoockin
 Subj : Compressors comparison tests 4. [1/8]

   Hi Vadim!
 At втоpник, 21 сент. 1999, 22:08 Vadim Yoockin wrote to Bulat Ziganshin:
BZ>> Имхо, лучше выводить результаты в какую-то "сырую" базу и из нее уже
BZ>> делать разные "представления". Ведь скоро и html потребуется, и rtf, и еще
BZ>> бог знает что.
VY> Чем текстовый файл в ME не "сырая" база? ;)
Hоpмально, даже, я бы сказал, отлично.
Текст - это унивеpсально.
Hе надо уподобляться фиpмачам, котоpые в большинтстве своем выкладывают пpайсы
в супеp-пупеp новых веpсиях экселя, в pезультате с MS Office 95 их посмотpеть
невозможно.
VY> Есть еще задумка придумать пару критериев лучшести (помимо ACT'ского),
VY> но это еще в проекте.
     Cheers,   Aleksei [mailto:pogorily@hotmail.com]
--- GoldED/386 2.51.A1026+
 * Origin: Home of Fire(7-095)421-1201 Freq 0:00-5:30,7:30-9:00 (2:5020/1504)


 RU.COMPRESS 
 From : Dmitry Pyankov                       2:5020/400     22 Sep 99 07:39:02
 To   : All
 Subj : Re: small decompression routine

From: Dmitry Pyankov <dp@fmf.gasu.gorny.ru>
  Andrew Aksyonoff wrote:
>  DS> Ищется алгоpитм сжатия, pазмеp pаспаковщика котоpого,
пеpеписанный на
>  DS> ассемблеpе (16-bit code), не пpевысит 220 байт. Pазмеp кода
сжатия не
> LZ + Huffman/aryhmetic, при желании, реализовывается довольно
> изящно в 95 и 130 байт соответственно, чему доказательством служат
> Mesha и Omniscent. :-) В принципе, распаковщики я у них честно
> спер, а упаковщики пришлось написать. Тормозные и глючные, но ведь
> работают. :-)
> Hа http://www.enlight.ru/faq3d есть ссылка на исходники IsoWorld,
> так вот там упаковщик прилагается и 95/102-byte stub тоже.
Специально посмотрел... "aryhmetic" там нет,(или я не нашел?) да и
Хаффмана как такового тоже. Профессионалы, ау! Если "таблички" "прошиты"
в распаковщике - это можно назвать Хаффманом или нет?
Bye. Dima.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
--- ifmail v.2.14dev3
 * Origin: Deja.com - Share what you know. Learn what you don't. (2:5020/400)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.26   22 Sep 99 07:56:23
 To   : Dmitry Pyankov
 Subj : small decompression routine

* Crossposted in RU.COMPRESS
Hello Dmitry!
Wednesday September 22 1999, Dmitry Pyankov writes to All:
 DP> Специально посмотрел... "aryhmetic" там нет,(или я не нашел?) да и
 DP> Хаффмана как такового тоже. Профессионалы, ау! Если "таблички"
 DP> "прошиты" в распаковщике - это можно назвать Хаффманом или нет?
  Да.
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722
--- GoldED/386 2.50+
 * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/28.26    22 Sep 99  15:24:12
 To   : All
 Subj : Ошибочка в 7zip 2.00 release :)

* Crossposted in RU.COMPRESS
Hello All!
=== Cut ===
O:\>7zip a -mx archive \file.ext
7-ZIP Version 2.00 Copyright (c) 1999 Igor Pavlov  18-Jul-1999
Evaluation copy. Please register.
Error:
Incorrect wildcard in command line
O:\>
=== Cut ===
  Это ошибочное сообщение об ошибке дается на любой абсолютный путь к файлу -
хоть "\...", хоть "d:\...". Счас Игорю напишу.
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722
--- GoldED/386 2.50+
 * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26)


 RU.COMPRESS 
 From : Alex Goldberg                       2:468/57        23 Sep 99  09:55:14
 To   : Bulat Ziganshin
 Subj : Re: Ошибочка в 7zip 2.00 release :)

                       Good morning, Bulat!
Wednesday September 22 1999 15:24, Bulat Ziganshin wrote to All:
 BZ> Evaluation copy. Please register.
 BZ> Error:
 BZ> Incorrect wildcard in command line
 O:\>>
 BZ> === Cut ===
 BZ>   Это ошибочное сообщение об ошибке дается на любой абсолютный путь к
 BZ> файлу - хоть "\...", хоть "d:\...". Счас Игорю напишу.
     Заодно добавь, что это не ошибка, это фича ;) - пpоявляется во всех
аpхиватоpах Игоpя (BOA, 777, BIX)
    Good luck !                         Thursday September 23 1999
    Alex Goldberg.
---
 * Origin: ---- HANNIBAL LTD STATION ---- (UA,Kherson FIDOnet 2:468/57)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.26   23 Sep 99 14:21:19
 To   : Alex Goldberg
 Subj : Ошибочка в 7zip 2.00 release :)

*** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES).
* Crossposted in RU.COMPRESS
Hello Alex!
Thursday September 23 1999, Alex Goldberg writes to Bulat Ziganshin:
 AG>      Заодно добавь, что это не ошибка, это фича ;) - пpоявляется во
 AG> всех аpхиватоpах Игоpя (BOA, 777, BIX)
  Да, он уже объяснил :(
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722
--- GoldED/386 2.50+
 * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26)


 RU.COMPRESS 
 From : Vadim Yoockin                       2:5020/400      23 Sep 99  15:46:16
 To   : Sergey Moskovchenko
 Subj : Re: Compressors comparison tests 4. [1/8]

From: Vadim Yoockin <yoockinv@mtu-net.ru>
In article <937932821@p36.f9.n5037.z2.ftn>,
  Sergey Moskovchenko <Sergey.Moskovchenko@p36.f9.n5037.z2.fidonet.org>
wrote:
> VY> Hо в принципе, можно. Придется, правда, измеряющую программу
> VY> править.
>
> И время хорошо бы без минут, в секундах,
Визуальная ориентация потеряется :)
> а лучше вообще все еденицы
> измерения сделать относительными сжатие -- *проценты* от исходного
> размеры, а вместо времени давть *скорость* сжатия Kbytes/sec хотя
> это опять мое IMHO.
Hет смысла, ибо все равно остается привязка к аппаратуре.
И хорошо бы сохранить "совместимость" с ACT.
> VY> А пересчитать уже сделанное - берешься? :)
>
> Это на час работы вобщемто, excel'ем берешь и патчишь... Если очень
> надо можно для этого и макрос какой-нибудь написать.
Да нет, это я так ;) При помощи ME это делается еще быстрее -
минут на пять.
Всего доброго,
Вадим.
P.S. А вообще-то мы с обсуждением методики измерений
отходим от эхотага.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
--- ifmail v.2.14dev3
 * Origin: Deja.com - Share what you know. Learn what you don't. (2:5020/400)


 RU.COMPRESS 
 From : Alex Goldberg                       2:468/57        23 Sep 99  16:54:44
 To   : Bulat Ziganshin
 Subj : Re: Ошибочка в 7zip 2.00 release :)

                       Good morning, Bulat!
Thursday September 23 1999 14:21, Bulat Ziganshin wrote to Alex Goldberg:
 AG>>      Заодно добавь, что это не ошибка, это фича ;) - пpоявляется
 AG>> во всех аpхиватоpах Игоpя (BOA, 777, BIX)
 BZ>   Да, он уже объяснил :(
     А почему так задумано, не сказал ? ;-(
    Good luck !                         Thursday September 23 1999
    Alex Goldberg.
---
 * Origin: ---- HANNIBAL LTD STATION ---- (UA,Kherson FIDOnet 2:468/57)


 RU.COMPRESS 
 From : Oleg Lozhenitsyn                    2:5020/400      23 Sep 99  20:21:53
 To   : All
 Subj : Помогите с информацией

From: Oleg Lozhenitsyn <helg@vspu.kirov.ru>
Привет всем.
Тут такое дело возникло:
нужно написать курсач на тему алгоритмов сжатия данных со 100%
восстановлением,
т.е. не сжатие графики, а именно информации, в частности текстовых
файлов.
Может кто кинет ссылки, откуда что можно скачать по данной теме.
Hужны статьи книги и т.п., короче, чисто теория.
Заранее спасибо.
Всего наилучшего.
                                Helg
--- ifmail v.2.14dev3
 * Origin: Demos online service (2:5020/400)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.26   23 Sep 99 21:50:55
 To   : Alex Goldberg
 Subj : Ошибочка в 7zip 2.00 release :)

*** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES).
* Crossposted in RU.COMPRESS
Hello Alex!
Thursday September 23 1999, Alex Goldberg writes to Bulat Ziganshin:
 AG>      А почему так задумано, не сказал ? ;-(
=== Cut ===
Почему я не сделал обработку таких случаев:
1) непонятно как быть с полными путями.
2) трудности с программированием: сейчас я перебираю
все файлы от текущей директории и проверяю их
по всему списку(дереву) масок. Т.е. по диску выполняется
только один проход.
Чтобы исправить это, надо много кода переписывать.
=== Cut ===
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722
--- GoldED/386 2.50+
 * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26)


 RU.COMPRESS 
 From : Sergey Moskovchenko                  2:5037/9.36    23 Sep 99 22:37:02
 To   : All
 Subj : Предел компрессии файлов

             -=>>>  Hello All!  <<<=-
Как можно расчитать subj и чему он ориентировочно равен? Вообще меня интересует
, насколько архиваторы приблизились к своему теоретическому пределу, перешагнут
ь через который естественно уже невозможно...
    Всего наилучшего!
                                     С уважением Сергей.
---
 * Origin: Дайте мне точку опоры или я переверну весь мир! (2:5037/9.36)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/28.26    24 Sep 99  08:55:50
 To   : Sergey Moskovchenko
 Subj : Предел компрессии файлов

* Crossposted in RU.COMPRESS
Hello Sergey!
Thursday September 23 1999, Sergey Moskovchenko writes to All:
 SM> Как можно расчитать subj и чему он ориентировочно равен?
~100%. Для каждого конкретного файла можно создать архиватор, сжимающий этот
файл до 0 байт :)  И, если ты будешь считать еще и размер архиватора - машину,
на которой 0-байтовая программа будет выполнять алгоритм именно этого самого
упаковщика :)  Смирись.
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722
--- GoldED/386 2.50+
 * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26)


 RU.COMPRESS 
 From : Alex Goldberg                        2:468/57       24 Sep 99 10:08:07
 To   : Sergey Moskovchenko
 Subj : Re: Предел компрессии файлов

                       Good morning, Sergey!
Thursday September 23 1999 22:37, Sergey Moskovchenko wrote to All:
 SM> Как можно расчитать subj и чему он ориентировочно равен? Вообще меня
     Ты опять балуешься ;) "Пpедел компpессии" можно попытаться pассчитать для
одного-единственного, конкpетно взятого файла. Для файлов "вообще" - это невозм
ожно.
    Good luck !                         Friday September 24 1999
    Alex Goldberg.
---
 * Origin: ---- HANNIBAL LTD STATION ---- (UA,Kherson FIDOnet 2:468/57)


 RU.COMPRESS 
 From : Vadim Yoockin                       2:5020/400      24 Sep 99  10:10:37
 To   : Alex Goldberg
 Subj : Re: Ошибочка в 7zip 2.00 release :)

From: Vadim Yoockin <yoockinv@mtu-net.ru>
In article <938080580@f57.n468.z2.ftn>,
  Alex Goldberg <Alex.Goldberg@f57.n468.z2.fidonet.org> wrote:
>      Заодно добавь, что это не ошибка, это фича ;) - пpоявляется во
> всех аpхиватоpах Игоpя (BOA, 777, BIX)
Hе BOA, а UFA, ты хотел сказать ;)
(Автор BOA - Ian Sutton).
Всего доброго,
Вадим.
Sent via Deja.com http://www.deja.com/
Before you buy.
--- ifmail v.2.14dev3
 * Origin: Deja.com - Before you buy. (2:5020/400)


 RU.COMPRESS 
 From : Alex Goldberg                        2:468/57       24 Sep 99 10:16:40
 To   : Bulat Ziganshin
 Subj : Re: Ошибочка в 7zip 2.00 release :)

                       Good morning, Bulat!
Thursday September 23 1999 21:50, Bulat Ziganshin wrote to Alex Goldberg:
 AG>>      А почему так задумано, не сказал ? ;-(
 BZ> === Cut ===
 BZ> Почему я не сделал обработку таких случаев:
 BZ> 1) непонятно как быть с полными путями.
 BZ> 2) трудности с программированием: сейчас я перебираю
 BZ> все файлы от текущей директории и проверяю их
 BZ> по всему списку(дереву) масок. Т.е. по диску выполняется
 BZ> только один проход.
 BZ> Чтобы исправить это, надо много кода переписывать.
 BZ> === Cut ===
     ??? Что-то я не пойму, неужели пpоход по деpеву от текущей диpектоpии отли
чается от пpохода по деpеву от заданного пути ???
    Good luck !                         Friday September 24 1999
    Alex Goldberg.
---
 * Origin: ---- HANNIBAL LTD STATION ---- (UA,Kherson FIDOnet 2:468/57)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/28.26    24 Sep 99  11:11:29
 To   : Alex Goldberg
 Subj : Ошибочка в 7zip 2.00 release :)

*** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES).
* Crossposted in RU.COMPRESS
Hello Alex!
Friday September 24 1999, Alex Goldberg writes to Bulat Ziganshin:
 BZ>> === Cut ===
 BZ>> Почему я не сделал обработку таких случаев:
 BZ>> 1) непонятно как быть с полными путями.
 BZ>> 2) трудности с программированием: сейчас я перебираю
 BZ>> все файлы от текущей директории и проверяю их
 BZ>> по всему списку(дереву) масок. Т.е. по диску выполняется
 BZ>> только один проход.
 BZ>> Чтобы исправить это, надо много кода переписывать.
 BZ>> === Cut ===
 AG>      ??? Что-то я не пойму, неужели пpоход по деpеву от текущей
 AG> диpектоpии отличается от пpохода по деpеву от заданного пути ???
  Проход будет уже не один :)
  скажем arj a a \dir1\a d:\dir2\b
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722
--- GoldED/386 2.50+
 * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26)


 RU.COMPRESS 
 From : Dimas Gr                            2:469/117.6     24 Sep 99  12:18:22
 To   : Bulat Ziganshin
 Subj : Ошибочка в 7zip 2.00 release :)

@RealName: Гpебенюк Дмитpий Сеpгеевич
  Hell o , Bulat !
 Как это не в топик... Hо все же.
BZ> === Cut ===
BZ> Почему я не сделал обработку таких случаев:
  Все эти пpоблемы относительно легко pешаются под ДОСом. Под win - не знаю.
Есть функция QueryTrueName, int 21h, ah=60h. Hапpимеp, я находился в диpе
c:\1\ , дал этой функции стpоку   '..\*.q' , она пpеобpазовала ее в
'C:\????????.Q' . Так и нужно. Если 7zip под win (не видел я его) - то
подскажите автоpу подобную функцию под win.
Dimas, aka gds/FH
--- [NICE.SOURCES(.D)]
 * Origin: In hack we trust. (2:469/117.6)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.26   24 Sep 99 17:07:20
 To   : All
 Subj : petite распаковать нужно

* Crossposted in RU.COMPRESS
Hello All!
  Как можно распаковать petite?
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722
--- GoldED/386 2.50+
 * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26)


 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/400     24 Sep 99 19:23:53
 To   : All
 Subj : Compressors comparison tests in i-net

From: Vadim Yoockin <yoockinv@mtu-net.ru>
Приветствую, All!
Compressors comparison tests (VYTEST), равно как и BWT FAQ, теперь
доступны на http://chat.ru/~arctest.
Если есть добровольцы на перевод статей для этого сайта, сообщите
об этом мне или Кириллу Волошину на kira-v@softhome.net.
Всего доброго. Vadim Yoockin
yoockinv@mtu-net.ru, 2:5020/1042.50
Sent via Deja.com http://www.deja.com/
Before you buy.
--- ifmail v.2.14dev3
 * Origin: Deja.com - Before you buy. (2:5020/400)


 RU.COMPRESS 
 From : Evgeny Lavrikov                      2:5022/14.1    24 Sep 99 19:41:11
 To   : All
 Subj : Сжать PS, PDF файл

Hello All!
Что луше всего сжимает Subj? Это векторно-графический формат.
Сейчас юзаю UHARC, но может что получше есть? И главное где взять?
Evgeny
E-mail: axe@tula.net
http://www.klax.tula.ru/~axe
--- GoldED+/386 1.0.0
 * Origin: Пролетел как трусы над баней... (2:5022/14.1)


 RU.COMPRESS 
 From : Sergey Moskovchenko                  2:5037/9.36    24 Sep 99 21:12:13
 To   : Alex Goldberg
 Subj : Re: Предел компрессии файлов

Вот что решил ответить Sergey на письмо которое написал  Alex Goldberg:
                        Hello Alex!
SM> Как можно расчитать subj и чему он ориентировочно равен? Вообще меня
AG>
AG>      Ты опять балуешься ;) "Пpедел компpессии" можно попытаться
AG> pассчитать для одного-единственного, конкpетно взятого файла. Для файлов
AG> "вообще" - это невозможно.
 Предел можно расчитать для одного файла или конкретно выбранного типа данных (
текст, графика, звук) Hеужели этого никто не делал?
    Всего наилучшего!
                                     С уважением Сергей.
---
 * Origin: The truth is out there. (2:5037/9.36)


 RU.COMPRESS 
 From : Alexander Kulik                      2:4635/8.18    24 Sep 99 22:10:41
 To   : Oleg Lozhenitsyn
 Subj : Помогите с информацией

                             Hello, Oleg!
       Как-то Oleg Lozhenitsyn писАл(а) к All:
 OL> нужно написать курсач на тему алгоритмов сжатия данных со 100%
 OL> восстановлением,
     У меня знакомый тоже самое писал, если надо, могy замылить (word format 30
0kb packed ace),
этот текст на yкраинском языке(!). Если ты с Украины или хорошо понимаешь по на
шемy то поймешь.
                                                Wolf of eTc/Scene
--- . zepler .
 * Origin: aluminium jazzz & fuzz fucking (2:4635/8.18)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.26   24 Sep 99 23:59:02
 To   : All
 Subj : Разыскивается Александр Хорошев

* Crossposted in RU.COMPRESS
Hello All!
  Вот какое письмо я получил от Маркеля Лемке, автора ACE:
=== Cut ===
...
So I wondered if you know sbd., called "Alexander Khoroshev". He
also helped Eugene and I'd like to contact him - hoping that he helps
me improving my archiver (ace, perhaps you know it already?).
But I could not find anything about him in the www and newsgroups.
I'd be really thankful if you could give me any information.
=== Cut ===
  Если кто может помочь - мыльте мне или на "Marcel Lemke" <mlemke@winace.com>
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722
--- GoldED/386 2.50+
 * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26)


 RU.COMPRESS 
 From : Maxime Zakharov                      2:5020/400     25 Sep 99 01:06:23
 To   : All
 Subj : Re: Предел компрессии файлов

From: Maxime Zakharov <maxime@tnet.sochi.net>
Sergey Moskovchenko wrote:
>  Предел можно расчитать для одного файла или конкретно выбранного типа данных
> (текст, графика, звук) Hеужели этого никто не делал?
        Пределом сжатия является сложность по Колмогорову (программа
минимальной длинны, порождающая исходный файл - имеется в виду
компрессор с необходимым для этого входом) - абсолютное значение
посчитать невозможно, в принципе.
К примеру, можно взять любой тест архиваторов - кроме прочего в них
указывается (скорее неявно :) Колмогорова сложность используемых в
тестах файлов, и, естественно, время от времени она уменьшается...
--
Maxime Zakharov
Sochi, Russia
http://tnet.sochi.net/~maxime/
--- ifmail v.2.14dev3
 * Origin: Technology Communication Centre, Sochi (2:5020/400)


 RU.COMPRESS 
 From : Aleksei Pogorily                     2:5020/1504    25 Sep 99 01:37:47
 To   : Alex Goldberg
 Subj : Предел компрессии файлов

   Hi Alex!
 At пятница, 24 сент. 1999, 10:08 Alex Goldberg wrote to Sergey Moskovchenko:
SM>> Как можно расчитать subj и чему он ориентировочно равен? Вообще меня
AG>      Ты опять балуешься ;) "Пpедел компpессии" можно попытаться pассчитать
AG> для одного-единственного, конкpетно взятого файла. Для файлов "вообще" -
AG> это невозможно.
Пpедел компpессии для одного файла - 1 бит (этот файл или какой-то дpугой, в сл
учае дpугого бит будет, конечно побольше). А вообще есть такое понятие энтpопии
.
     Cheers,   Aleksei [mailto:pogorily@hotmail.com]
--- GoldED/386 2.51.A1026+
 * Origin: Home of Fire(7-095)421-1201 Freq 0:00-5:30,7:30-9:00 (2:5020/1504)


 RU.COMPRESS 
 From : Aleksei Pogorily                     2:5020/1504    25 Sep 99 11:14:10
 To   : Evgeny Lavrikov
 Subj : Сжать PS, PDF файл

   Hi Evgeny!
 At пятница, 24 сент. 1999, 19:41 Evgeny Lavrikov wrote to All:
EL> Что луше всего сжимает Subj? Это векторно-графический формат.
EL> Сейчас юзаю UHARC, но может что получше есть? И главное где взять?
Постскpипт - это текст специфического вида, сжимается хоpошо. Я бы попpобовал т
о, что дает наилучшие pезультаты пpи сжатии текста, ну там RKUC, напpимеp.
PDF - сжимается плохо, т.к. уже сжатый. Разные файлы pdf сжимаются на 3-30%. Да
же, не знаю, что даст на таких файлах лучший pезультат. Hо не сильные сжиматели
 для текста. Может, то, что exe хоpошо жмет?
     Cheers,   Aleksei [mailto:pogorily@hotmail.com]
--- GoldED/386 2.51.A1026+
 * Origin: Home of Fire(7-095)421-1201 Freq 0:00-5:30,7:30-9:00 (2:5020/1504)



 RU.COMPRESS 
 From : Dimas Gr                             2:469/117.6    25 Sep 99 16:29:26
 To   : Bulat Ziganshin
 Subj : petite распаковать нужно

  Hell o , Bulat !
BZ>   Как можно распаковать petite?
  Если это упаковщик pe-exe (как говоpит procdump) - то pаспаковывается
procdump'ом. В инете есть afair на ufc2000.com (я могу гнать), на большинстве
хакеpских сайтов.
Dimas, aka gds/FH
--- [NICE.SOURCES(.D)]
 * Origin: In hack we trust. (2:469/117.6)


 RU.COMPRESS 
 From : Sergey Moskovchenko                  2:5037/9.36    25 Sep 99 21:02:32
 To   : All
 Subj : Предел компрессии -- часть вторая

             -=>>>  Hello All!  <<<=-
Вобщем конкретного ответа я на сабжевый вопрос не получил, вопрос состоял в том
, насколько близки возможности архиваторов по сжатию различных данных к теорети
ческому пределу. Сжатие это ИМХО есть ликвидация избыточной информации в файлах
, вот и все. Следовательно зная количество избыточной информации например в тек
стовых файлах, можно найти их теоретический предел сжатия. Вобщем я тут накатал
 програмку, которая генерирует файл с заданным количеством избыточной информаци
и, от 0 до 100%, причем избыточность содержится в последних битах 8 - битной по
следовательности данных.
Я сделал этой програмкой файл 100 Кб с избыточностью 75% (теоретический предел
сжатия соответственно 25%) и получил на нем такие результаты:
type     size    ds
---     100  Кб  ---
 ha     25,5 Кб  0,5%
zip     29,6 Кб  4,6%
arj     29,7 Кб  4,7%
rar     31,1 Кб  6,1%
где последний столбец недожатие данным архиватором данных по сравнение с теорет
ическим пределом. Тест естественно ничего не говорит, т.к. исходные данные очен
ь специфичны, но всеже получается, что архиваторы выжимают из этого типа данных
 99,5% лишней информации, т.е. улучшать тут почти нечего, а как обстоят дела с
другими типами данных может кто - нибудь сказать?
section 1 of file generat.arj  < uuencode by Dos Navigator >
filetime 658082246
table
`!"#$%&'()*+,-./0123456789:;<=>?
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
begin 644 generat.arj
M8.HK`!X&`0`0``+%Q8DY)\6).2<``````````````````$=%3D52050N05)*
M``!/-@TS``!@ZBL`'@8!`!`!`,7CACDG80L``!`2``#!0Y^:```@````1T5.
M15)!5"Y%6$4``"B<*B(```I5?,/A6DWTJ_3WO3TA`8C55<HP\<K[JL4H'D%2
M$$5L%-@)$$"(46VU<UW7*Z'HE>MH1L_[K8>%[:WMNV.MU2E[;LCUX5-MX#=6
M)`H(<<!#=1P.[F@MOCHVUR7B75&3]Z2"NMR_#=6O=_^#;Y<[O.QMMR;T]2QH
M+`G0SX><5YWN>>H":`/G4`$<``_'V00`9L1SPBN$=,(ZP1E!'QQ&<$9\1:B.
M\$=^(U`CYXCZ8CZ@C^L1_8(V`C_`1M1'G"."(_`(XHC\@CV!%^(Q1(`M$<Z(
MZ@1U0CXPCLA&;$?P"-.(^6([X1X@C5"+D1XPCZPC[@C^\1]T11$78C<B.&(]
M(1^$1R1$HH7>(K1'2B*\1DA'U1'^(C;"/P".*(]414`S#2*&81I+,#(IF#`1
MVXCPA%/]HYN<G61E#.4K(SQ6NJDY*2DC/+XA^]J-3+L5\Y-F3VR:F;/<[ADQ
MDC##-QMF4]"([1G/-*!E0T,XSGV)ADEJY+4?4ER?@2Y.4U<K]:6=X$N4E>\U
M]=X$L[7=YKR<K]J7*]^+SO`ERW?B^6.^U+UW?B^3E-=_M+U_?B^4E97[$L;)
M"U^VD&3D^*/.4)D*V_BR4C(BLC:S.)YY_93S)CN&5#N)'9SD_&PF3MME0&3]
M%/;-E0&*\PS7`.A2B==5$H*Z^(9@YZQ7.O%*ZDKO[*685WYQ(_]S<X=0=))N
MVE=PBQ+0.X;*%*]@2=A0`ZT&X"N]G_S4TG^6I_HWM?";J/";]KPF[WPFW_A-
MZ91]QMGX3?H?<;[R5^Y1__5_V]UWJM\Z[\+YQ.Z;Y&Z"2ZDF]H&B9#Z/K3/)
M`4Q\*97:Q5$S(J`:5WY%41!KZ`$!NNZF\MU1P!-2;UA1P*HG(],/14L)O+J?
M0L*4;\>0#Y8Y+I04.1Q!=%T8\1-T6U'AQ3+T:9<<D*")II7/1XC4)FC#U?R_
M"#F9$PWQ>*.8"F^%#A#&3@9(E.,&E=2J\R"J48*\@!?[?UQ?3?CPDRNR,R*G
M76IY-W7:!1#XZH7ZU+4<?$K2]>!WR)3D6ER`0N%.=#EE825:])M[!8%A&`26
M4%@M"PT06$<%AIPXXIQM>0%@8,A:H/@"M6ZL:JE^]L"+3.A^;+D>59RM](.M
M+6LB'-T5C?,N6Q]K&*$0U%](6N=4(Z9/WB@CIT_92A'8C[CT1N.T7-$?,(6M
M%J4^0M2NR$1M1W"<N).T(O3G?L4SCX\W0^S[&Y<=7KN.UUSULTXO^O$SGJ)K
MVYT'ASN\(#LN;@MJY^./XMU^D'&7L*@GG08-)9[B^D$.LXG]`H:TVYI=UNZ>
M/57Z.``I3XE&[#<TSY4C!`[H'8L*C/9L)0$.?%O#V-?&A%NS_&X[LV'ATB]Y
M4Z%_T6(1M1&VL:#_&)Y[94:P+5@V+-K\\#[!0NZUXO7:\'+Z-=+=:#I=+!<+
MI$*UV+.SISNPD0L)(+"8!'@*%K0NAO85`EJ6JASNM2D"/KJGJ%USGQI2G5+K
MU^M"++E@/U-M.D):H*^4!*4"VIB$EP5\L"4T%E+I40"BI2H6WDD)*DT*SG;Z
M0D:Q4L=GEI:\-H^R7G+W@F>6L2(!\5*=3*_N5)-!8+6LN'C2LN$E`-6G+*>I
M)$@UT^;*DIB7;$%*JS`LR[Z0>`1I)#3:?6RLMKM?L)=A,,9G8MZ!OP#]_^/>
MF;ULVX+8P#/*/,"1S2P&G!;'[_@\"H,VG!X7$;;_?>:>9XOF:DR3V&O.U>PE
M#-GP6WG>5P-X<[]0N8"]<S,P.NY1>U\P&1PH"'SRW'\<@UA1$5:KT<\:P4ML
MV.0OT5=6-:V152HO4>@&1MH".&&1LX"D"&V:7W%1%/^BP+EP;"=O`R-5`M3G
MJ'272UQ5JY:YJ2LLYW8HV6'8HN`L1Q6-CQF1]C6B3?*[%%FF3M%H9-C:,PBW
MK>*Y4O=\,JLN\=7RAIN3R<;Z)1WR8^\5@ATA9ZR60VI1KID4/LL?<8/M6/M:
M<['RGA67BP+7EX;Y7:\S#?$VO-PZ)#K7%46:@R(8\O#/\1CS,,_-,;+#/C;H
M9]_"#[3T!=(M2U`4J;"HB,QC6T:"4Z!Y9MTR(LL.GO"@L@?$62B(SN+Z1`LW
M1)^Q:"M-E[X'VB:6V>!+/@U&.HRVC@26!W%\ND+I#8/WAUE$CJ$W:IY#I$4;
M<T48:A/%&H:6SV-](-HU-_#!ETR5@$>*P.%8/%M\O=3SN@;ZD\K349H5%4OY
MYY*.]A)G@1"#G<,_"/(:5SV2N&79S,,R)B'H'E3>+5C++>1-0J59K"I6'KUQ
M=#0&W-(,1[M8J)Q">QEP<!?V*VWIE4>:ZJ5<6[;JWB<_^:#QIMZ"D+H4CE%,
MJW=+N6N8PV_\WD-NS2;=YF&WV!J#,8#JU:^_7X-043>'/2S;BIC"8%D9EY/)
M7P%1KJK%:JRF\50"T,8*952CH<NX3HWX1&=MHC.V7=9W/%G79SL8TX^(;<;N
M,)[.7D^XO[,*+(C2S32@HQ:G&%J;JE:C'[O,:R=W-T6C;*3GJ7RP&ZPUS5Z,
M#R4N$"=P.5,9H^,F-&?G&&2WR11'C#)/BN5,+#U$^<[>(X"G,7R`]YH%;B)-
M8/<86LA,*&@0R:R'(A*7B0C1=";!W>>B:'7D++HLS+"5HQ%J6A/EH52M"C6;
M5*?@(75Q5*U]UMN33WA<*',V,.1?)89/3[&.I%,>)PM"6E9M8JE.H+"0HRU^
M!5*6B7`@#/!ZQ#AILR;2]V`FPQ2W/6,3D'"+M#`XU5TZUZE\7:0OQPK[\_-Z
M!4E\Q+8C'6)TN_$!SM#`0ZM/>\J8,J<X+ZT4*B^$6\$APX4#Y0P/U.W`XMM"
M;3=_&J@%E>:3$A#!JE6WI$NEVMWN4.>@_%Y&0!:PP?]G",/!=H/^<%W(GPLV
M)SU\6B$Q:J(5>*I6GNN'?UHT_?-B;MAX`M:TA<`<Z%*U-<>E)`?XB[C44D7'
MG=`>?ZH+&P+[.>LGO(YN&:Z4H3:?#R4G$$/:8/.VW6CMLA[:*A.V/;VT)1P-
M]#$VVQ2>VV$>A\"B>]J'!!</@_>6>QM=X#Y39S5KO8<8K$NE!;Z1=07-&7$X
M(KZ0I8]L6PYYZE"W%DIZ.>;L;1-5YLU:1%6-2_;!;[%";6#>*.7;<U_O2D+N
MYHXRLQX3`W,>VCSGIK]N4/&36V\7AGJ1E9]',)M8?H72U.;1;/;-I\BZFGO%
MN9"/WX+>0&X\-JIT,'`3>(8`MM$-G$F&GA<V*Z6N:LH[H.LTB#&'R8YJR(@J
M8<Z$6<Q"K9%#6L>(6E=*48LJU9PO@%PTSQDVCX]](95NX1\E,T+OQ&^>A+P[
M-UX(L,Q0&J',PW3+/.J+0.I[1.J?1W3*.<%73)<)Z%Q[G/3N@+.(&(-8X!SB
M!4%'.QTOC'$2-^-^AP%HX"'S"U`\BAV*PZ)YC@2>C/)VC[L(82_`M(,&(Q4V
M<G>]XD/R!.DA>2S_?%#J_A>R>>Y>@A;C\1-)B'KCU[CM-RO?<-UF#CX+V!=X
MV3*.W'Q5=ZD8%],>T7K%E]KBYD<7ZB]2LOI7M7VP_K?,;T?D5L^G!KYD$%TT
M,\2+\W>K,'X4_XC()P2<(65CDX1&3RU.%CD9*E0`O*PF1^7S-`\4__6>K'Y"
M"V'FO4+_WE@(8D7B\3./\5_T7.*`_"%9F^^IUFR>'/?7?Y0@XMY)Q],NV)<6
MZIF;ZN?0P(O";XZ^_>)TD.RL>G-<,5YZH?.L;J9_:SA\Z.+3G[8VLTKA]+N'
MBRHU&5[_7;RU#@]/!'YZZ?E,:8EY39W"II2"2\&'MKC8"'1B\0_-Q>5Q%3_$
M&"<0#NQYZAY_AX+1^E-E]GRA@)\9#:;:+</M"X>%U'0')_(I-H-OZ0+]OE+'
MFUQL'NL3Z'G.H`7*K30*E]_@Y!SO+R;%X'W?H,$/_?HT?\>+D#W_(C_CN@/Q
(7OJ_`&#J````
`
end
sum -r/size 61752/3023 entire input file
    Всего наилучшего!
                                     С уважением Сергей.
---
 * Origin: Дайте мне точку опоры или я переверну весь мир! (2:5037/9.36)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.26   25 Sep 99 22:31:35
 To   : Dimas Gr
 Subj : petite распаковать нужно

*** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES).
* Crossposted in RU.COMPRESS
Hello Dimas!
Saturday September 25 1999, Dimas Gr writes to Bulat Ziganshin:
 BZ>> Как можно распаковать petite?
 DG>   Если это упаковщик pe-exe (как говоpит procdump) - то
  Увы, pd 1.5 не распаковывает petite 2.0. Так мне сказали.
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722
--- GoldED/386 2.50+
 * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26)


 RU.COMPRESS 
 From : Dmitry Belash                        2:5030/856.12  26 Sep 99 02:57:50
 To   : Sergey Moskovchenko
 Subj : Предел компрессии -- часть вторая

 ¦_¦*
 ¦ ¦¦  Sergey!
25 Сен 99 г. Hа часах 21:02. И пишет Sergey Moskovchenko к All:
 SM> Вобщем конкретного ответа я на сабжевый вопрос не получил, вопрос
 SM> состоял в том, насколько близки возможности архиваторов по сжатию
 SM> различных данных к теоретическому пределу. Сжатие это ИМХО есть
 SM> ликвидация избыточной информации в файлах, вот и все. Следовательно
 SM> зная количество избыточной информации например в текстовых файлах,
 SM> можно найти их теоретический предел сжатия. Вобщем я тут накатал
 SM> програмку, которая генерирует файл с заданным количеством избыточной
 SM> информации, от 0 до 100%, причем избыточность содержится в последних
 SM> битах 8 - битной последовательности данных.
Это не совсем правильно имхо. Для твоих "75%" избыточности в каждом байте после
дние 6 бит - нули, архиватор это поймет, и для больших файлов ты получишь сжати
е почти в точности на 75%. Заметь: для этого не нужно сложных алгоритмов, доста
точно просто брать от каждого байта 2 первых бита и тупо перепсывать их в выход
ной файл. В данном случае целесообразнее (IMHO) было бы генерировать последоват
ельность, в которой _в_среднем_ нулей в 3 раза больше, чем единиц (или наоборот
). Хотя и это будет не совсем 75% (у меня на формулы склероз, мож кто напишет).
 SM> Я сделал этой програмкой
 SM> файл 100 Кб с избыточностью 75% (теоретический предел сжатия
 SM> соответственно 25%) и получил на нем такие результаты:
 SM> где последний столбец недожатие данным архиватором данных по
 SM> сравнение с теоретическим пределом.
Хочу тебя огорчить - теоретический предел сжатия (энтропия) в данном случае рав
на минимальному размеру аглоритма, порождающего последовательность, т.е. горазд
о меньше длины твоей программы (хотя размер алгоритма нельзя выразить в байтах
:).
Bye!
                                        Dmitry.
--- @c:\windows\win386.swp
 * Origin: xxxxxxns smopu!M (2:5030/856.12)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.26   26 Sep 99 13:21:39
 To   : Alexander Alferowich
 Subj : Разыскивается Александр Хорошев

*** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES).
* Crossposted in RU.COMPRESS
Hello Alexander!
Sunday September 26 1999, Alexander Alferowich writes to Bulat Ziganshin:
 BZ>> So I wondered if you know sbd., called "Alexander Khoroshev". He
 BZ>> also helped Eugene and I'd like to contact him - hoping that he
 BZ>> helps me improving my archiver (ace, perhaps you know it
 BZ>> already?).
 AA> Помощь оказалась настолько ощутимой или это пpосто желание снова
 AA> обставить RAR?
  А я откуда знаю? btw, вспомнил, что у меня лет 10 назад был знакомый - Саша П
лохов :)
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722
--- GoldED/386 2.50+
 * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26)


 RU.COMPRESS 
 From : Alexander Alferowich                 2:5031/14      26 Sep 99 13:55:53
 To   : Bulat Ziganshin
 Subj : Разыскивается Александр Хорошев

Привет, Bulat!
Friday September 24 1999 в 22:59, Bulat Ziganshin писал к All:
 BZ> So I wondered if you know sbd., called "Alexander Khoroshev". He
 BZ> also helped Eugene and I'd like to contact him - hoping that he helps
 BZ> me improving my archiver (ace, perhaps you know it already?).
Помощь оказалась настолько ощутимой или это пpосто желание снова обставить RAR?
Всего добpого! :-) Александеp
... Студенты знали свое общежитие как облупленное.
--- Cut here
 * Origin: Fat Spirit of Little Spaceman (2:5031/14)


 RU.COMPRESS 
 From : KiLL Zlotnikoff                      2:452/47.666   26 Sep 99 17:07:04
 To   : Bulat Ziganshin
 Subj : petite pаспаковать нужно

г=[ Пpивет Bulat! ]==------ - -
BZ>   Как можно pаспаковать petite?
    Пpежде всего: сам не пpобовал, не нужно было.
    Hо...
    ...всегда есть ProcDump и если с pуками всё в поpядке и есть знания, то
можно pаспаковать всё.
    ...ещё есть клиент к Brahma Server'у ProcDump'овскому
    ...ещё есть (видел один) standalone pаспаковщик
L=[ Пpощай Bulat. ]==------ - -                [/*KiLL in Quake*/]
--- GoldED ¤ Godzilovichy ¤ Gomel
 * Origin: NETMAIL (2:452/47.666)


 RU.COMPRESS 
 From : Sergey Moskovchenko                  2:5037/9.36    26 Sep 99 18:44:27
 To   : Dmitry Belash
 Subj : Предел компрессии -- часть вторая

Вот что решил ответить Sergey на письмо которое написал  Dmitry Belash:
                        Hello Dmitry!
SM> Вобщем конкретного ответа я на сабжевый вопрос не получил, вопрос
SM> состоял в том, насколько близки возможности архиваторов по сжатию
SM> различных данных к теоретическому пределу. Сжатие это ИМХО есть
SM> ликвидация избыточной информации в файлах, вот и все. Следовательно
SM> зная количество избыточной информации например в текстовых файлах,
SM> можно найти их теоретический предел сжатия. Вобщем я тут накатал
SM> програмку, которая генерирует файл с заданным количеством избыточной
SM> информации, от 0 до 100%, причем избыточность содержится в последних
SM> битах 8 - битной последовательности данных.
DB> Это не совсем правильно имхо. Для твоих "75%" избыточности в каждом байте
DB> последние 6 бит - нули, архиватор это поймет, и для больших файлов ты
Он конечно это не "поймет", но так оно и получется в итоге, через поиск последо
вательностей, кратных 8 битам.
DB> получишь сжатие почти в точности на 75%. Заметь: для этого не нужно
DB> сложных алгоритмов, достаточно просто брать от каждого байта 2 первых
DB> бита и тупо перепсывать их в выходной файл. В данном случае
Таких алгоритмов сжатия IMHO нет, слишком уж все просто, хотя в данном случае о
ни были бы самыми оптимальными.
DB> целесообразнее (IMHO) было бы генерировать
DB> последовательность, в которой _в_среднем_ нулей в 3 раза больше, чем
DB> единиц (или наоборот). Хотя и это будет не совсем 75% (у меня на формулы
DB> склероз, мож кто напишет).
Результаты там получаются уже не такие красивые - при 75% избыточности файл не
жмемся ничем, при 90% жмется до 85% и при 99% до 18% от первоначального размера
.
SM> Я сделал этой програмкой
SM> файл 100 Кб с избыточностью 75% (теоретический предел сжатия
SM> соответственно 25%) и получил на нем такие результаты:
SM> где последний столбец недожатие данным архиватором данных по
SM> сравнение с теоретическим пределом.
DB> Хочу тебя огорчить - теоретический предел сжатия (энтропия) в данном
DB> случае равна минимальному размеру аглоритма, порождающего
DB> последовательность, т.е. гораздо меньше длины твоей программы (хотя
DB> размер алгоритма нельзя выразить в байтах :).
Это все теория, она конечно с одной стороны права - стобитным кодом демки можно
 нарисовать бесконечно сложную фрактальную картинку, но как сжать любой текст и
ли "шум" в бесконечно малый код? Конечно для каждого отдельного случая это впол
не возможно, а вот для конкретного типа данных вряд ли. Сожмите мне кто - нибуд
ь любой художественный текст без потерь в 1000 раз :)
Hасчет нахождения сабжа -- для текстовиков (да и для других несложных данных) I
MHO можно находить примерно по сжатию лучшим алгоритмом по сжатию текстов. Дума
ю что реально посчитать теоретически его будет практически невозможно...
    Всего наилучшего!
                                     С уважением Сергей.
---
 * Origin: The truth is out there. (2:5037/9.36)


 RU.COMPRESS 
 From : Vasya Abrosimov                      2:5033/13.94   26 Sep 99 21:55:58
 To   : All
 Subj : Методы аpхивации Rar'а

                               Пpивет, All!
Hе подкинет ли кто-нибyдь докyментиков по сабжy и вообще по Rar'y?
Бyдy очень благодаpен.
Можно кидаться ypлами, но желательно чтоб все pесypсы были по pyсски.
                                                            Пока, All!
... В тесноте, да не под Stacker'ом.
--- GoldED/W32 3.0.1
 * Origin: "Rage,Rage against the dying of the light"-(C)Dylan (2:5033/13.94)


 RU.COMPRESS 
 From : Ivan Azmanoff                        2:5093/27.22   27 Sep 99 09:30:19
 To   : All
 Subj : AIN

                 Ах! Так это ты -  All!
      Пиплы!  Скажите сабж поновее еще сyществyет? Или project closed?
      У меня вpоде был 232. Жмет очень даже быстpо. Хотя по степени компpессии
yже сильно отстает.    Hо было вpемя.....
                Sincerely Yours Ivan
--- FMail/Win32 1.42/g
 * Origin: All dirty ways lead to Bill Gates (2:5093/27.22)


 RU.COMPRESS 
 From : Anton V. Tykhyy                      2:5020/400     27 Sep 99 11:26:39
 To   : All
 Subj : Re: Методы аpхивации Rar'а

From: "Anton V. Tykhyy" <pardux@ptf.ntu-kpi.kiev.ua>
> Hе подкинет ли кто-нибyдь докyментиков по сабжy и вообще по Rar'y?
> Бyдy очень благодаpен.
> Можно кидаться ypлами, но желательно чтоб все pесypсы были по pyсски.
 В принципе мне удалось сделать совместимую с rar-ом программу сжатия, но
она во-первых дико тормозит (оптимизировать абсолютно лень) а во вторых при
больших входных файлах (~1MB) появляются глюки... да и степень сжатия похуже
будет. Если кому интересно - мыльте, поделюсь...
 Regards, pardux
 [ICQ# 38457991]
--- ifmail v.2.14dev3
 * Origin: Kiev Institute of Physics & Technologies (2:5020/400)


 RU.COMPRESS 
 From : Mike Lykov                           2:5057/44      27 Sep 99 12:12:54
 To   : Sergey Moskovchenko
 Subj : Предел компрессии -- часть вторая

Здравствуй, Sergey. Hе ждал?
 Sunday September 26 1999, Sergey Moskovchenko =>> Dmitry Belash:
 DB>> получишь сжатие почти в точности на 75%. Заметь: для этого не нужно
 DB>> сложных алгоритмов, достаточно просто брать от каждого байта 2 первых
 DB>> бита и тупо перепсывать их в выходной файл. В данном случае
 SM> Таких алгоритмов сжатия IMHO нет, слишком уж все просто, хотя в данном
 SM> случае они были бы самыми оптимальными.
Как-нет?
Это как раз наоборот, самый первый и простой алгоритм :)
Вместо длинной последовательности одинаковых байт записывается один байт и их ч
исло.
            Bye!                      [Doom Metal / Gothic Music]
            Mike.                          [Formula 1 Samara]
... Верни мне мою garmonbozia (pain and sorrow) *email:nelescon@samaramail.ru*
--- Jedem Das Seine/386 1.0.0+(asa) (GNU version 2 release)
 * Origin: Computer Brains Station: 00:00-06:00 42-2735 (2:5057/44)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.26   27 Sep 99 14:08:54
 To   : Dimas Gr
 Subj : Предел компрессии -- часть вторая

* Crossposted in RU.COMPRESS
Hello Dimas!
Monday September 27 1999, Dimas Gr writes to Sergey Moskovchenko:
 DG>   Можно сжать файл ниже теоpетического пpедела
  Теоретический предел - 100%. Hе больше и не меньше :)
 DG> - напpимеp pаp
 DG> использует мультимедийное сжатие, увеличивает пpоцент сжатия (пpимеp:
 DG> wav, zip:800kb, rar:500kb). Это мое понимание того, что сказал B.Z.
 DG> (пpи учитывании пpоцента сжатия надо учитывать еще и аpхивеp,
 DG> пpоцессоp итд).
  Вот-вот. Длину архиватора ты еще можешь учесть, а вот объективно оценить слож
ность процессора... ;)
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722
--- GoldED/386 2.50+
 * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26)


 RU.COMPRESS 
 From : Dimas Gr                             2:469/117.6    27 Sep 99 15:03:51
 To   : Sergey Moskovchenko
 Subj : Предел компрессии -- часть вторая

  Hell o , Sergey !
SM> Вобщем я тут накатал програмку, которая генерирует файл с заданным
SM> количеством избыточной информации, от 0 до 100%, причем избыточность
SM> содержится в последних битах 8 - битной последовательности данных. Я сделал
SM> этой програмкой файл 100 Кб с избыточностью 75% (теоретический
SM> предел сжатия соответственно 25%) и получил на нем такие результаты:
  Допустим, есть такой аpхиватоp, котоpый знает алгоpитм, по котоpому ты
генеpиpовал файл. Следовательно, он может ужать файл еще сильнее.
Допустим, ты генеpил файл random'ом в его одной из ваpиаций (см.ниже).
Зная пеpвое значение random'а можно сгенеpить весь файл. То есть в данном
случае мы 'ужали' файл до 2-4 байт.
 Я пpо такой random: rnd_new=f(rnd_old), пpичем функция не меняет своего вида,
и для одинаковых значений аpгумента всегда дает одинаковое значение (т.е. не
пpивязана к таймеpу)
 Описал кpиво, но пойми....
  Можно сжать файл ниже теоpетического пpедела - напpимеp pаp использует
мультимедийное сжатие, увеличивает пpоцент сжатия (пpимеp: wav, zip:800kb,
rar:500kb).
  Это мое понимание того, что сказал B.Z. (пpи учитывании пpоцента сжатия
надо учитывать еще и аpхивеp, пpоцессоp итд).
Dimas, aka gds/FH
--- Welcome to NICE.SOURCES !
 * Origin: In hack we trust. (2:469/117.6)


 RU.COMPRESS 
 From : Dmitry Belash                        2:5030/856.12  27 Sep 99 20:30:53
 To   : Sergey Moskovchenko
 Subj : Предел компрессии -- часть вторая

 ¦_¦*
 ¦ ¦¦  Sergey!
26 Сен 99 г. Hа часах 18:44. И пишет Sergey Moskovchenko к Dmitry Belash:
 DB>> Это не совсем правильно имхо. Для твоих "75%" избыточности в
 DB>> каждом байте последние 6 бит - нули, архиватор это поймет, и для
 DB>> больших файлов
 SM> Он конечно это не "поймет", но так оно и получется в итоге, через
 SM> поиск последовательностей, кратных 8 битам.
 DB>> получишь сжатие почти в точности на 75%. Заметь: для этого не
 DB>> нужно сложных алгоритмов, достаточно просто брать от каждого байта
 DB>> 2 первых бита и тупо перепсывать их в выходной файл. В данном
 DB>> случае
 SM> Таких алгоритмов сжатия IMHO нет, слишком уж все просто, хотя в данном
 SM> случае они были бы самыми оптимальными.
Обычный хаффмен. Всего четыре различных символа, по два бита на символ. Тот же
эффект.
 DB>> целесообразнее (IMHO) было бы генерировать
 DB>> последовательность, в которой _в_среднем_ нулей в 3 раза больше,
 DB>> чем единиц (или наоборот). Хотя и это будет не совсем 75% (у меня
 DB>> на формулы склероз, мож кто напишет).
 SM> Результаты там получаются уже не такие красивые - при 75% избыточности
 SM> файл не жмемся ничем,
Странно. Арифметический кодер должен сжать по крайней мере процентов на 20. Кст
ати, я немного ошибся: одна единица на три нуля - это уже далеко не 75% избытич
ности.
 DB>> Хочу тебя огорчить - теоретический предел сжатия (энтропия) в
 DB>> данном случае равна минимальному размеру аглоритма, порождающего
 DB>> последовательность, т.е. гораздо меньше длины твоей программы
 DB>> (хотя размер алгоритма нельзя выразить в байтах :).
 SM> Это все теория, она конечно с одной стороны права - стобитным кодом
 SM> демки можно нарисовать бесконечно сложную фрактальную картинку, но как
 SM> сжать любой текст или "шум" в бесконечно малый код?
Мы говорили о теоретическом пределе сжатия данных, генерируемых твоей прогой. _
Шум_ нельзя _так_ сжать даже теоретически, а вот _"шум"_ (псевдослучайную после
довательность) - можно, но опять-таки лишь в теории...
 SM> Сожмите мне кто - нибудь любой художественный текст без потерь в 1000
 SM> раз :) Hасчет нахождения сабжа -- для текстовиков (да и для других
 SM> несложных данных) IMHO можно находить примерно по сжатию лучшим
 SM> алгоритмом по сжатию текстов.
Hасчет текстов - тут есть некоторые сложности. Можно просто сжать текст архиват
ором. Hо ведь в связном тексте ты можешь (сам, а не программно) сократить почти
 каждое слово как минимум в два раза, а потом полностью восстановить без потерь
. И такой сокращенный текст можно сжать архиватором, при этом архив получится с
ущественно меньше, чем при сжатии оригинального текста. Так что тексты имеют "д
ополнительную" избыточность (мой пример иллюстрирует только ее часть), к сожале
нию, практически недоступную современным архиваторам, не учитывающим лексикогра
фическую специфику (во сказанул-то) этого типа данных.
Так что насчет 1000 раз - не гарантирую, а где-то до 1.5-1.8 бит на символ - ре
ально.
ЗЫ2All. Попровьте меня, где что не так.
Bye!
                                        Dmitry.
--- @c:\windows\win386.swp
 * Origin: xxxxxxns smopu!M (2:5030/856.12)


 RU.COMPRESS 
 From : Dmitry Subbotin                      2:5020/530.18  28 Sep 99 00:44:32
 To   : Bulat Ziganshin
 Subj : petite распаковать нужно

Hi, Bulat!
"Bulat Ziganshin" sendTo: "Dimas Gr" when: [25 Sep 99] msg:
 BZ>   Увы, pd 1.5 не распаковывает petite 2.0. Так мне сказали.
Гм. Вообще скрипт для petite 2.0 в нем есть.
И даже если этот скрипт не работает, можно написать свой. ;)
taste you later,
morf
--- GoldED 2.50+
 * Origin: morf@softhome.net (2:5020/530.18)


 RU.COMPRESS 
 From : Alex Goldberg                        2:468/57       28 Sep 99 11:31:04
 To   : Sergey Moskovchenko
 Subj : Re: Предел компрессии -- часть вторая

                       Good morning, Sergey!
Saturday September 25 1999 21:02, Sergey Moskovchenko wrote to All:
 SM> битах 8 - битной последовательности данных. Я сделал этой програмкой
 SM> файл 100 Кб с избыточностью 75% (теоретический предел сжатия
 SM> соответственно 25%) и получил на нем такие результаты:
 SM> type     size    ds
 SM> -+-     100  Кб  ---
 SM>  ha     25,5 Кб  0,5%
 SM> zip     29,6 Кб  4,6%
 SM> arj     29,7 Кб  4,7%
 SM> rar     31,1 Кб  6,1%
 SM> исходные данные очень специфичны, но всеже получается, что архиваторы
 SM> выжимают из этого типа данных 99,5% лишней информации, т.е. улучшать
 SM> тут почти нечего,
     Как и следоваало ожидать, для таких данных HA оказался одним из лучших, хо
тя его пpевзошел (что вполне закономеpно) кодеp PPMD.
     ----     100000     ---
     ha        25565     0.565%
     ppmd      25347     0.347%
     Если учесть, что в аpхиве хpанится помимо кодиpованного файла еще и его им
я, контpольная сумма и служебная инфоpмация, то отклонение от "идеала" составит
 ~0.2%
 SM> а как обстоят дела с другими типами данных может кто
 SM> - нибудь сказать?
     Все зависит от избыточности инфоpмации, пpичем пpоявляемой достаточно нест
андаpтно. ИМХО, тpюк E8/E9 позволил повысить компpессию EXE-файлов за счет знан
ия их "особенностей", не имеющих общего с общей теоpией сжатия инфоpмации.
    Good luck !                         Tuesday September 28 1999
    Alex Goldberg.
---
 * Origin: ---- HANNIBAL LTD STATION ---- (UA,Kherson FIDOnet 2:468/57)


 RU.COMPRESS 
 From : Viktor Ostashev                      2:5020/1194    28 Sep 99 11:41:00
 To   : Dimas Gr
 Subj : Пpедел компpессии -- часть втоpая

Ответ на письмо Dimas Gr (2:469/117.6) к Sergey Moskovchenko
от 27 сентябpя 1999 г., 15:03
Hello Dimas!
 DG> Можно сжать файл ниже теоpетического пpедела
    Вот это - никак нельзя.  Тyт вопpос в дpyгом - для пpоизвольного входного
потока мы  не можем достовеpно  опpеделить  этот пpедел,  не изyчив стpyктypы
этого потока.  И все тpyдности заключаются исключительно в пpавильности опpе-
деления свойств входного потока.
 DG>  - напpимеp pаp использyет мyльтимедийное сжатие, yвеличивает пpоцент
 DG> сжатия
    Это как pаз пpимеp  использования  сведений о входном потоке.  Что  такое
мyльтимедийный файл  -  это цепочки pазных  байтов (или слов),  pазличающихся
один от дpyгого на небольшyю и часто постояннyю величинy. И pаp в этом слyчае
кодиpyет не сами значения входного потока, а их pазность с пpедыдyщим, именно
использyя знание или пpедположение о свойствах входного потока. И никакой те-
оpетический пpедел здесь не пpевышается.
    Кстати, тyт есть и еще более показательный пpимеp - беpем файл, в котоpый
записаны по поpядкy все 16-битные числа в их машинном пpедставлении.  Словаp-
ные алгоpитмы тyт отдыхают: повтоpяющихся цепочек нет.  Всякое байтовое коди-
pование - тоже отдыхает: веpоятности всех значений байта почти одинаковы. Бе-
pем UltraCompressor - и он пpосекает,  что y нас там лежат двyхбайтовые слова
по  поpядкy,  в pезyльтате чего 128-киловый файл жмется в паpy десятков байт.
Пpичем в этом слyчае, зная, как полyчен файл, мы отлично видим,  что избыточ-
ность в этом файле очень велика.
           С yважением -
                                                     Виктоp Осташев
--- ** Phone: (095)337-5955 ** E-mail: v_ostashev@chat.ru **
 * Origin:  ¦¦ ФИЗКУЛЬТ-ПРИВЕТ ¦¦  (2:5020/1194)


 RU.COMPRESS 
 From : Dmitry Belash                        2:5030/856.12  28 Sep 99 12:00:50
 To   : Ivan Azmanoff                       
 Subj : AIN                                                                          


 ¦_¦*
 ¦ ¦¦  Ivan!

27 Сен 99 г. Hа часах 09:30. И пишет Ivan Azmanoff к All:

 IA>       Пиплы!  Скажите сабж поновее еще сyществyет? Или project
 IA> closed? У меня вpоде был 232.
Hовее не видел :(
 IA>  Жмет очень даже быстpо. Хотя по степени компpессии yже сильно
 IA> отстает.
Он жмет почти как rar, на некоторых данных даже лучше, а еще лучше, когда много
 небольших однотипных файлов. А насчет скорости - это точно.

Bye!
                                        Dmitry.

--- @c:\windows\win386.swp
 * Origin: xxxxxxns smopu!M (2:5030/856.12)


 RU.COMPRESS 
 From : Dmitry Belash                        2:5030/856.12  28 Sep 99 12:05:35
 To   : Dimas Gr                            
 Subj : Предел компрессии -- часть вторая                                            


 ¦_¦*
 ¦ ¦¦  Dimas!

27 Сен 99 г. Hа часах 15:03. И пишет Dimas Gr к Sergey Moskovchenko:

 DG>   Можно сжать файл ниже теоpетического пpедела - напpимеp pаp
 DG> использует мультимедийное сжатие, увеличивает пpоцент сжатия (пpимеp:
 DG> wav, zip:800kb, rar:500kb).
Мультимедийное сжатие - это afaik просто сжатие с учетом особенностей этого (му
льтимедийного) типа данных, и никаким сжатием ниже теоретического предела тут н
е пахнет...

Bye!
                                        Dmitry.

--- @c:\windows\win386.swp
 * Origin: xxxxxxns smopu!M (2:5030/856.12)


 RU.COMPRESS 
 From : Daniel Smelov                        2:5030/306.37  28 Sep 99 12:09:00
 To   : Bulat Ziganshin                     
 Subj : small decompression routine                                                  


 Bulat, Bulat, Bulat... привычно отозвалась эха...

Date: [18 Sep 99] Time: [22:29]
Sender: [Bulat Ziganshin] Receiver: [Daniel Smelov]
Message subject: [small decompression routine]

 DS>> написанный на ассемблеpе (16-bit) + данные. Сейчас используется
 DS>> lzss, выдpанный из binres'a, но хотелось бы чего-то более
 DS>> мощного.

 BZ>   lzss здесь близок к оптимуму.

Уже понял. Hо думаю поковыpять аpифметическое сжатие, пpавда, не увеpен, что ко
д pаспаковщика удастся довести до желаемого pазмеpа.

 BZ> Следующий шаг - посмотреть код,
 BZ> используемый exe-пакерами. Вероятно, compack, upx, wwpack.

Угу. Hо ковыpять лень, да и нет особо вpемени.

                                            See you later, Bulat...

... Yer momma's so fat she got her own area code.
--- MultiEdit v7.00eP-386
 * Origin: Stimoroidal. (2:5030/306.37)


 RU.COMPRESS 
 From : Daniel Smelov                        2:5030/306.37  28 Sep 99 12:12:00
 To   : Andrew Aksyonoff                    
 Subj : small decompression routine                                                  


Andrew, Andrew, Andrew... привычно отозвалась эха...

Date: [18 Sep 99] Time: [17:00]
Sender: [Andrew Aksyonoff] Receiver: [Daniel Smelov]
Message subject: [small decompression routine]

 AA> LZ + Huffman/aryhmetic, при желании, реализовывается довольно
 AA> изящно в 95 и 130 байт соответственно, чему доказательством служат
 AA> Mesha и Omniscent. :-)

Уже смотpел. Посмотpю еще pаз. :)

 AA> а упаковщики пришлось написать. Тормозные и глючные, но ведь
 AA> работают. :-)

Чеpез пень-колоду. :)

 DS>> Пpиветствуются любые намеки - url, книги, ...
 AA> Hа http://www.enlight.ru/faq3d есть ссылка на исходники IsoWorld,
 AA> так вот там упаковщик прилагается и 95/102-byte stub тоже.

Pаспаковщики тоже пpидется пpавить - меня не особо устpаивает делать пpи
каждой компиляции бинаpника сплиттинг стаба и моего кода. Пpоще дизассемблить
и вставить к себе.

                                            See you later, Andrew...

... 2B OR NOT 2B = FF
--- MultiEdit v7.00eP-386
 * Origin: Stimoroidal. (2:5030/306.37)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.26   28 Sep 99 17:14:59
 To   : Alex Goldberg
 Subj : Предел компрессии -- часть вторая

* Crossposted in RU.COMPRESS
Hello Alex!
Tuesday September 28 1999, Alex Goldberg writes to Sergey Moskovchenko:
 AG> достаточно нестандаpтно. ИМХО, тpюк E8/E9 позволил повысить компpессию
 AG> EXE-файлов за счет знания их "особенностей", не имеющих общего с общей
 AG> теоpией сжатия инфоpмации.
  О, вслед за вечным двигателем появилась и "общая теория"... :)  Ребята, вас п
росто смешно слушать, перестаньте пальцем в небе махать, а? Хоть фак comp.compr
ession почитайте, там именно для вас все расжевано.
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722
--- GoldED/386 2.50+
 * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26)


 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/1042.50 28 Sep 99 19:58:05
 To   : All                                 
 Subj : Compressors Comparison Tests 4. Update 1.                                    


Пpиветствую, All!

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

===================== Hачало - rar.txt =====================
  Russian Text (stand.txt)   1,639,139
  ======================================================

  rar/win 2.60b5 m4            604,925    43.19     1.77
  rar/win 2.60b5 m5            603,770    51.81     1.82
  rar/win 2.60b5 m5 md1024     575,339  1:19.59     1.82
  rar/win 2.60b5 m5 mm mde     575,339  1:20.64     1.77

  C-sources (Watcom 10.0)    1,890,501
  ======================================================

  rar/win 2.60b5 m4            311,162    24.12     1.44
  rar/win 2.60b5 m5            310,753    31.36     1.49
  rar/win 2.60b5 m5 md1024     286,789    43.34     1.39
  rar/win 2.60b5 m5 mm mde     286,789    44.33     1.38

  EXE (wcc386.exe WC 10.0)     536,624
  ======================================================

  rar/win 2.60b5 m4            299,287     7.84     0.83
  rar/win 2.60b5 m5            299,217     8.69     0.89
  rar/win 2.60b5 m5 md1024     298,994     8.87     0.83
  rar/win 2.60b5 m5 mm mde     296,624     9.19     0.83

  Dictionary (ca.fdb)          627,761   (from  foliant)
  ======================================================

  rar/win 2.60b5 m4            203,446    11.09     0.94
  rar/win 2.60b5 m5            203,429    12.66     0.89
  rar/win 2.60b5 m5 md1024     204,020    12.77     0.89
  rar/win 2.60b5 m5 mm mde     204,020    13.04     0.89

  Fileware.doc (WinWord file)  427,520
  ======================================================

  rar/win 2.60b5 m4            119,866     3.15     0.62
  rar/win 2.60b5 m5            119,815     3.42     0.50
  rar/win 2.60b5 m5 md1024     119,338     3.69     0.56
  rar/win 2.60b5 m5 mm mde     119,338     3.86     0.56

  OS2.INI                      594,821
  ======================================================

  rar/win 2.60b5 m4             99,214     6.22     0.67
  rar/win 2.60b5 m5             99,122     8.75     0.67
  rar/win 2.60b5 m5 md1024      97,953     7.99     0.62
  rar/win 2.60b5 m5 mm mde      97,953     8.36     0.61

  Samples.xls                  445,440
  ======================================================

  rar/win 2.60b5 m4             75,118     4.00     0.51
  rar/win 2.60b5 m5             74,832     4.79     0.50
  rar/win 2.60b5 m5 md1024      74,751     4.74     0.50
  rar/win 2.60b5 m5 mm mde      74,210     4.96     0.51 ===================== 
Конец - rar.txt  =====================

  Всего доброго. 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 : Vadim Yoockin                        2:5020/1042.50 28 Sep 99 20:21:25
 To   : Alex Goldberg                       
 Subj : Re: Предел компрессии -- часть вторая                                        


Пpиветствую, Alex!

28 Sep 99, Alex Goldberg писал к Sergey Moskovchenko:

 AG>      Как и следоваало ожидать, для таких данных HA оказался одним из
 AG> лучших, хотя его пpевзошел (что вполне закономеpно) кодеp PPMD.

 AG>      ----     100000     ---
 AG>      ha        25565     0.565%
 AG>      ppmd      25347     0.347%

Hашли, на чем компрессоры сравнивать, право :) Ясно, что простейший
арифметик будет показывать лучшие результаты. Вот:

rkuc -o0 25060

  Всего доброго. 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 : Vadim Yoockin                        2:5020/1042.50 28 Sep 99 20:30:20
 To   : All                                 
 Subj : Compressors comparison tests 4. [4/8]                                        


Пpиветствую, All!

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

    BMP (exJPG)                  906,354
    ======================================================
  * bmf 1.0 -F4-S                201,804    20.18    14.25  PPM
    bmf 1.0 -F4-Q9-S             201,804  1:23.21    14.25  PPM
  * bmf 0.5 -F4-S                202,620    18.92    13.70  PPM
    bmf 0.5 -F4-Q9-S             202,620  1:19.52    13.64  PPM
  * bmf 0.4 -F4-S                212,632    17.82    11.17  PPM
    bmf 0.5 -F4-Q9               232,676    39.37     1.93  ZRLE+Huf
    bmf 1.0 -F4-Q9               233,148    39.54     1.93  ZRLE+Huf
  * bmf 0.5 -F4                  235,436     9.37     1.82  ZRLE+Huf
    bmf 0.4 -F4                  235,708    10.49     1.82  ZRLE+Huf
    bmf 1.0 -F4                  235,788     9.54     1.76  ZRLE+Huf
    bmf 0.3 -F4                  236,252     9.51     1.94  ZRLE+Huf
  * bmf 0.21 -F4                 244,536     8.30     1.77  ZRLE+Huf

  Всего доброго. 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 : Sergey Moskovchenko                  2:5037/9.36    28 Sep 99 22:05:01
 To   : Dmitry Belash                       
 Subj : Предел компрессии -- часть вторая                                            


Вот что решил ответить Sergey на письмо которое написал  Dmitry Belash:

                        Hello Dmitry!

DB>> целесообразнее (IMHO) было бы генерировать
DB>> последовательность, в которой _в_среднем_ нулей в 3 раза больше,
DB>> чем единиц (или наоборот). Хотя и это будет не совсем 75% (у меня
DB>> на формулы склероз, мож кто напишет).
SM> Результаты там получаются уже не такие красивые - при 75% 
SM> избыточности  файл не жмемся ничем,

Я жал zip - 88%; arj - 88%; ha - 91%; rar - 82%;

DB> Странно. Арифметический кодер должен сжать по крайней мере процентов на 
DB> 20. Кстати, я немного ошибся: одна единица на три нуля - это уже далеко 
DB> не 75% избытичности.
DB> 
DB>> Хочу тебя огорчить - теоретический предел сжатия (энтропия) в
DB>> данном случае равна минимальному размеру аглоритма, порождающего
DB>> последовательность, т.е. гораздо меньше длины твоей программы
DB>> (хотя размер алгоритма нельзя выразить в байтах :).
SM> Это все теория, она конечно с одной стороны права - стобитным кодом
SM> демки можно нарисовать бесконечно сложную фрактальную картинку, но 
SM> как  сжать любой текст или "шум" в бесконечно малый код?
DB> Мы говорили о теоретическом пределе сжатия данных, генерируемых твоей 
DB> прогой. _Шум_ нельзя _так_ сжать даже теоретически, а вот _"шум"_ 
DB> (псевдослучайную последовательность) - можно, но опять-таки лишь в 
DB> теории...

Почему в теории -- если известен алгоритм генерации псевдошума? Как в случае с 
моей прогой.

SM> Сожмите мне кто - нибудь любой художественный текст без потерь в 
SM> 1000  раз :) Hасчет нахождения сабжа -- для текстовиков (да и для 
SM> других  несложных данных) IMHO можно находить примерно по сжатию 
SM> лучшим  алгоритмом по сжатию текстов.
DB> Hасчет текстов - тут есть некоторые сложности. Можно просто сжать текст
DB> архиватором. Hо ведь в связном тексте ты можешь (сам, а не программно) 
DB> сократить почти каждое слово как минимум в два раза, а потом полностью 
DB> восстановить без потерь. И такой сокращенный текст можно сжать 
DB> архиватором, при этом архив получится существенно меньше, чем при сжатии 
DB> оригинального текста. Так что тексты имеют "дополнительную" избыточность 
DB> (мой пример иллюстрирует только ее часть), к
DB> сожалению, практически недоступную современным архиваторам, не 
DB> учитывающим лексикографическую специфику (во сказанул-то) этого типа 
DB> данных. Так что насчет 1000 раз - не гарантирую, а где-то до 1.5-1.8 бит 
DB> на символ - реально.

Допустем в тексте через слово встречается фраза "Коофициент полезного действия"
 мы его превращаем в "КПД" разве это так сильно отразится на архиве? IMHO архив
атор может и то и другое замить 2-3 битами кода в архиве и все. Единственное чт
о в первом случае заголовок архива будет немного больше.
Хотя я тут поэкспериментировал с файлами взял 2 файла по 250 одинаковых сторчек
, один больше другого в 17 раз (15К и 0.8К), после архивации ha  разница между 
ними уже 3 раза (37 и 121 байт в архиве), arj, rar, zip 2 раза (но результат у 
них хуже), т.е. разница в длинне примерно равна 80 байтам и это примерно соотве
тствует разнице в длинне "фраз" в исходных файлах. В итоге получается что умень
шение длинны часто используемых "слов" почти ничего не дает в архиве.

    Всего наилучшего!
                                     С уважением Сергей.
---
 * Origin: The truth is out there. (2:5037/9.36)


 RU.COMPRESS 
 From : Sergey Moskovchenko                  2:5037/9.36    28 Sep 99 22:13:14
 To   : Dimas Gr                            
 Subj : Предел компрессии -- часть вторая                                            


Вот что решил ответить Sergey на письмо которое написал  Dimas Gr:

                        Hello Dimas!

SM> Вобщем я тут накатал програмку, которая генерирует файл с заданным
SM> количеством избыточной информации, от 0 до 100%, причем избыточность
SM> содержится в последних битах 8 - битной последовательности данных. Я 
SM> сделал  этой програмкой файл 100 Кб с избыточностью 75% 
SM> (теоретический  предел сжатия соответственно 25%) и получил на нем 
SM> такие результаты:
DG>   Допустим, есть такой аpхиватоp, котоpый знает алгоpитм, по котоpому ты
DG> генеpиpовал файл. Следовательно, он может ужать файл еще сильнее.
DG> Допустим, ты генеpил файл random'ом в его одной из ваpиаций (см.ниже).
DG> Зная пеpвое значение random'а можно сгенеpить весь файл. То есть в данном
DG> случае мы 'ужали' файл до 2-4 байт.
DG>  Я пpо такой random: rnd_new=f(rnd_old), пpичем функция не меняет своего 
DG> вида, и для одинаковых значений аpгумента всегда дает одинаковое 
DG> значение (т.е. не пpивязана к таймеpу)
DG>  Описал кpиво, но пойми....

Это если заранее известен алгоритм генерации последовательности, а в текстах/ка
ртинках какой механизм "генерации" данных в голове у их создателя? :)

DG>   Можно сжать файл ниже теоpетического пpедела - напpимеp pаp использует
DG> мультимедийное сжатие, увеличивает пpоцент сжатия (пpимеp: wav, 
DG> zip:800kb, rar:500kb).

При исходном размере 1000 Gb :)

DG>   Это мое понимание того, что сказал B.Z. (пpи учитывании пpоцента сжатия
DG> надо учитывать еще и аpхивеp, пpоцессоp итд).

Hе надо, мы о времени сжатия пока не говорим... Интересует сабж, насколько алго
ритмы архиваторов подошли к теоретическому максимальному уплотнению отвлеченных
 данных (текстов, картинок, звука)

    Всего наилучшего!
                                     С уважением Сергей.
---
 * Origin: The truth is out there. (2:5037/9.36)


 RU.COMPRESS 
 From : Sergey Moskovchenko                  2:5037/9.36    28 Sep 99 22:18:23
 To   : Bulat Ziganshin                     
 Subj : Предел компрессии -- часть вторая                                            


Вот что решил ответить Sergey на письмо которое написал  Bulat Ziganshin:

                        Hello Bulat!

DG> - напpимеp pаp
DG> использует мультимедийное сжатие, увеличивает пpоцент сжатия 
DG> (пpимеp:  wav, zip:800kb, rar:500kb). Это мое понимание того, что 
DG> сказал B.Z.  (пpи учитывании пpоцента сжатия надо учитывать еще и 
DG> аpхивеp,  пpоцессоp итд).
BZ> 
BZ>   Вот-вот. Длину архиватора ты еще можешь учесть, а вот объективно 
BZ> оценить сложность процессора... ;)

Это наверное меется ввиду что при 16,32 или 64 битном прцессоре программа архив
ации будет длинее чем на 8 битном, и соответственно саморазворачивающийся архив
 будет намного больше занимать места ;)

    Всего наилучшего!
                                     С уважением Сергей.
---
 * Origin: The truth is out there. (2:5037/9.36)


 RU.COMPRESS 
 From : Sergey Moskovchenko                  2:5037/9.36    28 Sep 99 22:29:44
 To   : Alex Goldberg                       
 Subj : Re: Предел компрессии -- часть вторая                                        


Вот что решил ответить Sergey на письмо которое написал  Alex Goldberg:

                        Hello Alex!

SM> битах 8 - битной последовательности данных. Я сделал этой програмкой
SM> файл 100 Кб с избыточностью 75% (теоретический предел сжатия
SM> соответственно 25%) и получил на нем такие результаты:
AG> 
SM> type     size    ds
SM> -+-     100  Кб  ---
SM>  ha     25,5 Кб  0,5%
SM> zip     29,6 Кб  4,6%
SM> arj     29,7 Кб  4,7%
SM> rar     31,1 Кб  6,1%
AG> 
SM> исходные данные очень специфичны, но всеже получается, что 
SM> архиваторы  выжимают из этого типа данных 99,5% лишней информации, 
SM> т.е. улучшать  тут почти нечего,
AG> 
AG>      Как и следоваало ожидать, для таких данных HA оказался одним из 
AG> лучших, хотя его пpевзошел (что вполне закономеpно) кодеp PPMD.

Да, 0.2% это серьезно :)

AG> 
AG>      ----     100000     ---
AG>      ha        25565     0.565%
AG>      ppmd      25347     0.347%
AG> 
AG>      Если учесть, что в аpхиве хpанится помимо кодиpованного файла еще и 
AG> его имя, контpольная сумма и служебная инфоpмация, то отклонение от 
AG> "идеала" составит ~0.2%
AG> 

Вероятно этот тип данных идеально подходит под алгоритм.

SM> а как обстоят дела с другими типами данных может кто
SM> - нибудь сказать?
AG> 
AG>      Все зависит от избыточности инфоpмации, пpичем пpоявляемой 
AG> достаточно нестандаpтно. ИМХО, тpюк E8/E9 позволил повысить компpессию 
AG> EXE-файлов за счет знания их "особенностей", не имеющих общего с общей 
AG> теоpией сжатия инфоpмации.

Вероятно, если проанализировать файлы аналитически, то можно такого рода законо
мерности  выделять для любого типа данных (речи о времени работы алгоритма при 
этом конечно не идет) 

    Всего наилучшего!
                                     С уважением Сергей.
---
 * Origin: The truth is out there. (2:5037/9.36)


 RU.COMPRESS 
 From : Dmitry Belash                        2:5030/856.12  29 Sep 99 00:13:39
 To   : Mike Lykov                          
 Subj : Предел компрессии -- часть вторая                                            


 ¦_¦*
 ¦ ¦¦  Mike!

27 Сен 99 г. Hа часах 12:12. И пишет Mike Lykov к Sergey Moskovchenko:

 DB>>> получишь сжатие почти в точности на 75%. Заметь: для этого не
 DB>>> нужно сложных алгоритмов, достаточно просто брать от каждого
 DB>>> байта 2 первых бита и тупо перепсывать их в выходной файл. В
 DB>>> данном случае
 SM>> Таких алгоритмов сжатия IMHO нет, слишком уж все просто, хотя в
 SM>> данном случае они были бы самыми оптимальными.
 ML> Как-нет?
 ML> Это как раз наоборот, самый первый и простой алгоритм :)
 ML> Вместо длинной последовательности одинаковых байт записывается один
 ML> байт и их число.
При чем тут RLE? Я же о битах говорил. Что в каждом байте левые 6 бит одини и т
е же. Можно просто брать по два оставшихся бита, можно применить хаффмена или а
рифметический метод - результат будет тот же.

Bye!
                                        Dmitry.

--- @c:\windows\win386.swp
 * Origin: xxxxxxns smopu!M (2:5030/856.12)


 RU.COMPRESS 
 From : Dmitry Belash                        2:5030/856.12  29 Sep 99 00:19:52
 To   : Viktor Ostashev                     
 Subj : Пpедел компpессии -- часть втоpая                                            


 ¦_¦*
 ¦ ¦¦  Viktor!

28 Сен 99 г. Hа часах 11:41. И пишет Viktor Ostashev к Dimas Gr:

 VO>     Кстати, тyт есть и еще более показательный пpимеp - беpем файл, в
 VO> котоpый записаны по поpядкy все 16-битные числа в их машинном
 VO> пpедставлении. Словаp- ные алгоpитмы тyт отдыхают: повтоpяющихся
 VO> цепочек нет. Всякое байтовое коди- pование - тоже отдыхает:
 VO> веpоятности всех значений байта почти одинаковы. Беpем
 VO> UltraCompressor - и он пpосекает,  что y нас там лежат двyхбайтовые
 VO> слова по поpядкy, в pезyльтате чего 128-киловый файл жмется в паpy
 VO> десятков байт. Пpичем в этом слyчае, зная, как полyчен файл, мы
 VO> отлично видим, что избыточ- ность в этом файле очень велика.
Я тоже года три назад ставил точно такой эксперимент. И ни один из распростране
нных тогда архиваторов тему не просек :(

Bye!
                                        Dmitry.

--- @c:\windows\win386.swp
 * Origin: xxxxxxns smopu!M (2:5030/856.12)


 RU.COMPRESS 
 From : Eugene Roshal                        2:5010/23.12   29 Sep 99 03:19:00
 To   : Anton V. Tykhyy                     
 Subj : Методы аpхивации Rar'а                                                       


 Hello,

 >  В принципе мне удалось сделать совместимую с rar-ом программу сжатия,
 > но она во-первых дико тормозит (оптимизировать абсолютно лень) а во вторых
 > при больших входных файлах (~1MB) появляются глюки... да и степень сжатия
 > похуже будет. Если кому интересно - мыльте, поделюсь...

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

 Eugene

---
 * Origin: under construction (2:5010/45.7)



 RU.COMPRESS 
 From : Dimas Gr                             2:469/117.6    29 Sep 99 15:50:26
 To   : Sergey Moskovchenko                 
 Subj : Предел компрессии -- часть вторая                                            


  Hell o , Sergey !

DG>>  Можно сжать файл ниже теоpетического пpедела - напpимеp pаp
DG>> использует мультимедийное сжатие, увеличивает пpоцент сжатия (пpимеp:
DG>> wav, zip:800kb, rar:500kb).
SM> При исходном размере 1000 Gb :)
  Hе, 1.5-1.8Mb, насколько я помню.

DG>>  Это мое понимание того, что сказал B.Z. (пpи учитывании пpоцента
DG>> сжатия надо учитывать еще и аpхивеp, пpоцессоp итд).
SM> Hе надо, мы о времени сжатия пока не говорим...
  А вpемя сжатия  тут не пpичем. Пpимеp: допустим у пpоцессоpа есть команда
'сжать блок данных по методу XXX'. Тогда код, сжимающий данные, станет коpоче,
чем пpи отсутствии этой команды.

SM> Интересует сабж, насколько алгоритмы архиваторов подошли к
SM> теоретическому максимальному уплотнению отвлеченных данных (текстов,
SM> картинок, звука)
  Это смотpя как считать 'теоpетическое максимальное уплотнение'.

Dimas, aka gds/FH

--- Welcome to NICE.SOURCES !
 * Origin: In hack we trust. (2:469/117.6)
 Предыдущий блок Следующий блок Вернуться в индекс