[an error occurred while processing this directive][an error occurred while processing this directive][an error occurred while processing this directive]
— 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)
[an error occurred while processing this directive][an error occurred while processing this directive]