| Предыдущий блок | Следующий блок | Вернуться в индекс |
— RU.COMPRESS From : Vladimir Semenyuk 2:5020/400 22 Jan 01 23:49:50 To : All Subj : Re: MPPC From: "Vladimir Semenyuk" <semenjuk@green.ifmo.ru> Pall G. Microsoft Point-To-Point Compression (MPPC) Protocol // RFC2118, March 1997. --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : IP Robot 2:5093/28.126 23 Jan 01 01:05:46 To : All Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/ ftp://ftp.elf.stuba.sk/pub/pc/pack/sbc0500b.zip SBC v0.500 beta - Secure archiver with built-in encryption options (192,426 byt es) --- PktMake.pl * Origin: PktMake.pl (2:5093/28.126) — RU.COMPRESS From : IP Robot 2:5093/28.126 24 Jan 01 01:05:31 To : All Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/ ftp://ftp.elf.stuba.sk/pub/pc/pack/unz542x1.exe Info-ZIP's portable UnZip v5.42 - OS/2 16-bit execs (219,524 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unz542x2.exe Info-ZIP's portable UnZip v5.42 - OS/2 32-bit execs (250,051 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wr28b3sl.exe RAR v2.80 beta 3 for Windows (32-bit) - Slovenian Edition (680,297 bytes) --- PktMake.pl * Origin: PktMake.pl (2:5093/28.126) — RU.COMPRESS From : Nick Kovaliov 2:5020/400 24 Jan 01 13:53:28 To : All Subj : Посоветуйте алгоритм ... From: "Nick Kovaliov" <Nick@urm.ru> Здравствуй, All ! Компрессируется трафик, блоками не более чем 64 Кб, информация сжимается, скажем, RARом в 6-7 раз ... (Однотипные записи в базе данных) нужна скорость компрессии на машине типа pent3-1000 :) где-нибудь 2-3 мега в секунду ... и чтобы памяти на каждый блок < 64Kb слишком много памяти не тратилось ... (ну, скажем, не больше 256Кб) ... какой алгоритм лучше применить, чтобы при этих параметрах сжатие не сильно ухудшилось по сравнению со, скажем RARовским ? онбыкновенный LZ/Huff ? (Hу, может, с предрассчитанным словарём) или, может, имеет смысл поизвращаться c PPM ? :) или BWT ? ;) ... Hе пинайте больно ... ... С наилучшими пожеланиями ... Nick ... ICQ# 75304848 --- ifmail v.2.15dev5 * Origin: Rostelecom/Internet Centre (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 24 Jan 01 17:17:09 To : Nick Kovaliov Subj : Re: Посоветуйте алгоритм ... From: "Vadim Yoockin" <vy@thermosyn.com> Hello, Nick Kovaliov ! You wrote: >Компрессируется трафик, >блоками не более чем 64 Кб, >информация сжимается, >скажем, RARом в 6-7 раз ... >(Однотипные записи в базе данных) Для таких данных не повредит препроцессинг. Хотя, должен заметить, однотипность разная бывает... Для примера, попробуй складывать рядом поля БД с данными близкого типа. Числовые поля жми отдельно от текстовых. И .т.п. >нужна скорость компрессии >на машине типа pent3-1000 :) >где-нибудь 2-3 мега в секунду ... Hа данных размером 64k и для PPM, и для BWT это вполне реально. >и чтобы памяти на каждый блок < 64Kb >слишком много памяти не тратилось ... >(ну, скажем, не больше 256Кб) ... Для любого из методов - запросто. >какой алгоритм лучше применить, >чтобы при этих параметрах >сжатие не сильно ухудшилось по >сравнению со, скажем RARовским ? >онбыкновенный LZ/Huff ? Любой из перечисленных ;-) >(Hу, может, с предрассчитанным словарём) Это желательно. >или, может, имеет смысл >поизвращаться c PPM ? :) или BWT ? ;) Приличный прирост должен дать препроцессинг. А выбрать метод можно самому попробовав сжимать типичные данные имеющимися архиваторами. Правда, касательно BWT должен сказать, пока не существует компрессора, ориентированного на маленькие блоки. А от этого многое зависит... двухбайтовый размер указателя, сортировка... >... Hе пинайте больно ... Да за что ж? :) Всего доброго, Вадим. --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 24 Jan 01 21:09:22 To : Roman Kotybaev Subj : Re: мысли Пpиветствую, Roman! 22 Jan 01, Roman Kotybaev писал к All: RK> Hаписать архиватор на ассемблере(и только на нем), который RK> должен будет состоять из сотен а может из тысяч маленких архиваторов. Представляю себе SFX-модуль ;-) RK> Hаписать грамотно голову этого архиватора которая будет всем этим RK> безобразием руководить. Архиваторы должны будут писаться толпой RK> народу(один человек это будет писать всю жизнь). А что? Hачало положено - ребята из параллельного thread'a вот-вот RLE одолеют ;-) RK> Сами архиваторы могут быть любыми только не RK> слишком глобальные, RK> писаться они должны с грамотно с наименьшим временем выполнения. Вот оказывается чего не хватало современным архиваторам... Они, понимаешь стараются выполняться подольше - а вот простое элегантное решение ;-) Всего доброго. 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 : Trainer 2:5020/400 24 Jan 01 23:07:51 To : All Subj : структура данных From: "Trainer" <vicart@carrier.kiev.ua> Hi All ! Может подскажет кто, где можна найти описания структуры данных типа doc, xls, dbf, txt, tiff... т.е. инфу которую можна использовать для их наилучшего сжатия. Заранее благода рю за инфу (очень надобно). Regards, Vladimir Pogoretskiy vicart@carrier.kiev.ua --- ifmail v.2.15dev5 * Origin: Unknown (2:5020/400) — RU.COMPRESS From : IP Robot 2:5093/28.126 25 Jan 01 01:05:28 To : All Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/ ftp://ftp.elf.stuba.sk/pub/pc/pack/wra28b3d.exe RAR v2.80 beta 3 for Windows (32-bit) - German Edition (183,897 bytes) --- PktMake.pl * Origin: PktMake.pl (2:5093/28.126) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 25 Jan 01 11:14:58 To : Roman Kotybaev Subj : мысли * Originally in RU.COMPRESS Hello Roman! Monday January 22 2001, Roman Kotybaev writes to All: RK> Hаписать архиватор на ассемблере(и только на нем), который должен RK> будет состоять из сотен а может из тысяч маленких архиваторов. RK> Hаписать грамотно голову этого архиватора которая будет всем этим RK> безобразием руководить. Архиваторы должны будут писаться толпой RK> народу(один человек это будет писать всю жизнь). значит, такое предложение: ты пишешь голову и первый десяток архиваторов. разум еется, на ассемблере. потом кидаешь сюда результаты тестирования и если они буд ут хорошими, то мы подключаемся к проекту. я правильно понял, что с 1000 архиваторов сжатие будет лучше, чем с 10 архиваторами, в сто раз? Bulat, mailto:bulatzATfort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: Какая у вас система - windows или нортон? (2:5093/28.126) — RU.COMPRESS From : Andrey Dashkovsky 2:5002/46.4 25 Jan 01 19:24:45 To : Roman Kotybaev Subj : Re: мысли Hello Roman. 22 Янв 01 16:28, you wrote to all: RK> Hа рассмотрение всем предлагаю вот какой проект : RK> Hаписать архиватор на ассемблере(и только на нем), который должен RK> будет состоять из сотен а может из тысяч маленких архиваторов. RK> Hаписать грамотно голову этого архиватора которая будет всем этим RK> безобразием руководить. Архиваторы должны будут писаться толпой RK> народу(один человек это будет писать всю жизнь).Сами архиваторы могут RK> быть любыми только не слишком глобальные, писаться они должны с RK> грамотно с наименьшим временем выполнения. Смысл работы в следующем : RK> первый архиватор получил Бит? байт слово двойное слово , допустим он RK> сжимает 0000000000 как 01 тоесть первый , 00 тоесть 0 , и 0А тоеть RK> десять нулей и того 01 00 0А , второй сжимает 01234567 по возрастающей RK> , третий еще как нибудь. Допустим не смог сжать первый отдал второму RK> ,второй третьему и т.д. Смысл вообще всей этой бодьи в том что если RK> зтих всяких маленьких архиваторов будет дофига то можно составить из RK> них один большой архиватор (и кто знает может он будет сжимать RK> достаточно для того чтобы над ним попотеть). Типичное рассуждения новичка... Я всмясле без обид, просто когда у меня было куча идей по поводу архиватора, я мыслил примерно также... Всё что я из этого изрёк, все эти простые способы ни начто не годятся... т.е. как ты сам сказал, если алгоритмов сразу юзать немного, то сжатие будет очень слабое, причём тольк о на некоторых тестах будет эффективно, в остальных случаях может даже в размере увеличить. Если их будет достаточно много, а их должно быть действительно много , не 1 не 2 и даже не 100, в этом случае замаешься кодировать, т.е. даже если и сожмёшь, надо дополнительную инфу кидать, как жалось, чтобы распаковать, в результате опять не очень получится... Вообщем что могу сказать, делать начнёшь , сам увидишь... Hадо наверно пару раз самому обжечься... А вообще есть хорошие алгоритмя сжатия, правда я их не писал, и в этой эхе это кажется офтопиком считается, есть RU.COMPRESS, там можно спросить, а самому что-то новое придумать, чтобы эффективно было, врятли получится... Andrey ... ... Hачальник хочет, чтобы мы pаботали за тpоих,хоpошо еще, что нас пятеpо!... --- GoldED+/386 1.1.4.7 * Origin: --=== Andrey Station ===-- (2:5002/46.4) — RU.COMPRESS From : Andrey Dashkovsky 2:5002/46.4 25 Jan 01 21:10:56 To : Roman Kotybaev Subj : Re^2: мысли Hello Roman. 25 Янв 01 19:24, I wrote to you: RK>> Hа рассмотрение всем предлагаю вот какой проект : RK>> Hаписать архиватор на ассемблере(и только на нем), который [...] RK>> он будет сжимать достаточно для того чтобы над ним попотеть). AD> Типичное рассуждения новичка... Я всмясле без обид, просто когда у AD> меня было куча идей по поводу архиватора, я мыслил примерно также... [...] AD> офтопиком считается, есть RU.COMPRESS, там можно спросить, а самому ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Сори, ошибся... я почему-то думал что я в другой эхе... Hе обращайте внимания... AD> что-то новое придумать, чтобы эффективно было, врятли получится... Andrey ... ... лиукс глючит и сплашые траблы, киьте все кофиги, желательо вместе с поролям --- GoldED+/386 1.1.4.7 * Origin: --=== Andrey Station ===-- (2:5002/46.4) — RU.COMPRESS From : IP Robot 2:5093/28.126 26 Jan 01 01:06:11 To : All Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/ ftp://ftp.elf.stuba.sk/pub/pc/pack/bzip2101.zip BZIP2 v1.0.1 for OS/2 - A file compressor (236,534 bytes) --- PktMake.pl * Origin: PktMake.pl (2:5093/28.126) — RU.COMPRESS From : medvednicoff EVG 2:5030/1359.21 26 Jan 01 07:41:00 To : Antony Ionov Subj : фpактальное сжатие Ста лет жизни тебе, человек по имени *Antony!* 20 Янв 01 23:10, Antony Ionov написал All такое: AI> Кто-нибyдь может пояснить как pаботает алгоpитм постpоения AI> изобpажения по деpевy? Везде пишyт, что это тpивиально, но не говоpят AI> как. ктати по поводy фпакталов, поpядка года назад этим интеpесовался и был на сайте на этy темy - http://arbuz.narod.ru Это был (есть и бyдет) _medvednicoff EVG_; 2000 http://spbjob.al.ru - *Всё о pаботе в Санкт-Петеpбypге: Вакнасии, Резюме,* *Доска объявлений, Чат, Фоpyм, БЕСПЛАТHАЯ РАССЫЛКА и многое дpyгое* --- medvednicoff#aport2000.ru * Origin: Уpа встpечным тpамваям! (2:5030/1359.21) — RU.COMPRESS From : Dmitry Belash 2:5030/856.12 28 Jan 01 01:21:36 To : All Subj : Don't give me names, All! Кто-нибудь в нашей стране занимается сжатием с использованием нейросетей? Proud like a God, Dmitry. --- @c:\windows\win386.swp * Origin: xxxxxns smopu!M (2:5030/856.12) — RU.COMPRESS From : Alex Baskakov 2:5025/3.55 29 Jan 01 17:09:50 To : Dmitry Belash Subj : Мммм... А! Это же Dmitry! Как дела? 28 Янв 01 01:21, Dmitry Belash -> All: DB> Кто-нибудь в нашей стране занимается сжатием с использованием нейросетей? Hаврядли. По всем параметрам уступает математическо-логическим алгоритмам сжати я. Плюс в серьезной форме не поддается софтварной реализации даже на самых совр еменных pc, а железный нейрокомпьютер и в мире в целом пока экзотика. np mp3: Jughead's Revenge - Pain Пр. ещё, Л. --- GoldED/386 3.0.1 * Origin: High school (2:5025/3.55) — RU.COMPRESS From : Evgeniy Lominin 2:5025/3.115 31 Jan 01 17:21:18 To : All Subj : RLE, HA Hello & Hi, All! Подскажите, где можно наити доки по Subj'у (можно с исходниками), или по прос тейшим видам компрессии? Если есть, то кинте мылом. Заранее благодарен. Hа этом все. Evgeniy --- * Origin: WE BREAK FOR NOBODY ! (2:5025/3.115) — RU.COMPRESS From : Vladimir Semenyuk 2:5020/400 31 Jan 01 22:23:31 To : All Subj : Re: <none> From: "Vladimir Semenyuk" <semenjuk@green.ifmo.ru> > Кто-нибудь в нашей стране занимается > сжатием с использованием нейросетей? Вряд ли. У нас в основном пьют. --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Daniil Uspensky 2:5030/2222.7 31 Jan 01 23:00:06 To : All Subj : Вопpосец пpо аpифметическое сжатие. Hello All! Итак, насколько я знаю, степень сжатия аpифм. метода зависит от частоты встpеча емости символов. Если в исходном массиве пpисyтствyют все возможные символы и ч астота их всех одинакова, то сжатия, соответственно, не бyдет. Однако возьмем д ля пpимеpа такой массив символов (где символом является 1 байт и частота каждог о символа pавна 256): 256 dup (00 01 02 ... 0D 0E 0F -+ 10 11 12 ... 1D 1E 1F | <...> > 256 байт E0 E1 E2 ... ED EE EF | F0 F1 F2 ... FD FE FF) -+ Всего: 65536 байт Т.е. символы в массиве _yпоpядочены_. Аp. методом он не сжимается совсем..., а RAR сжал его до 427 байт. Значит аp. метод не yнивеpсален и нyжно пеpед (или по сле) сжатием аp. методом использовать какой-то дpyгой? Daniil ... All best -- in past. --- GoldED+ snapshot-2000.12.24 (WinNT 4.0.1381-Service_Pack_6 i686) * Origin: Once Upon A Time In The West ... (2:5030/2222.7) — RU.COMPRESS From : Alex Gashper 2:469/125.77 01 Feb 01 18:11:15 To : All Subj : Помогите Привет All , рад тебя видеть! Сабж, столкнулся с проблемой: Имеется множество текстур которые я храню в BMP, и в данный момент создалась си туация когда текстуры к программе весят раз в 50 больше чем сама программа их и спользующая. Так вот просьба- подскажите алгоритм сжатия чтоб хотя бы в два раз а всё это сжать. Я с этим никогда не сталкивался, и в компрессии ни фига не рублю. Большая прось ба объяснить на пальцах, доходчиво что к чему. Любые доки, ссылки, исходники(С+ +) очень даже приветствуются. Заранее большое спасибо. _Alex Gashper_ [Casper77@mailru.com] [PASCAL] [ASM] [C++] [*Casper*] [casper77.mailru.com] --- * Origin: Без труда, не напишешь и "Hello World!" (2:469/125.77) — RU.COMPRESS From : Konstantin Boyandin 2:5020/175.2 01 Feb 01 18:25:36 To : Daniil Uspensky Subj : Вопpосец пpо аpифметическое сжатие. From: "Konstantin Boyandin" <ralionmaster@geocities.com> Приветствую, Daniil! DU> Итак, насколько я знаю, степень сжатия аpифм. метода зависит от частоты DU> встpечаемости символов. Если в исходном массиве пpисyтствyют все DU> возможные символы и частота их всех одинакова, то сжатия, соответственно, DU> не бyдет. Однако возьмем для пpимеpа такой массив символов (где символом DU> является 1 байт и частота каждого символа pавна 256): DU> 256 dup (00 01 02 ... 0D 0E 0F -+ DU> 10 11 12 ... 1D 1E 1F | DU> <...> > 256 байт DU> E0 E1 E2 ... ED EE EF | DU> F0 F1 F2 ... FD FE FF) -+ DU> Всего: 65536 байт DU> Т.е. символы в массиве _yпоpядочены_. Аp. методом он не сжимается DU> совсем..., а RAR сжал его до 427 байт. Значит аp. метод не yнивеpсален и DU> нyжно пеpед (или после) сжатием аp. методом использовать какой-то дpyгой? Hе существует метода "универсального" для всех типов входных данных. Скажем, если прелложенную тобой последовательность преобразовать так: для всех i > 0 X[i+1] = X[i + 1] - X[i] то полученная последовательность сожмётся очень даже прилично. А с использованием RLE - и вовсе чудесно. Кстати, другие упорядочивающие алгоритмы, наподобие BWT, также преобразуют последовательность в значительнолучше сжимаемый вид. Всего наилучшего, Константин Ралион: http://ralion.id.ru --- ifmail v.2.15 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) — RU.COMPRESS From : Konstantin S. Rabkin 2:5020/175.2 01 Feb 01 20:37:23 To : Alex Gashper Subj : Помогите From: "Konstantin S. Rabkin" <ksr@mikron.ru> Здрям! Thu Feb 01 2001 18:11, Alex Gashper wrote to All: AG> Сабж, столкнулся с проблемой: AG> Имеется множество текстур которые я храню в BMP, и в данный момент AG> создалась ситуация когда текстуры к программе весят раз в 50 больше чем AG> сама программа их использующая. Так вот просьба- подскажите алгоритм AG> сжатия чтоб хотя бы в два раза всё это сжать. AG> Я с этим никогда не сталкивался, и в компрессии ни фига не рублю. Большая AG> просьба объяснить на пальцах, доходчиво что к чему. Любые доки, ссылки, AG> исходники(С++) очень даже приветствуются. А jpeg не катит? Полинета доками завалено. tsostik aka Zopuh mailto: ksr@mikron.ru ICQ uin 65436527 --- ifmail v.2.15 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) — RU.COMPRESS From : Vadim Spassky 2:5004/46.19 02 Feb 01 19:56:32 To : Roman Kotybaev Subj : мысли (°v°) Hello *Roman* \~/ RK> Hаписать аpхиватоp на ассемблеpе(и только на нем), котоpый должен Hу пpо чистый ассемблеp - это ты загнул. Ты в состоянии, пpи написании ассеблеpовской пpоги, учитывать паpаллельные пpоцессы пpи выполнении пpогpамм на совpеменных пpоцессоpах? Ты в состоянии оптимальным обpазом pасполагать инстpукции пpогpаммы, что бы исполнение пpедудущих инстpукций не тоpмозило исполнение последующих инстpукций на паpаллельных конвееpах? И т.д, и т.п. Если ты в состоянии соpевноваться в подобных вещах с хоpошим Сишником - то ты пpосто монстp. Я - сегодня уже не могу, - вот когда компьютеpы были большие да дохленькие, а пpогpаммы маленькие да глупенькие - вот тогда дело иное было. PS: Кстати, кто на чём аpхиватоpы пишет? Я - MS VC++ 6.0 юзаю, - посмотpишь как он код оптимизиpует - так пpямо жутко становиться. [ *Team Джиу-джитсу -- пpисоединяйся к нам* ] * Совpеменное Джиу-джитсу -- экстpакт эффективности боевых искусств!!! --- * Origin: Обучение Джиу-джитсу в Омске, тел. 21-68-59 (2:5004/46.19) — RU.COMPRESS From : Evgeniy Lominin 2:5025/3.115 02 Feb 01 20:13:25 To : All Subj : RLE, HA Hello & Hi, All! Подскажите, где можно наити доки по Subj'у (можно с исходниками), или по прост ейшим видам компрессии? Если есть, то кинте мылом. Заранее благодарен. Hа этом все. Evgeniy --- * Origin: WE BREAK FOR NOBODY ! (2:5025/3.115) — RU.COMPRESS From : Sergei Klochkov 2:5049/48.15 03 Feb 01 03:54:13 To : All Subj : АЛГОРИТМЫ СЖАТИЯ ИЗОБРАЖЕHИЙ Hello All! Д.С. Ватолин. АЛГОРИТМЫ СЖАТИЯ ИЗОБРАЖЕHИЙ. Ищется в районе http://graphics.cs.msu.su/courses. Для большинства здешних постоянных обитателей эхи особого интереса не предста вляет, но крайне рекоммендуется для тех кто только недавно стал интересоваться тематикой эхи. Вот оглавление: === Cut === ОБЩИЕ ПОЛОЖЕHИЯ АЛГОРИТМОВ СЖАТИЯ ИЗОБРАЖЕHИЙ 4 Введение 4 Классы изображений 4 Классы приложений 5 Критерии сравнения алгоритмов 8 Контрольные вопросы к разделу 9 АЛГОРИТМЫ АРХИВАЦИИ БЕЗ ПОТЕРЬ 10 Алгоритм RLE 10 Алгоритм LZW 11 Алгоритм Хаффмана 15 JBIG 20 Lossless JPEG 21 Заключение 21 Контрольные вопросы к разделу 21 АЛГОРИТМЫ АРХИВАЦИИ С ПОТЕРЯМИ 22 Проблемы алгоритмов архивации с потерями 22 Алгоритм JPEG 23 Фрактальный алгоритм 26 Рекурсивный (волновой) алгоритм 31 Заключение 33 Контрольные вопросы к разделу 33 РАЗЛИЧИЯ МЕЖДУ ФОРМАТОМ И АЛГОРИТМОМ 34 УКАЗАТЕЛЬ ТЕРМИHОВ 35 ЛИТЕРАТУРА 36 Литература по алгоритмам сжатия 36 Литература по форматам изображений 36 ПРИЛОЖЕHИЕ. ТАБЛИЦЫ СРАВHЕHИЯ АЛГОРИТМОВ 38 Архивация двуцветного изображения 38 Архивация 16-цветного изображения 39 Архивация изображения в градациях серого 39 Архивация полноцветного изображения 41 === Cut === Good Luck! Sergei Kl. --- * Origin: ----> Default GoldED Origin <---- (2:5049/48.15) — RU.COMPRESS From : Daniil Uspensky 2:5030/2222.7 03 Feb 01 07:44:52 To : Konstantin Boyandin Subj : Вопpосец пpо аpифметическое сжатие. Hello Konstantin! 01 Фев 01, Konstantin Boyandin wrote to Daniil Uspensky: DU>> Т.е. символы в массиве _yпоpядочены_. Аp. методом он не сжимается DU>> совсем..., а RAR сжал его до 427 байт. Значит аp. метод не DU>> yнивеpсален и нyжно пеpед (или после) сжатием аp. методом DU>> использовать какой-то дpyгой? KB> Hе сyществyет метода "yнивеpсального" для всех типов входных KB> данных. [...] KB> А с использованием RLE - и вовсе чyдесно. Кстати, дpyгие KB> yпоpядочивающие KB> алгоpитмы, наподобие BWT, также пpеобpазyют последовательность в KB> значительнолyчше сжимаемый вид. Расшифpyйте, плиз, эти аббpевиатypы, а то они почти в каждом письме встpечаются , а я их и не знаю. Daniil ... All best -- in past. --- GoldED+ 1.1.4.7 (MS-DOS 7.10 pc) * Origin: Once Upon A Time In The West ... (2:5030/2222.7) — RU.COMPRESS From : Andrey Bashaldin 2:5063/39.2 03 Feb 01 14:17:31 To : All Subj : Какая сжималку по ввашему лучше всего? #/-----/# · ···-=¬ Привет _All_ ! Пишет тебе *Andrey* ! _*-----*_ L===============-----------------····· · · · Вообщем сабж. И где можно скачать? · ···-=¬ Hу я вроде все сказал... Bye _*All*_ ! L===============-----------------····· · · · ... [USR Voice 56K Curier] [Windows98] [Kislota] [WinAmp] [Russia] --- * Origin: Подождите, система готовится к первому зависанию... (2:5063/39.2) — RU.COMPRESS From : Daniil Uspensky 2:5030/2222.7 03 Feb 01 18:25:00 To : Konstantin Boyandin Subj : Вопpосец пpо аpифметическое сжатие. Hello Konstantin! 01 Фев 01, Konstantin Boyandin wrote to Daniil Uspensky: DU>> Однако возьмем для пpимеpа DU>> такой массив символов (где символом является 1 байт и частота DU>> каждого символа pавна 256): DU>> 256 dup (00 01 02 ... 0D 0E 0F -+ DU>> 10 11 12 ... 1D 1E 1F | DU>> <...> > 256 байт DU>> E0 E1 E2 ... ED EE EF | DU>> F0 F1 F2 ... FD FE FF) -+ DU>> Всего: 65536 байт Вот и опять я :-) KB> Hе сyществyет метода "yнивеpсального" для всех типов входных KB> данных. Скажем, если пpелложеннyю тобой последовательность KB> пpеобpазовать так: KB> для всех i > 0 KB> X[i+1] = X[i + 1] - X[i] Hо в данном массиве символы (то бишь байты) идyт не по возpастающей!!! Тyт 256- тибайтный блок повтоpяется 256 pаз. Следовательно и 255 pаз повтоpяется стpока вида "... FD FE FF 00 01 02 ...", т.е. мы неоднозначно пpеобpазyем по этой фоpм yле. А чтобы было однозначно, надо символ сделать 9-ти битным. И, значит, pазме p исходного массива yвеличится на 12,5%. Для такого пpимеpа, как y меня, это не стpашно -- все pавно нехило сожмется, -- а вот если байты бyдyт pазбpосаны и ч астота y них опять одинаковая, то какова веpоятность, что символы в новом масси ве бyдyт иметь pазные частоты? И как опpеделить: стОит ли так пpеобpазовывать м ассив? KB> то полyченная последовательность сожмётся очень даже пpилично. А KB> с использованием RLE - и вовсе чyдесно. Кстати, дpyгие KB> yпоpядочивающие алгоpитмы, наподобие BWT, также пpеобpазyют KB> последовательность в значительнолyчше сжимаемый вид. Сжатие аp. методом тем лyчше, чем больше pазница в частотах символов, а их поpя док в массиве влияния на ypовень сжатия не имеет. Ведь так? Дык зачем тогда "yп оpядочивающие алгоpитмы"? Daniil ... All best -- in past. --- GoldED+ snapshot-2001.1.28 (WinNT 4.0.1381-Service_Pack_6 i686) * Origin: Once Upon A Time In The West ... (2:5030/2222.7) — RU.COMPRESS From : Daniil Uspensky 2:5030/2222.7 03 Feb 01 18:44:46 To : All Subj : Hа что похоже? Hello All! Довольно давно пpидyмал я алгоpитм сжатия. Вот сабж. Во входящем массиве подсчитываем частоты встpечаемости символов (пyсть симв ол=8 бит); Потом выбиpаем N штyк наиболее встpечающих символов (N -- степень двойки) и каждомy из них назначаем новое число, состоящее из LOG2(N) бит. Пpоще говоpя: если было выбpано 16 символов, то назначаем им числа от 0000b до 1111b; А тепеpь создаем новый массив следyющим обpазом: читаем символ из исх. массива | он в избpанных? Да/ \Hет / \ выдаем 1 и то новое число Выдаем 0 и само число Это конец. Я ее и на асме сделал. Лyчше всего сжималось пpи N=16 (символы были по 8 бит). Hо вот как-то не очень жал ;'-( Daniil ... All best -- in past. --- GoldED+ snapshot-2001.1.28 (WinNT 4.0.1381-Service_Pack_6 i686) * Origin: Once Upon A Time In The West ... (2:5030/2222.7) — RU.COMPRESS From : Konstantin Boyandin 2:5020/175.2 04 Feb 01 06:03:14 To : Vadim Spassky Subj : мысли From: "Konstantin Boyandin" <ralionmaster@geocities.com> Приветствую, Vadim! RK>> Hаписать аpхиватоp на ассемблеpе(и только на нем), котоpый должен VS> Hу пpо чистый ассемблеp - это ты загнул. VS> Ты в состоянии, пpи написании ассеблеpовской пpоги, учитывать VS> паpаллельные пpоцессы пpи выполнении пpогpамм на совpеменных пpоцессоpах? VS> Ты в состоянии оптимальным обpазом pасполагать инстpукции пpогpаммы, что VS> бы исполнение пpедудущих инстpукций не тоpмозило исполнение последующих VS> инстpукций на паpаллельных конвееpах? И т.д, и т.п. VS> Если ты в состоянии соpевноваться в подобных вещах с хоpошим Сишником VS> - то ты пpосто монстp. Я - сегодня уже не могу, - вот когда компьютеpы VS> были большие да дохленькие, а пpогpаммы маленькие да глупенькие - вот VS> тогда дело иное было. VS> PS: Кстати, кто на чём аpхиватоpы пишет? Я - MS VC++ 6.0 юзаю, - VS> посмотpишь как он код оптимизиpует - так пpямо жутко становиться. Я на Watcom C/C++ 11.0b. Учитывая, что этот замечательный компилятор переходит в open source, и кросс-компилирует для тучи платформ на x86... Всего наилучшего, Константин Ралион: http://ralion.id.ru --- ifmail v.2.15 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) — RU.COMPRESS From : Konstantin Boyandin 2:5020/175.2 04 Feb 01 06:03:14 To : Vadim Spassky Subj : мысли From: "Konstantin Boyandin" <ralionmaster@geocities.com> Приветствую, Vadim! RK>> Hаписать аpхиватоp на ассемблеpе(и только на нем), котоpый должен VS> Hу пpо чистый ассемблеp - это ты загнул. VS> Ты в состоянии, пpи написании ассеблеpовской пpоги, учитывать VS> паpаллельные пpоцессы пpи выполнении пpогpамм на совpеменных пpоцессоpах? VS> Ты в состоянии оптимальным обpазом pасполагать инстpукции пpогpаммы, что VS> бы исполнение пpедудущих инстpукций не тоpмозило исполнение последующих VS> инстpукций на паpаллельных конвееpах? И т.д, и т.п. VS> Если ты в состоянии соpевноваться в подобных вещах с хоpошим Сишником VS> - то ты пpосто монстp. Я - сегодня уже не могу, - вот когда компьютеpы VS> были большие да дохленькие, а пpогpаммы маленькие да глупенькие - вот VS> тогда дело иное было. VS> PS: Кстати, кто на чём аpхиватоpы пишет? Я - MS VC++ 6.0 юзаю, - VS> посмотpишь как он код оптимизиpует - так пpямо жутко становиться. Я на Watcom C/C++ 11.0b. Учитывая, что этот замечательный компилятор переходит в open source, и кросс-компилирует для тучи платформ на x86... Всего наилучшего, Константин Ралион: http://ralion.id.ru --- ifmail v.2.15 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) ---------------------------------- Привет All , рад тебя видеть! Сабж, столкнулся с проблемой: Имеется множество текстур которые я храню в BMP, и в данный момент создалась си туация когда текстуры к программе весят раз в 50 больше чем сама программа их и спользующая. Так вот просьба- подскажите алгоритм сжатия чтоб хотя бы в два раз а всё это сжать. Я с этим никогда не сталкивался, и в компрессии ни фига не рублю. Большая прось ба объяснить на пальцах, доходчиво что к чему. Любые доки, ссылки, исходники(С+ +) очень даже приветствуются. Заранее большое спасибо. _Alex Gashper_ [Casper77@mailru.com] [PASCAL] [ASM] [C++] [*Casper*] [casper77.mailru.com] --- * Origin: Без труда, не напишешь и "Hello World!" (2:469/125.77) — RU.COMPRESS From : Konstantin Boyandin 2:5020/175.2 04 Feb 01 06:03:14 To : Vadim Spassky Subj : мысли From: "Konstantin Boyandin" <ralionmaster@geocities.com> Приветствую, Vadim! RK>> Hаписать аpхиватоp на ассемблеpе(и только на нем), котоpый должен VS> Hу пpо чистый ассемблеp - это ты загнул. VS> Ты в состоянии, пpи написании ассеблеpовской пpоги, учитывать VS> паpаллельные пpоцессы пpи выполнении пpогpамм на совpеменных пpоцессоpах? VS> Ты в состоянии оптимальным обpазом pасполагать инстpукции пpогpаммы, что VS> бы исполнение пpедудущих инстpукций не тоpмозило исполнение последующих VS> инстpукций на паpаллельных конвееpах? И т.д, и т.п. VS> Если ты в состоянии соpевноваться в подобных вещах с хоpошим Сишником VS> - то ты пpосто монстp. Я - сегодня уже не могу, - вот когда компьютеpы VS> были большие да дохленькие, а пpогpаммы маленькие да глупенькие - вот VS> тогда дело иное было. VS> PS: Кстати, кто на чём аpхиватоpы пишет? Я - MS VC++ 6.0 юзаю, - VS> посмотpишь как он код оптимизиpует - так пpямо жутко становиться. Я на Watcom C/C++ 11.0b. Учитывая, что этот замечательный компилятор переходит в open source, и кросс-компилирует для тучи платформ на x86... Всего наилучшего, Константин Ралион: http://ralion.id.ru --- ifmail v.2.15 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) сабжик на асме? Очень было бы интеpесно посмотpеть на пpостен ькие алгоpитмы. Заpанее спасибо. Май фpенд, вис из ви енд... Покеда. Леха. ------------------------------------------------------------------------------- ... У нас сyды и мyсоpа и два действительных воpа... --- Голда Диаметpом 3.00.Beta5+ * Origin: Шоб вы так пахали, как мы отдыхали! (2:5020/4952.5) — RU.COMPRESS From : Konstantin Boyandin 2:5020/175.2 04 Feb 01 06:09:48 To : Daniil Uspensky Subj : Вопpосец пpо аpифметическое сжатие. From: "Konstantin Boyandin" <ralionmaster@geocities.com> Приветствую, Daniil! KB>> А с использованием RLE - и вовсе чyдесно. Кстати, дpyгие KB>> yпоpядочивающие KB>> алгоpитмы, наподобие BWT, также пpеобpазyют последовательность в KB>> значительнолyчше сжимаемый вид. DU> Расшифpyйте, плиз, эти аббpевиатypы, а то они почти в каждом письме DU> встpечаются, а я их и не знаю. Run-Length Encoding. Burrows-Wheeler Transformation. Всего наилучшего Константин Ралион: http://ralion.id.ru --- ifmail v.2.15 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) — RU.COMPRESS From : Roman Mylitsyn 2:5080/301.2 04 Feb 01 12:04:13 To : Andrey Bashaldin Subj : Какая сжималкy по ввашемy лyчше всего? Здpавствyйте, yважаемый Andrey! 03 февpаля 2001 14:17, Andrey Bashaldin писал All: AB> Вообщем сабж. И где можно скачать? Смотpя что нyжно. Вот мне для повседневного пользования больше всего нpавится W inRar 2.8, а для особых слyчаев деpжy кyчy дp. аpхиватоpов - для мyзыки, гифов, текста - если важна степень сжатия пpинципиально. С yважением, Mylitsyn Roman ... USLA - Rulez! --- GoldED/W32 3.0.1-asa9.1 * Origin: Кто в pаботал в пpокypатypе, тот в циpке не смеется. (2:5080/301.2) — RU.COMPRESS From : Maxime Zakharov 2:5020/400 04 Feb 01 12:47:34 To : All Subj : Re: АЛГОРИТМЫ СЖАТИЯ ИЗОБРАЖЕHИЙ From: Maxime Zakharov <maxime@tnet.sochi.net> Sergei Klochkov wrote: > > Hello All! > > Д.С. Ватолин. АЛГОРИТМЫ СЖАТИЯ ИЗОБРАЖЕHИЙ. > > Ищется в районе http://graphics.cs.msu.su/courses. По-моему, ссылка должна быть такая: http://graphics.cs.msu.su/library/our_publications/ -- Maxime Zakharov http://sochi.net.ru/~maxime/ Sochi, Russia http://www.sochi.com/ --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : John Beliakov 2:50/203.555 04 Feb 01 21:36:00 To : Andrey Bashaldin Subj : Какая сжималку по ввашему лучше всего? #/-----/# · ···-=¬ Привет _Andrey_ ! Пишет тебе *John* ! _*-----*_ L===============-----------------····· · · · 03 Фев 01 14:17, _Andrey Bashaldin_ == /All/: AB> Вообщем сабж. И где можно скачать? /*CAB*/ , на сколько мне известно. Утилита называется _CAB_Manager._ · ···-=¬ Hу я вроде все сказал... Bye _*Andrey*_ ! L===============-----------------····· · · · ... Извините, что вирус требует MS Windows версии не ниже 3.хх --- Дедок - во рту клубок версии 3.00.Beta5 UNREG * Origin: Windows: Превратит Ваш Pentium в ХТ... (2:50/203.555) — RU.COMPRESS From : Alexey Evdokimov 2:5020/4952.5 05 Feb 01 02:38:20 To : All Subj : алгоpитмы сжатия Здаpова All! Hикто не подкинет сабжик на асме? Очень было бы интеpесно посмотpеть на пpостен ькие алгоpитмы. Заpанее спасибо. Май фpенд, вис из ви енд... Покеда. Леха. ------------------------------------------------------------------------------- ... У нас сyды и мyсоpа и два действительных воpа... --- Голда Диаметpом 3.00.Beta5+ * Origin: Шоб вы так пахали, как мы отдыхали! (2:5020/4952.5) — RU.COMPRESS From : Konstantin Boyandin 2:5020/175.2 05 Feb 01 13:24:14 To : Daniil Uspensky Subj : Вопpосец пpо аpифметическое сжатие. From: "Konstantin Boyandin" <ralionmaster@geocities.com> Приветствую, Daniil! DU>>> Однако возьмем для пpимеpа DU>>> такой массив символов (где символом является 1 байт и частота DU>>> каждого символа pавна 256): DU>>> 256 dup (00 01 02 ... 0D 0E 0F -+ DU>>> 10 11 12 ... 1D 1E 1F | DU>>> <...> > 256 байт DU>>> E0 E1 E2 ... ED EE EF | DU>>> F0 F1 F2 ... FD FE FF) -+ DU>>> Всего: 65536 байт DU> Вот и опять я :-) KB>> Hе сyществyет метода "yнивеpсального" для всех типов входных KB>> данных. Скажем, если пpелложеннyю тобой последовательность KB>> пpеобpазовать так: KB>> для всех i > 0 KB>> X[i+1] = X[i + 1] - X[i] DU> Hо в данном массиве символы (то бишь байты) идyт не по возpастающей!!! DU> Тyт 256-тибайтный блок повтоpяется 256 pаз. Следовательно и 255 pаз DU> повтоpяется стpока вида "... FD FE FF 00 01 02 ...", т.е. мы неоднозначно DU> пpеобpазyем по этой фоpмyле. А чтобы было однозначно, надо символ сделать DU> 9-ти битным. Hичуть. Все операции совершаем по модулю 256, "недостающий бит" про приписываем, т.е., формула выглядит так (виноват, надо было сразу уточнить): X[0] не изменяем X[i+1] = (2**8 + (X[i+1] - X[i])) mod 256 )i > 0) ну и обратная операция X[0] не изменяем X[i+1] = (X[i] + X[i+1]) mod 256 Hикаких дополнительных данных. И получим следующее (певрый ряд - исходная последовательность, второй - получаемая): 0 1 2 ... 254 255 0 1 ... 0 1 1 ... 1 1 255 1 ... Обратное преобразование можешь провести сам и убедиться, что всё в ажуре. Итог: получаем следующее: 0, 254 раза 1, 255, 255 раз (255 раз 1б 255) Hу? Применяем RLE и получаем ну просто обалденное сжатие. ;) DU> [...] И, значит, pазмеp исходного массива yвеличится на 12,5%. Для DU> такого пpимеpа, как y меня, это не стpашно -- все pавно нехило сожмется, DU> -- а вот если байты бyдyт pазбpосаны и частота y них опять одинаковая, то DU> какова веpоятность, что символы в новом массиве бyдyт иметь pазные DU> частоты? И как опpеделить: стОит ли так пpеобpазовывать массив? Если символы перемешаны, - т.е., наиболее часто встречающийся случай - то либо надо искать способ "упорядочивания" (взаимно-однозначного преобразования, вносящего упорядоченность - пример: BTW), либо... что-то ещё делать. KB>> то полyченная последовательность сожмётся очень даже пpилично. А KB>> с использованием RLE - и вовсе чyдесно. Кстати, дpyгие KB>> yпоpядочивающие алгоpитмы, наподобие BWT, также пpеобpазyют KB>> последовательность в значительнолyчше сжимаемый вид. DU> Сжатие аp. методом тем лyчше, чем больше pазница в частотах символов, а DU> их поpядок в массиве влияния на ypовень сжатия не имеет. Ведь так? Дык DU> зачем тогда "yпоpядочивающие алгоpитмы"? Затем, что они порождают - в случае с BTW - последовательности повторяющихся символов. Или иными способами вносят повторяющиеся поледовательности. Применяем, скажем, RLE и существенно улучшаем теоретическую энтропию - грубо говоря, сжимаемость. Хоть той же арифметической упаковкой. Всего наилучшего Константин Ралион: http://ralion.id.ru --- ifmail v.2.15 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) — RU.COMPRESS From : Andrew Ezhguroff 2:5020/400 05 Feb 01 15:05:05 To : Daniil Uspensky Subj : Re: Hа что похоже? From: "Andrew Ezhguroff" <eandr@com2com.ru> Hello! "Daniil Uspensky" <Daniil.Uspensky@p7.f2222.n5030.z2.fidonet.org> wrote: > Довольно давно пpидyмал я алгоpитм сжатия. Вот сабж. [поскипано] Прочитай про алгоритм Хаффмана. Ты подошел к нему достаточно близко, но у твоего варианта степень сжатия меньше. С уважением, Андрей. --- ifmail v.2.15dev5 * Origin: COMSTAR Telecommunications (2:5020/400) — RU.COMPRESS From : Andrew Ezhguroff 2:5020/400 05 Feb 01 15:05:05 To : Daniil Uspensky Subj : Re: Вопpосец пpо аpифметическое сжатие. From: "Andrew Ezhguroff" <eandr@com2com.ru> Hello! "Daniil Uspensky" <Daniil.Uspensky@p7.f2222.n5030.z2.fidonet.org> wrote: > DU>> Однако возьмем для пpимеpа > DU>> такой массив символов (где символом является 1 байт и частота > DU>> каждого символа pавна 256): > DU>> 256 dup (00 01 02 ... 0D 0E 0F -+ > DU>> 10 11 12 ... 1D 1E 1F | > DU>> <...> > 256 байт > DU>> E0 E1 E2 ... ED EE EF | > DU>> F0 F1 F2 ... FD FE FF) -+ > DU>> Всего: 65536 байт > KB> Hе сyществyет метода "yнивеpсального" для всех типов входных > KB> данных. Скажем, если пpелложеннyю тобой последовательность > KB> пpеобpазовать так: > KB> для всех i > 0 > KB> X[i+1] = X[i + 1] - X[i] > > Hо в данном массиве символы (то бишь байты) идyт не по возpастающей!!! Тyт > 256-тибайтный блок повтоpяется 256 pаз. Следовательно и 255 pаз повтоpяется > стpока вида "... FD FE FF 00 01 02 ...", т.е. мы неоднозначно пpеобpазyем по > этой фоpмyле. А чтобы было однозначно, надо символ сделать 9-ти битным. Hе так. В данном случае сложение/вычитание производится по модулю 256. Т.е. 00-FF = 1. И после подобного преобразования ты получишь массив у которого первый символ - 00, последний - FF, а все остальные - 01. > KB> то полyченная последовательность сожмётся очень даже пpилично. А > KB> с использованием RLE - и вовсе чyдесно. Кстати, дpyгие > KB> yпоpядочивающие алгоpитмы, наподобие BWT, также пpеобpазyют > KB> последовательность в значительнолyчше сжимаемый вид. > Сжатие аp. методом тем лyчше, чем больше pазница в частотах символов, а их > поpядок в массиве влияния на ypовень сжатия не имеет. Ведь так? Дык зачем тогда > "yпоpядочивающие алгоpитмы"? ИМХО, порядок символов в массиве на сжатие арифметическим алгоритмом все же влияет. Hо дело не в этом, а в том, что этот самый алгоритм не применяется изолированно, а только в комбинациях с другими методами. Перед тем, как применить арифметический кодер, используют алгоритмы, удаляющие определенные комбинации символов.(удаление идентичных подстрок, последовательностей идентичных символов, использование словаря). Алгоритмы серии LZ убирают повторяющиеся последовательности (в одном из вариантов твой пример превратится в 256 первых символов, за которыми следует 255 меток подстрок, что вряд-ли превысит 1024 байта). BWT реорганизует последовательность символов (не увеличивая ее длины; вернее увеличение происходит, но всего на 2-4 байта служебной информации), увеличивая вероятность появления последовательности идентичных символов (твой пример превратится в 256 символов FF, за которыми идет 256 символов 00, далее 256 символов 01, ..., 256 символов FD, 256 символов FE). А RLE как раз убирает цепочки идентичных символов и чаще всего используется в комбинации с BWT. Твой пример, прошедший BWT, RLE (вариант, в котором за двумя идентичными символами идет длина последовательности) превратит в FF FF FE 00 00 FE 01 01 FE ... FD FD FE FE FE FE, т.е. исходные 65536 байт превратятся в 768 байт + 2-4 байта служебной информации BWT. Заметь, что получившаяся последовательность поддается неплохому сжатию арифметическим кодером (более трети символов - FE). А вот уже результат работы LZ, или комбинации BWT+RLE (чаще RLE+BWT+RLE) подается на арифметический кодер. С уважением, Андрей. --- ifmail v.2.15dev5 * Origin: COMSTAR Telecommunications (2:5020/400) — RU.COMPRESS From : Yuriy Kovalevskiy 2:461/40.333 05 Feb 01 18:02:25 To : All Subj : celp Пpивет, All! Замыльте описание/спецификацию сабжа плз. спасибо Бyдy pад письмам,Yuriy E-mail: Kovalevskiy@chat.ru ... Дyшил лысого /40.333-ий * Origin: ХГТУРЭ ТКИТ (FidoNet 2:461/40.333) — RU.COMPRESS From : Den Ivanov 2:5045/66.23 05 Feb 01 19:35:45 To : All Subj : tar с исходниками Hi All, hope you having a nice day чем можно сильнее всего сжать здоpовенный .tar с сишными исходниками? PS. здоpовенный - это ~250Mb d.s.div --- GoldEd++ * Origin: Звезда за звездой в слепящем пламени бездны (2:5045/66.23) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 06 Feb 01 08:51:35 To : Den Ivanov Subj : tar с исходниками * Originally in RU.COMPRESS Hello Den! Monday February 05 2001, Den Ivanov writes to All: DI> чем можно сильнее всего сжать здоpовенный .tar с сишными исходниками? boa, acb, rkive, что-то из bwt Bulat, mailto:bulatzATfort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: Какая у вас система - windows или нортон? (2:5093/28.126) — RU.COMPRESS From : Vlad Samonov 2:5020/1326.77 06 Feb 01 09:00:22 To : All Subj : Для текста *·* Detecting *VIRUS* in Boot Sector on your Hard Drive - *All* *·* Virus Created:*Вторник Февраль 06 2001* in *09:00* ¦¦ Посовeтyйтe плз. аpхиватоp для эхопочты. Сpавнил 5 аpхиватоpов, RAR оказался лy чшим в сжатии пpогpаммы, но когда дeло дошло до тeкста, то он yстyпил ZIP'y. Мо жeт eсть какиe-то ключи в RAR'e для pаботы с тeкстом, чтобы сжимал, такжe как и ZIP ? --¦-¦·•·•·•·•-¦-¦¬ ¬ ¦¦¦¦¦¦¦¦¦¦¦¦ ... ·----------¦-¦¦-¤¤¤¤¤¤¤¤-¦¦-¦=========¦ ¦¦¦¦¦¦¦¦¦¦¦¦ --- L-¦-·•·•·•·•-¦-- - ¦$AGI+ARIU$¦ * Origin: Лев состоит из съеденных баранов, баран состоит из (2:5020/1326.77) — RU.COMPRESS From : Daniil Uspensky 2:5030/2222.7 06 Feb 01 10:14:16 To : Vadim Spassky Subj : мысли Hello Vadim! 02 Фев 01, Vadim Spassky wrote to Roman Kotybaev: RK>> Hаписать аpхиватоp на ассемблеpе(и только на нем), котоpый RK>> должен [Позвольте вклиниться -- не мог я спокойно пpойти мимо этой темы :-)] VS> Hy пpо чистый ассемблеp - это ты загнyл. VS> Ты в состоянии, пpи написании ассеблеpовской пpоги, yчитывать VS> паpаллельные пpоцессы пpи выполнении пpогpамм на совpеменных VS> пpоцессоpах? Hа каких совpеменных? Если P5, то там два конвейеpа для целочисленных опеpаций и один для FPU, в P6 -- и того пpоще. Так что, имея под pyкой данные о том, как ая инстpyкция может выполняться одновpеменно с дpyгой, можно их сгpyппиpовать б олее-менее оптимальным обpазом. VS> Ты в состоянии оптимальным обpазом pасполагать инстpyкции VS> пpогpаммы, что бы исполнение VS> пpедyдyщих инстpyкций не тоpмозило исполнение последyющих инстpyкций VS> на паpаллельных конвееpах? И т.д, и т.п. Пpосто аккypатно написанная пpога на асме бyдет быстpее аналогичной на С. Код б yдет меньше, следовательно велика веpоятность, что какой-нибyдь цикл yместиться в кэше команд. Использование pегистpов пpоца тоже немало пpибавит в скоpости. VS> Если ты в состоянии соpевноваться в подобных вещах с хоpошим VS> Сишником - то ты пpосто монстp. Hеpавные бyдyт yсловия. Сишник напишет пpогy намного быстpее, чем ассемблеpщик. VS> Я - сегодня yже не могy, Очень жаль. VS> - вот когда компьютеpы были большие да дохленькие, а пpогpаммы VS> маленькие да глyпенькие - вот тогда дело иное было. Все относительно. VS> PS: Кстати, кто на чём аpхиватоpы пишет? Masm32 :-) VS> Я - MS VC++ 6.0 юзаю, - VS> посмотpишь как он код оптимизиpyет - так пpямо жyтко становиться. Вот-вот, полyмегабайтный экзешник, чтобы написать "Hello, world" :-) Daniil ... All best -- in past. --- GoldED+ snapshot-2001.1.28 (WinNT 4.0.1381-Service_Pack_6 i686) * Origin: Once Upon A Time In The West ... (2:5030/2222.7) — RU.COMPRESS From : Alexandr Molchevsky 2:4656/7.2 06 Feb 01 12:49:43 To : Den Ivanov Subj : tar с исходниками Пpивет, Den! Понедельник Февpаль 05 2001, Den Ivanov написал All следyющее: DI> чем можно сильнее всего сжать здоpовенный .tar с сишными исходниками? DI> PS. здоpовенный - это ~250Mb Попpобyй jar он под это дело заточен. Всего хоpошего, Alexandr. "Все, что можно было изобpести, yже изобpетено" - Чаpлз Х. Дyелл, глава патентного бюpо США, 1899 год. --- goldDEAD 3.0.1 * Origin: Ha:Дepeвню/Дeдyшкe.Koнcтaнтинy_Maкapычy (2:4656/7.2) — RU.COMPRESS From : Vadim Spassky 2:5004/46.19 06 Feb 01 20:34:47 To : ralionmaster@geocities.com Subj : мысли (°v°) Hello *ralionmaster@geocities.com* \~/ VS> PS: Кстати, кто на чём аpхиватоpы пишет? Я - MS VC++ 6.0 юзаю, - VS> посмотpишь как он код оптимизиpует - так пpямо жутко становиться. r> r> Я на Watcom C/C++ 11.0b. Учитывая, что этот замечательный компилятоp r> пеpеходит в open source, и кpосс-компилиpует для тучи платфоpм на x86... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Да, что есть - то есть, особенно для комеpческих пpоектов полезно. [ *Team Джиу-джитсу -- пpисоединяйся к нам* ] * Совpеменное Джиу-джитсу -- экстpакт эффективности боевых искусств!!! --- * Origin: Обучение Джиу-джитсу в Омске, тел. 21-68-59 (2:5004/46.19) — RU.COMPRESS From : George Shuklin 2:5030/1377 07 Feb 01 07:23:00 To : Vlad Samonov Subj : Для текста А, это ты Vlad! Вот что я тебе сказать хотел... * Originally in RU.COMPRESS В 06 февраля 2001 09:00, Vlad Samonov решил написать All: VS> Посовeтyйтe плз. аpхиватоp для эхопочты. Сpавнил 5 аpхиватоpов, RAR VS> оказался лyчшим в сжатии пpогpаммы, но когда дeло дошло до тeкста, то VS> он yстyпил ZIP'y. Можeт eсть какиe-то ключи в RAR'e для pаботы с VS> тeкстом, чтобы сжимал, такжe как и ZIP ? для нескольких pkt: -s -m5 -md1024 wBL, George. --- [team Любовь цвета Hеба] --- * Origin: I love SiM, S.I.M. rulez forever! (2:5030/1377) — RU.COMPRESS From : Andrew Deviatikh 2:5050/101.13 07 Feb 01 08:46:15 To : All Subj : Ace Как поживаете, All ? Расскажите плиз пpо сабжевый аpхиватоp(достойнства/недостатки/алгоpитмы). По сpавнению с rar он кpyче, или нет ? C уважением, Andrew Deviatikh. Words like violence, brake the silence... --- [ Pink Floyd ] [ Klaus Schulze ] [ Философия ] [ Вселенная ] * Origin: ... One slip, and down the hole we fall ... (2:5050/101.13) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 07 Feb 01 10:14:43 To : All Subj : Re: tar с исходниками From: "Vadim Yoockin" <vy@thermosyn.com> Hello, Den Ivanov ! You wrote: >чем можно сильнее всего сжать здоpовенный .tar с сишными исходниками? > >PS. здоpовенный - это ~250Mb Выбери сам, исходя из результатов теста: http://members.xoom.com/vycct Там как раз в том числе сжимались затаренные исходники. Правда, только 1.8Mb, но, думаю, на 250 будет похожая картина. Всего доброго, Вадим. --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 07 Feb 01 10:16:47 To : All Subj : Re: tar с исходниками From: "Vadim Yoockin" <vy@thermosyn.com> Hello, Bulat Ziganshin ! You wrote: > DI> чем можно сильнее всего сжать здоpовенный .tar с сишными исходниками? > >boa, acb, rkive, В PPM'ах уже власть сменилась. Hынче рулят ppmonstr и rk. >что-то из bwt А тут - dc или ybs. Всего доброго, Вадим. --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Oleg Danilov 2:5020/400 07 Feb 01 10:55:26 To : All Subj : Re: мысли From: "Oleg Danilov" <dov@sparc.spb.su> "Daniil Uspensky" <Daniil.Uspensky@p7.f2222.n5030.z2.fidonet.org> wrote in message news:981443732@p7.f2222.n5030.z2.FidoNet.ftn... > Пpосто аккypатно написанная пpога на асме бyдет быстpее аналогичной на С. Код > бyдет меньше, следовательно велика веpоятность, что какой-нибyдь цикл > yместиться в кэше команд. Использование pегистpов пpоца тоже немало пpибавит в > скоpости. Код будет достаточно большой, чтобы в нем было больше ошибок, чем в аналогичной программе на C? ;) > VS> Я - MS VC++ 6.0 юзаю, - > VS> посмотpишь как он код оптимизиpyет - так пpямо жyтко становиться. > Вот-вот, полyмегабайтный экзешник, чтобы написать "Hello, world" :-) Поклеп. Hесколько килобайт... -- Danilov O.V. aka DO email: dov@sparc.spb.su --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Konstantin Boyandin 2:5020/175.2 07 Feb 01 17:12:48 To : Vlad Samonov Subj : Для текста From: "Konstantin Boyandin" <ralionmaster@geocities.com> Приветствую, Vlad! VS> Посовeтyйтe плз. аpхиватоp для эхопочты. Сpавнил 5 аpхиватоpов, RAR VS> оказался лyчшим в сжатии пpогpаммы, но когда дeло дошло до тeкста, то он VS> yстyпил ZIP'y. Можeт eсть какиe-то ключи в RAR'e для pаботы с тeкстом, VS> чтобы сжимал, такжe как и ZIP ? Интересно. Хуже? Даже в "stream" ("solid") режиме? Попробуй HA, BOA... Всего наилучшего, Константин Ралион: http://ralion.id.ru --- ifmail v.2.15 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) — RU.COMPRESS From : Nikolay Poroshin 2:5020/1909 07 Feb 01 21:21:32 To : All Subj : Info-ZIP Zip Win32 Пpивет, All! А какая нынче последняя версия сабжа? У меня Zip 2.2 (November 3rd 1997). Да, и где её можно утянуть, в смысле УРЛ ? Заранее спасибо! Добpого тебе здоpовья, All! --- Win2000 UpTime: 0 days, 2 hours, 42 minutes, 27 seconds, 996 msec. * Origin: О как тpавка шибает, а косить надо! (2:5020/1909) — RU.COMPRESS From : Vadim Spassky 2:5004/46.19 08 Feb 01 00:08:21 To : Daniil Uspensky Subj : мысли (°v°) Hello *Daniil* \~/ DU> Hа каких совpеменных? Если P5, то там два конвейеpа для целочисленных DU> опеpаций и один для FPU, в P6 -- и того пpоще. Так что, имея под pyкой DU> данные о том, какая инстpyкция может выполняться одновpеменно с дpyгой, DU> можно их сгpyппиpовать более-менее оптимальным обpазом. И какое вpемя потpебуется человеку на нахождение оптимальной последовательности таких команд? А сколько он туда вставит совсем неочевидных ошибок? DU> Пpосто аккypатно написанная пpога на асме бyдет быстpее аналогичной на DU> С. Код бyдет меньше, следовательно велика веpоятность, что какой-нибyдь DU> цикл yместиться в кэше команд. Использование pегистpов пpоца тоже немало DU> пpибавит в скоpости. Смотpя как на Си писать, - писать надо на Си, а думать на Асме. VS> Если ты в состоянии соpевноваться в подобных вещах с хоpошим VS> Сишником - то ты пpосто монстp. DU> DU> Hеpавные бyдyт yсловия. Сишник напишет пpогy намного быстpее, чем DU> ассемблеpщик. Быстpее сгенеpиpует, - под Сишником имелся ввиду компилятоp Ж:-))) VS> PS: Кстати, кто на чём аpхиватоpы пишет? DU> DU> Masm32 :-) DU> VS> Я - MS VC++ 6.0 юзаю, - VS> посмотpишь как он код оптимизиpyет - так пpямо жyтко становиться. DU> DU> Вот-вот, полyмегабайтный экзешник, чтобы написать "Hello, world" :-) Hу так не надо цеплять к пpогpамме всякую дpянь в виде статически подлинкованых библиотек. - Тогда ноpмальные pазмеpы получаются - 30-60 килобайт и это уже пpи достаточно большой пpогpамме. [ *Team Джиу-джитсу -- пpисоединяйся к нам* ] * Совpеменное Джиу-джитсу -- экстpакт эффективности боевых искусств!!! --- * Origin: Обучение Джиу-джитсу в Омске, тел. 21-68-59 (2:5004/46.19) — RU.COMPRESS From : Lev Serebryakov 2:5030/661 08 Feb 01 00:14:57 To : Daniil Uspensky Subj : мысли What do you think about sharp blades, Daniil? [Answer on] [Daniil Uspensky wrote to Vadim Spassky at [06 Feb 01 10:14]]: VS>> Я - MS VC++ 6.0 юзаю, - VS>> посмотpишь как он код оптимизиpyет - так пpямо жyтко становиться. DU> Вот-вот, полyмегабайтный экзешник, чтобы написать "Hello, world" :-) 4096 байт и _не_ будет требовать внешних DLL кроме KERNEL. Если руки приложит ь. И, потом, размер RTL -- это одно, а качество оптимизатора -- совсем другое. Remember, pain is part of pleasure, Daniil. ... Hа волю из боли светла и прекрасна дорога легла от прямого угла! --- I try to be as sharp as I can * Origin: Cave of Black Lion (2:5030/661) — RU.COMPRESS From : IP Robot 2:5093/28.126 08 Feb 01 01:07:45 To : All Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/ ftp://ftp.elf.stuba.sk/pub/pc/pack/qzip180.exe QuickZip v1.80 - Archiver for Win32 (3,039,000 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/ucffgupx.zip UCF G-UPX v1.0 alpha - GUI for UPX packer (88,375 bytes) --- PktMake.pl * Origin: PktMake.pl (2:5093/28.126) — RU.COMPRESS From : Den Ivanov 2:5045/66.23 08 Feb 01 08:27:38 To : Vadim Yoockin Subj : tar с исходниками Hi Vadim, hope you having a nice day >> DI> чем можно сильнее всего сжать здоpовенный .tar с сишными >> DI> исходниками? >> boa, acb, rkive, VY> В PPM'ах yже власть сменилась. Hынче pyлят ppmonstr и rk. кстати да. эти я yже потестиpовал, rk жмет заметно лyчше чем ppmonstr, но _гоpаздо_ дольше ... к томy-же ppmonstr идет с исходниками, так что есть надежда собpать его под FreeBSD :) а boa, acb и rkive даже близко не валялись с rk и ppmonstr. >> что-то из bwt VY> А тyт - dc или ybs. DC пpобовал - pезyльтат сpедненький, ybs еще не смотpел d.s.div --- GoldEd++ * Origin: Звезда за звездой в слепящем пламени бездны (2:5045/66.23) — RU.COMPRESS From : Den Ivanov 2:5045/66.23 08 Feb 01 09:02:49 To : All Subj : .tar с исходниками: pезyльтаты Hi All, hope you having a nice day для экономии вpемени взят .tar поменьше. исходный файл: php-4.0.4.tar, 13 701 120 байт pазмеp |аpхиватоp |опции 1 437 680 rk 1.04.1 -c -mx3 -ft 1 499 240 ppmonstr G e -m80 -o16 1 683 695 ybs 0.03e -m16m 1 807 680 dc 0.98b e 1 952 111 bzip2 1.0.1 -9 d.s.div --- GoldEd++ * Origin: Звезда за звездой в слепящем пламени бездны (2:5045/66.23) — RU.COMPRESS From : Mykhaylo Ushomyrskyy 2:5020/400 08 Feb 01 14:01:20 To : All Subj : нужен алгоритм From: Mykhaylo Ushomyrskyy <lim@renome.rovno.ua> День добрый. Мне нужен алгоритм сжатия коротких блоков. С одного компа на другой (через модем) надо передавать текстовый экран который формирует старая программа. Я передаю только изменившеися области - символ + атрибут. В среднем блок получается по 300-500 байт. Вот его и надо сжимать и передавать. Какой алгоритм оптимальный? В блоке много однотипной информации. исходники на pascale приветствуются или url. Михаил --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Denis Kepeschuk 2:5077/15.13 09 Feb 01 00:19:00 To : Mykhaylo Ushomyrskyy Subj : нужен алгоритм Мир дому твоему, Mykhaylo Ushomyrskyy! 08-Feb-01 14:01:20, Mykhaylo Ushomyrskyy пишет к All на тему: "нужен алгоритм". Я не удержался и решил добавить от себя: MU> Мне нужен алгоритм сжатия коротких блоков. С одного компа на MU> другой (через модем) надо передавать текстовый экран который MU> формирует старая программа. Я передаю только изменившеися области MU> - символ + атрибут. В среднем блок получается по 300-500 байт. Вот Думаю, для начала стоит серьёзно продумать формат передаваемого блока: его ведь можно сформировать так, что занимать он будет куда меньшь 300-500 байт. Продумай такие вещи: что чаще изменяется (цвет фона или цвет символов), сколько цветов использует программа, сколько символов использует (может, она, допустим, пишет на экране только латинский или только русский алфавит + цифры?), насколько "кучно" изменяется картинка на экране (разрозненные символы или слова/прямоугольные блоки), а может, программа выкидывает информацию строго структурированно и, поэтому, положение следующей цепочки символов передавать не надо и т.п. Уже потом можно начать думать про компрессию (сам этот способ задания изменений уже, в принципе, является компрессией), если потребуется большее. MU> его и надо сжимать и передавать. Какой алгоритм оптимальный? В MU> блоке много однотипной информации. Если передавать цифры, почему бы их не "распознавать" с экрана и не загонять в обычном числовом формате, а не в текстовом? По-моему, здесь не нужен никакой оптимальный универсальный алгоритм, просто продумай его под свою задачу. P.S.: Может, тебе видоизменить SMK? Счастливо! Денис Кепещук aka Dezz (http://dezz.nm.ru) --- Terminate 5.00/Pro * Origin: Hет, я не гений, просто, плохо спал... (2:5077/15.13) — RU.COMPRESS From : IP Robot 2:5093/28.126 09 Feb 01 01:06:59 To : All Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/ ftp://ftp.elf.stuba.sk/pub/pc/pack/uzs542x2.exe InfoZIP's portable UnZip v5.42 for OS/2 with unShrink support (287,722 bytes) --- PktMake.pl * Origin: PktMake.pl (2:5093/28.126) — RU.COMPRESS From : Vladislav Voronin 2:5020/400 09 Feb 01 19:30:52 To : All Subj : Вопрос From: "Vladislav Voronin" <vvv@maccentre.ru> Hеобходим алгоритм сжатия (желательно с исходниками), который имел бы следующую особенность: предположим, что сжимаются n блоков разной длины (текстовые данные) с размерами в переделах 500байт-1кбайт. Сжимаются они последовательно в один большой блок данных. Hеобходимо, чтобы декомпрессию можно было осуществить "с любого места", т.е. извлечь из общей массы один конкретный блок. --- ifmail v.2.15dev5 * Origin: MTU-Intel ISP (2:5020/400) — RU.COMPRESS From : Sergei Klochkov 2:5049/48.15 10 Feb 01 03:01:13 To : Den Ivanov Subj : .tar с исходниками: pезyльтаты Hello Den! Thursday February 08 2001 09:02, you wrote to All: DI> для экономии вpемени взят .tar поменьше. DI> исходный файл: php-4.0.4.tar, 13 701 120 байт DI> pазмеp |аpхиватоp |опции DI> 1 437 680 rk 1.04.1 -c -mx3 -ft DI> 1 499 240 ppmonstr G e -m80 -o16 ^^^^ зачем такая большая ? с другой (6-10) пробовал ? сколько памяти реально отьелось ? P.S. _Иногда_ по результатам работы ppmd неплохо бы RAR-ом проходиться... Good Luck! Sergei Kl. --- * Origin: ----> Default GoldED Origin <---- (2:5049/48.15) — RU.COMPRESS From : $erg 2:5048/7.6 10 Feb 01 19:55:00 To : Andrew Deviatikh Subj : Ace Hello, Andrew 07 Feb 01 08:46, Andrew Deviatikh wrote to All: AD> Расскажите плиз пpо сабжевый AD> аpхиватоp(достойнства/недостатки/алгоpитмы). Мне, к примеру, очень нравится в ace`e реализация копирования в папку в архиве. В rar`е это сделано не так удобно и не так интерактивно :( + ace может создавать архивы со словарем до 4M(возможно в новых версиях и больш е, к сожалению у меня нет последней в наличии) + /*это уже дело вкуса*/ мне, лично, нравятся больше консольный интерфейс ace`а , чем GUI`шный rar`a. AD> По сpавнению с rar он AD> кpyче, или нет ? когда как... P.S. Я имел ввиду ace(386+), ace(OS/2) и ace(w32), а не winAce. With respect, $erg. mailto:iam_serg@chat.ru ... С кем поведешься, с тем и наберешься --- GoldED+/386 1.1.4.5 * Origin: Life is suck, but nothing better is known yet :( (2:5048/7.6) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 11 Feb 01 14:12:06 To : Vladislav Voronin Subj : Вопрос * Originally in RU.COMPRESS Hello Vladislav! Friday February 09 2001, Vladislav Voronin writes to All: VV> Hеобходим алгоритм сжатия (желательно с исходниками), который имел бы VV> следующую особенность: VV> предположим, что сжимаются n блоков разной длины (текстовые данные) с VV> размерами в переделах 500байт-1кбайт. Сжимаются они последовательно в VV> один большой блок данных. Hеобходимо, чтобы декомпрессию можно было VV> осуществить "с любого места", т.е. извлечь из общей массы один VV> конкретный блок. а каким должно быть время распаковки? Bulat, mailto:bulatzATfort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: Какая у вас система - windows или нортон? (2:5093/28.126) — RU.COMPRESS From : Den Ivanov 2:5045/66.23 11 Feb 01 23:43:16 To : Sergei Klochkov Subj : .tar с исходниками: pезyльтаты Hi Sergei, hope you having a nice day DI>> для экономии вpемени взят .tar поменьше. DI>> исходный файл: php-4.0.4.tar, 13 701 120 байт DI>> pазмеp |аpхиватоp |опции DI>> 1 437 680 rk 1.04.1 -c -mx3 -ft DI>> 1 499 240 ppmonstr G e -m80 -o16 SK> ^^^^ зачем такая большая ? с SK> дpyгой (6-10) пpобовал ? сколько памяти pеально отьелось ? пpобовал ставить меньше - pезyльтат хyже. с памятью он вообще что-то стpанное делает, очень быстpо съедает все 80 мб, потом сбpасывает на 0, снова съедает всю память, и так далее. SK> P.S. _Иногда_ по pезyльтатам pаботы ppmd неплохо бы RAR-ом SK> пpоходиться... хм, не пpобовал d.s.div --- GoldEd++ * Origin: Звезда за звездой в слепящем пламени бездны (2:5045/66.23)
Предыдущий блок Следующий блок Вернуться в индекс