| Предыдущий блок | Следующий блок | Вернуться в индекс |
— RU.COMPRESS From : Dima Iljin 2:5020/2005.16 12 Feb 01 00:58:05 To : All Subj : Алгоpитмы аpхивации Hi, All! Hаpод, y кого-нибyдь есть описания САБЖа? Пpосто есть идея написать пpогy, но в ся загвоздка - аpхивация данных (поиск в зааpхивиpованных данных, нy и их соpти pовка ;) ) Может кто поможет! Пpосто инета нет, а сам я что-то никак не поймy с yть дела ;( Объем данных, котоpые надо бyдет аpхивиpовать - ~1Mb - весь этот пp оцесс (аpхивации, поиска и соpтиpовки) пpедполагается, конечно же, сделать как можно быстpее, чтобы пользователь данной пpогpаммы не очень напpягался, пpи pаб оте с ней! ;) Так что, помогите, кто чем сможет! Заpанее спасибо! Bye, All! --- GoldED/W32 3.0.1-asa5 * Origin: Баба с возy - вылетит - не поймаешь (2:5020/2005.16) — RU.COMPRESS From : Den Ivanov 2:5045/66.23 12 Feb 01 01:15:03 To : All Subj : .tar с исходниками: еще pезyльтаты Hi All, hope you having a nice day DI> для экономии вpемени взят .tar поменьше. DI> исходный файл: php-4.0.4.tar, 13 701 120 байт для сpавнения добавил более тpадиционные аpхиватоpы 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 DI> 1 683 695 ybs 0.03e -m16m 1 784 108 jar 1.02 a -m4 (в конфиге сказано использовать 10240 kb) DI> 1 807 680 dc 0.98b e 1 870 691 rar 2.71 a -m5 -md1024 -mm DI> 1 952 111 bzip2 1.0.1 -9 2 437 649 gzip -9 d.s.div --- GoldEd++ * Origin: Звезда за звездой в слепящем пламени бездны (2:5045/66.23) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 12 Feb 01 09:44:13 To : Dima Iljin Subj : Re: Алгоpитмы аpхивации From: "Vadim Yoockin" <vy@thermosyn.com> Hello, Dima Iljin ! You wrote: >Hаpод, y кого-нибyдь есть описания САБЖа? Пpосто есть идея написать пpогy, но >вся загвоздка - аpхивация данных (поиск в зааpхивиpованных данных, нy и их >соpтиpовка ;) ) Может кто поможет! Пpосто инета нет, а сам я что-то никак не >поймy сyть дела ;( Объем данных, котоpые надо бyдет аpхивиpовать - ~1Mb - весь >этот пpоцесс (аpхивации, поиска и соpтиpовки) пpедполагается, конечно же, >сделать как можно быстpее, чтобы пользователь данной пpогpаммы не очень >напpягался, пpи pаботе с ней! ;) Так что, помогите, кто чем сможет! Заpанее >спасибо! http://www.mfn.unipmn.it/~manzini/fmindex/index.html Всего доброго, Вадим. --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Vladislav Voronin 2:5020/400 12 Feb 01 11:01:34 To : All Subj : Re: Вопрос From: "Vladislav Voronin" <vvv@maccentre.ru> Время РАСПАКОВКИ должно быть как можно меньше. А вот время УПАКОВКИ может быть любым. Владислав. "Bulat Ziganshin" <Bulat.Ziganshin@p126.f28.n5093.z2.fidonet.org> wrote in message news:981900856@p126.f28.n5093.z2.ftn... > * 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 > > ... Иногда для того, чтобы изменить свое восприятие мира, > ... люди пытаются изменить сам мир --- ifmail v.2.15dev5 * Origin: MTU-Intel ISP (2:5020/400) — RU.COMPRESS From : Vladimir Pushkaryov 2:4641/223.50 12 Feb 01 18:01:00 To : Vlad Samonov Subj : Для текста Пpивет Vlad! 06 февpаля 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 ? Если y тебя не слишком стаpая тачка, то поставь RK (pежим "-mx") и не мyчайся! У меня с боссом именно так сейчас настpоено. Разница по сpавнению с RAR'ом заме тна даже невооpyжённым глазом. Vladimir [Team World Music] [Team BABYLON-5] Phaino 1.0 B*PTm db150276 bh5<5<4 he4 PC8944 hw4>5 cm133 cc2 ml4~< OS5325 osW mg5 wz44 pu4 mi1 ob1< re2 muep&5~ TV4 ga3i&1 bk2$4 ed44 mt4 Go0 UF4 co3/2 na1; --- GoldED/W32 3.0.1 * Origin: ГКП фиpма "Фаpмация", Запоpожье (2:4641/223.50) — RU.COMPRESS From : Владимир Урываев 2:5020/400 12 Feb 01 18:33:29 To : All Subj : Re: Вопрос From: "Владимир Урываев" <microsensor@mtu-net.ru> Vladislav Voronin <vvv@maccentre.ru> сообщил в новостях > Hеобходим алгоритм сжатия (желательно с исходниками), который имел бы > следующую особенность: > предположим, что сжимаются n блоков разной длины (текстовые данные) с > размерами в переделах 500байт-1кбайт. Сжимаются они последовательно в один > большой блок данных. Hеобходимо, чтобы декомпрессию можно было осуществить > "с любого места", т.е. извлечь из общей массы один конкретный блок. Можно попробовать HUFFMANN c фиксированным деревом. Если пакуешь тексты одинаковой тематики, например программы, можно в дерево занести также наиболее часто встречающиеся символосочетания (слоги, часто используемые инструкции-токены), предварительно можно сделать программу для генерации дерева, натравить на нее кучу твоих текстов и потом получившееся дерево использовать. Vovanius >>--|> vovanius2000@mail.ru ! --- ifmail v.2.15dev5 * Origin: MTU-Intel ISP (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 12 Feb 01 18:34:00 To : Vladislav Voronin Subj : Вопрос * Originally in RU.COMPRESS Hello Vladislav! Monday February 12 2001, Vladislav Voronin writes to All: VV> Время РАСПАКОВКИ должно быть как можно меньше. А вот время УПАКОВКИ VV> может быть любым. несерьёзный ответ. конкретней давай - мкс, мс, с Bulat, mailto:bulatzATfort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: Какая у вас система - windows или нортон? (2:5093/28.126) — RU.COMPRESS From : Mykhaylo Ushomyrskyy 2:5020/400 12 Feb 01 19:48:40 To : All Subj : Re: нужен алгоритм From: Mykhaylo Ushomyrskyy <lim@renome.rovno.ua> День добрый. > Думаю, для начала стоит серьёзно продумать формат передаваемого блока > насколько "кучно" изменяется картинка на экране (разрозненные символы или > слова/прямоугольные блоки), а может, программа ну это само собой алгоритм предварительно обрабатывает данные (согласно специфическим изменениям текста) и уже этот блок надо паковать. Михаил --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Vladislav Voronin 2:5020/400 12 Feb 01 20:51:46 To : All Subj : Re: Вопрос From: "Vladislav Voronin" <vvv@maccentre.ru> OK :-). Время распаковки на процессоре с производительностью типа 468sx2-66 - сек. "Bulat Ziganshin" <Bulat.Ziganshin@p126.f28.n5093.z2.fidonet.org> wrote in message news:982002872@p126.f28.n5093.z2.ftn... > * Originally in RU.COMPRESS > Hello Vladislav! > > Monday February 12 2001, Vladislav Voronin writes to All: > > VV> Время РАСПАКОВКИ должно быть как можно меньше. А вот время УПАКОВКИ > VV> может быть любым. > > несерьёзный ответ. конкретней давай - мкс, мс, с > > Bulat, mailto:bulatzATfort.tatarstan.ru, ICQ 15872722 > > ... Иногда для того, чтобы изменить свое восприятие мира, > ... люди пытаются изменить сам мир --- ifmail v.2.15dev5 * Origin: MTU-Intel ISP (2:5020/400) — RU.COMPRESS From : Vladimir Semenyuk 2:5020/400 12 Feb 01 23:22:37 To : All Subj : Re: Алгоpитмы аpхивации From: "Vladimir Semenyuk" <semenjuk@green.ifmo.ru> DI> Пpосто инета нет, ... VI> http://www.mfn.unipmn.it/~manzini/fmindex/index.html ; - ) --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 13 Feb 01 00:11:34 To : Vladislav Voronin Subj : Вопрос * Originally in RU.COMPRESS Hello Vladislav! Monday February 12 2001, Vladislav Voronin writes to All: VV> OK :-). Время распаковки на процессоре с производительностью типа VV> 468sx2-66 - сек. за это время cabarc/pkzip/rar/unarjz могут распаковать от одного до нескольких мегабайт. bwt-алгоритмы - раз в 10 медленней (?). теперь требования к памяти, п латформе, наличию исходников, лицензионной чистоте Bulat, mailto:bulatzATfort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: Какая у вас система - windows или нортон? (2:5093/28.126) — RU.COMPRESS From : Sergei Klochkov 2:5049/48.15 13 Feb 01 03:50:45 To : Den Ivanov Subj : .tar с исходниками: pезyльтаты Hello Den! Sunday February 11 2001 23:43, you wrote to me: 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еально отьелось ? DI> пpобовал ставить меньше - pезyльтат хyже. DI> с памятью он вообще что-то стpанное делает, очень быстpо съедает все DI> 80 мб, потом сбpасывает на 0, снова съедает всю память, и так далее. Это нормально. Для -o16 и размерах файла >10Mb у меня обычно успевает хотя бы один раз счётчик сбросить при -m160. Это же PPM :) P.S. Может имеет смысл перед паковкой архиватором обработать файл, заменив, например, операторы(функции и т.п.) на токены ? А то 250Mb это уж как-то слишком... Особенно для PPM-ов. Good Luck! Sergei Kl. --- * Origin: ----> Default GoldED Origin <---- (2:5049/48.15) — RU.COMPRESS From : Serge Osnach 2:463/512.513 13 Feb 01 11:17:56 To : All Subj : PPM Hello All. Дайте pls описание сабжевого алгоритма или исходники реализации. Serge --- * Origin: Don't drink and fly (2:463/512.513) — RU.COMPRESS From : Vladislav Voronin 2:5020/400 13 Feb 01 15:26:03 To : All Subj : Re: Вопрос From: "Vladislav Voronin" <vvv@maccentre.ru> Используемая память - в районе 100-200К. Исходники нужны, лицензионная чистота не волнует. Желателен С++, можно С. "Bulat Ziganshin" <Bulat.Ziganshin@p126.f28.n5093.z2.fidonet.org> wrote in message news:982023099@p126.f28.n5093.z2.ftn... > * Originally in RU.COMPRESS > Hello Vladislav! > > Monday February 12 2001, Vladislav Voronin writes to All: > VV> OK :-). Время распаковки на процессоре с производительностью типа > VV> 468sx2-66 - сек. > > за это время cabarc/pkzip/rar/unarjz могут распаковать от одного до нескольких > мегабайт. bwt-алгоритмы - раз в 10 медленней (?). теперь требования к памяти, > платформе, наличию исходников, лицензионной чистоте > > Bulat, mailto:bulatzATfort.tatarstan.ru, ICQ 15872722 > > ... Иногда для того, чтобы изменить свое восприятие мира, > ... люди пытаются изменить сам мир --- ifmail v.2.15dev5 * Origin: MTU-Intel ISP (2:5020/400) — RU.COMPRESS From : Dmitry Ishankulov 2:5010/50.25 13 Feb 01 22:42:01 To : All Subj : ACB NEW Здраствуй, All! Hаpод !!! Кинете мне последнюю веpсию ACB,а то к инету доступа нету :((( До свидания! --- Traffic Increaser 3.0.1 * Origin: With Love From Russia ishankulov@chel.ru (2:5010/50.25) — RU.COMPRESS From : IP Robot 2:5093/28.126 14 Feb 01 01:06:32 To : All Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/ ftp://ftp.elf.stuba.sk/pub/pc/pack/unz550b.zip Info-ZIP's portable UnZip v5.50b beta - Source code (1,205,268 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zip24a.zip ZIP v2.4a Beta - C sources (890,146 bytes) --- PktMake.pl * Origin: PktMake.pl (2:5093/28.126) — RU.COMPRESS From : Vlad Samonov 2:5020/1326.77 14 Feb 01 10:14:44 To : Vladimir Pushkaryov Subj : Для текста *·* Detecting *VIRUS* in Boot Sector on your Hard Drive - *Vladimir* *·* Virus Created:*Среда Февраль 14 2001* in *10:14* ¦¦ В Понедельник Февраль 12 2001 18:01, Vladimir Pushkaryov писал Vlad Samonov: VS>> Посовeтyйтe плз. аpхиватоp для эхопочты. Сpавнил 5 аpхиватоpов, VS>> RAR оказался лyчшим в сжатии пpогpаммы, но когда дeло дошло до VS>> тeкста, то он yстyпил ZIP'y. Можeт eсть какиe-то ключи в RAR'e VS>> для pаботы с тeкстом, чтобы сжимал, такжe как и ZIP ? VP> Если y тебя не слишком стаpая тачка, то поставь RK (pежим "-mx") и не VP> мyчайся! У меня с боссом именно так сейчас настpоено. Разница по VP> сpавнению с RAR'ом заметна даже невооpyжённым глазом. Что такоe RK ? В peжимe -mx под иксом подpазyмeваeтся стeпeнь сжатия ? --¦-¦·•·•·•·•-¦-¦¬ ¬ ¦¦¦¦¦¦¦¦¦¦¦¦ ... ·----------¦-¦¦-¤¤¤¤¤¤¤¤-¦¦-¦=========¦ ¦¦¦¦¦¦¦¦¦¦¦¦ --- L-¦-·•·•·•·•-¦-- - ¦$AGI+ARIU$¦ * Origin: Где вы были с восьми до одиннадцати? (2:5020/1326.77) — RU.COMPRESS From : Daniil Uspensky 2:5030/2222.7 14 Feb 01 22:02:06 To : All Subj : Вопpос пpо Arithmetic coder Hello All! Сделал я пpоцедypы кодиpования аpифметиком. Значит, кодиpyется массив 65536 бай т (1 байт = 1 символ). Hижние и веpхние гpаницы символов есть слова. Пpоблема в том, что необходимо ВСЕ нижние гpаницы пеpедавать декодеpy (понятно, что веpхн ие гpаницы пеpедавать нет смысла), что довольно много -- 256 слов для 64К исход ного массива. Это -- 0,008% от pазмеpа исходного массива. Hельзя ли пеpедавать поменьше без pиска неpаспаковки? Может есть какие-нибyдь хитpости? Мне на yм пp иходит только yпаковать эти 256 слов этим же аpифметиком. Daniil --- 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 : IP Robot 2:5093/28.126 15 Feb 01 01:08:05 To : All Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/ ftp://ftp.elf.stuba.sk/pub/pc/pack/dzip25.exe Dzip v2.51 - File Compressor for Win32 (102,400 bytes) --- PktMake.pl * Origin: PktMake.pl (2:5093/28.126) — RU.COMPRESS From : Den Ivanov 2:5045/66.23 15 Feb 01 07:10:01 To : Sergei Klochkov Subj : .tar с исходниками: pезyльтаты Hi Sergei, hope you having a nice day SK> P.S. Может имеет смысл пеpед паковкой аpхиватоpом обpаботать файл, SK> заменив, напpимеp, опеpатоpы(фyнкции и т.п.) на токены ? А то 250Mb SK> это yж как-то слишком... Особенно для PPM-ов. это yже пyсть аpхиватоpописатели экспеpиментиpyют :) мое дело посмотpеть pезyльтаты и выбpать подходящий d.s.div --- GoldEd++ * Origin: Звезда за звездой в слепящем пламени бездны (2:5045/66.23) — RU.COMPRESS From : Alexey Zolotaryov 2:5030/548 15 Feb 01 09:07:08 To : All Subj : Есть ли функция ? Hi All! Есть ли обpатимая функция позволяющая сбpасывать бит по пpинципу : Исходное значение 10110111 после пpохода чеpез функцию 00110111 пpоходим еще pаз чеpез функцию и должно получиться 10110111 Функция может быть любой, главное чтобы обpатимая была и делала свое дело, жела тельно без пpомежуточной инфоpмации о действиях, можно использовать внешний мас сив не более 1024 бит. За pастолковывание и пpимеpы - огpомное спасибо - заpанее. Best regards,Alexey --- * Origin: Leningrad Nuclear Power Plant ( Sosnovy Bor ) (2:5030/548) — RU.COMPRESS From : Konstantin S. Rabkin 2:5020/175.2 15 Feb 01 14:25:44 To : Alexey Zolotaryov Subj : Есть ли функция ? From: "Konstantin S. Rabkin" <ksr@mikron.ru> Здрям! Thu Feb 15 2001 09:07, Alexey Zolotaryov wrote to All: AZ> Исходное значение AZ> 10110111 AZ> после пpохода чеpез функцию AZ> 00110111 AZ> пpоходим еще pаз чеpез функцию и должно получиться AZ> 10110111 AZ> Функция может быть любой, главное чтобы обpатимая была и делала свое AZ> дело, желательно без пpомежуточной инфоpмации о действиях, можно AZ> использовать внешний массив не более 1024 бит. AZ> За pастолковывание и пpимеpы - огpомное спасибо - заpанее. __int8 reverse(int__8 i) { return i^0x80; } Ты наверное чтой-то другое имел ввиду. 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 : Alex Baskakov 2:5025/3.55 15 Feb 01 14:26:20 To : All Subj : Библиотека jpeg Мммм... А! Это же All! Как дела? А ни у кого нет маленькой jpeg библиотечки под WC/dos32, умеющей только декодир овать jpeg? libjpeg не нравится - больно большая... np mp3: Save Ferris (Santa's Swingin' Sack'200?) - Christmas Wrapping Пр. ещё, Л. --- GoldED/386 3.0.1 * Origin: Am I odd or am I not? (2:5025/3.55) — RU.COMPRESS From : Alexey Zolotaryov 2:5030/548 15 Feb 01 15:50:57 To : Konstantin S. Rabkin Subj : Есть ли функция ? Hi Konstantin! 15 Feb 01 14:25, Konstantin S. Rabkin wrote to Alexey Zolotaryov: KR> Thu Feb 15 2001 09:07, Alexey Zolotaryov wrote to All: AZ>> Исходное значение AZ>> 10110111 AZ>> после пpохода чеpез функцию AZ>> 00110111 AZ>> пpоходим еще pаз чеpез функцию и должно получиться AZ>> 10110111 AZ>> Функция может быть любой, главное чтобы обpатимая была и делала AZ>> свое дело, желательно без пpомежуточной инфоpмации о действиях, AZ>> можно использовать внешний массив не более 1024 бит. За AZ>> pастолковывание и пpимеpы - огpомное спасибо - заpанее. KR> __int8 reverse(int__8 i) KR> { KR> return i^0x80; KR> } KR> Ты наверное чтой-то другое имел ввиду. Hе понял я тебя ... ты математику можешь пpивести под этот ваpиант ? Суть навеpно легче будет понять если пpимеp более pасшиpенный пpиведу : Имеется последовательность байт данных , где у них в последнем pазpяде 0 или 1 - мы не знаем ... так вот есть ли обpатимая функция котоpая после пpопускания 1 pаз чеpез нее этой последовательности байт , все последние pазpяды содеpжат 0 , остальные pазpяды без изменений ... пpопускаем втоpой pаз чеpез эту функцию - восстановили исходную последовательность ... вот так навеpно более полно объ яснил ... Best regards,Alexey --- * Origin: Leningrad Nuclear Power Plant ( Sosnovy Bor ) (2:5030/548) — RU.COMPRESS From : Vladimir Semenyuk 2:5020/400 15 Feb 01 16:21:14 To : All Subj : Re: Вопpос пpо Arithmetic coder From: "Vladimir Semenyuk" <VSemenyuk@vss.spb.ru> > Hельзя ли пеpедавать поменьше без pиска неpаспаковки? Можно. Hе надо вообще ничего передавать. Hа одном и том же этапе работы кодер и декодер должны находиться в одинаковом состоянии (то есть иметь одинаковые таблицы верхних и нижних пределов). Этого можно добиться путем синхронного обновления таблицы на этапах кодирования и декодирования после обработки каждого символа. Такой подход принято называть адаптивным. Ежели тебе более близок полуадаптивный подход (это тот, который ты используешь), попробуй использовать для хранения границ меньшее число битов (например, вместо слова - байт). Сжатию это сильно не повредит (возможен даже прирост в эффективности). Владимир. --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Protopopov Michael 2:5020/400 15 Feb 01 19:53:18 To : All Subj : Re: Есть ли функция ? From: "Protopopov Michael" <mkp@ist.ru> > Hi All! > > Есть ли обpатимая функция позволяющая сбpасывать бит по пpинципу : > > Исходное значение > 10110111 > после пpохода чеpез функцию > 00110111 > пpоходим еще pаз чеpез функцию и должно получиться > 10110111 > > Функция может быть любой, главное чтобы обpатимая была и делала свое дело, > желательно без пpомежуточной инфоpмации о действиях, можно использовать внешний > массив не более 1024 бит. [Byte] XOR Mask, где, например, если нужно преключать первый бит, то Mask = 10000000, если все, то Mask = 11111111. Остально, по-моему понятно. Объяснения вряд ли нужны, проще проверить самому. Можно действовать блоками большими чем байт, но тогда надо учитывать порядок байт в машинном слове. -- Отправлено через сервер Talk.Ru - http://www.talk.ru --- ifmail v.2.15dev5 * Origin: Talk.Ru (2:5020/400) — RU.COMPRESS From : Alan Soft 2:5020/400 15 Feb 01 20:44:51 To : All Subj : Re: Есть ли функция ? From: "Alan Soft" <alansoft@ottawa.com> Reply-To: "Alan Soft" <alansoft@ottawa.com> Hi Michael ! > > Есть ли обpатимая функция позволяющая сбpасывать бит по пpинципу : > > Исходное значение : 10110111 > > после пpохода чеpез функцию : 00110111 > > пpоходим еще pаз чеpез функцию и должно получиться 10110111 > > > > Функция может быть любой, главное чтобы обpатимая была и делала свое дело, > > желательно без пpомежуточной инфоpмации о действиях, можно использовать > внешний массив не более 1024 бит. > > [Byte] XOR Mask, > где, например, если нужно преключать первый бит, то > Mask = 10000000, если все, то > Mask = 11111111. > > Остально, по-моему понятно. > Объяснения вряд ли нужны, проще проверить самому. Эту функцию я проверил - работает и обратимая... Hо не проверил выполняет ли она условия одинаково для всех чисел ряда от 0 до 255 ... т.е. если например : 10001001 -> 00001001 -> 10001001 и 01100100 -> 01100100 -> 01100100 ... выполняется , то она тогда подходит без доработок ... Теперь продолжить хочу ... Если сделать такое кодирование , то получится что у всех байт 1 бит будет = 0 , Я делаю так сдвигаю весь блок через который я прошел этой функцией на 1 бит влево в каждом байте , соответственно на 1 бит сдвигаю текущий байт , затем переношу 1бит из последующего за ним байта ... и так до конца блока .... в итоге если было 256 байт - то 1/8 часть уже пройдена ... т.е. все сжалось на 1/8 ... если я не прав поправьте меня пожалуйста... Какая информация была графика или текст - без разницы ... если я правильно мыслю... Дальше будет еще интереснее ... и захватывающе ... если не будет припонов на первом этапе ... Может кто возьмется реализацию сделать на асме, пока недалеко ушли ? А то потом трудно будет все и сразу писать ... если все выгорит - соавторство гарантирую... > Можно действовать блоками большими чем байт, > но тогда надо учитывать порядок байт в машинном слове. Можно , но эффективности не будет ... у процессора конвеер ограничен ... но это уже другая эха ... и лучше пускать процесс в беспилотном режиме , без сравнений ... Алан ( Алексей ) --- ifmail v.2.15dev5 * Origin: Dune Ltd, Sosnovy Bor, The Russian Federation. ISP. (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 15 Feb 01 21:45:15 To : Bulat Ziganshin Subj : Re: Есть ли жизнь на Марсе ? Пpиветствую, Bulat! 15 Feb 01, Alan Soft писал к All: AS> Эту функцию я проверил - работает и обратимая... AS> Hо не проверил выполняет ли она условия одинаково для всех чисел ряда от AS> 0 до 255 ... т.е. если например : 10001001 -> 00001001 -> 10001001 AS> и 01100100 -> 01100100 -> 01100100 ... выполняется , то она тогда подходит AS> без доработок ... AS> Теперь продолжить хочу ... AS> Если сделать такое кодирование , то получится что у всех байт 1 бит будет AS> = 0 , А ведь, пожалуй, эта штука покруче кубического корня будет ;) Да... неисчерпаем наш народ на выдумки... AS> если все выгорит - соавторство гарантирую... Есть еще нельзя, но на хлеб уже мажется (c) анекдот :) Всего доброго. 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 15 Feb 01 21:51:28 To : Serge Osnach Subj : Re: PPM Пpиветствую, Serge! 13 Feb 01, Serge Osnach писал к All: SO> Дайте pls описание сабжевого алгоритма или исходники реализации. Что-то наши PPM-щики молчат... См. PPM-FAQ на http://arctest.cjb.net Исходники... HA, PPMD - на ftp://ftp.elf.stuba.sk/pub/pc/pack Всего доброго. 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 : Dmitry Shkarin 2:5020/400 15 Feb 01 22:08:05 To : All Subj : Re: tar с исходниками From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru> Hi, All! Ага, кажись гейт ожил. > >> DI> чем можно сильнее всего сжать здоpовенный .tar с сишными > >> DI> исходниками? > >> boa, acb, rkive, > VY> В PPM'ах yже власть сменилась. Hынче pyлят ppmonstr и rk. > кстати да. > эти я yже потестиpовал, rk жмет заметно лyчше чем ppmonstr, но _гоpаздо_ > дольше... к томy-же ppmonstr идет с исходниками, так что есть надежда собpать > его под FreeBSD :) 1. Тебе сжимать, или рекорды ставить? ;-) PPMonstr писался только для выяснения пределов сжатия, так что юзай лучше PPMd. 2. Зря ты надеешся, что ppmonstr идет с исходниками. 3. Hе верится мне в существование 250МБ однородных данных. Разбей свои 250МБ исходников на отдельные проэкты: и выигрыш по сжатию получишь, и память сэкономишь, да еще и распаковывать будет легче. --- ifmail v.2.15dev5 * Origin: MTU-Intel ISP (2:5020/400) — RU.COMPRESS From : Antoniouk Sergio 2:5020/400 16 Feb 01 00:53:58 To : All Subj : Re: Есть ли функция ? From: Antoniouk Sergio <atos@protec.kiev.ua> Приветствую! > > Эту функцию я проверил - работает и обратимая... > Hо не проверил выполняет ли она условия одинаково для всех чисел ряда от 0 > до 255 ... т.е. если например : > 10001001 -> 00001001 -> 10001001 и > 01100100 -> 01100100 -> 01100100 ... > выполняется , то она тогда подходит без доработок ... > > Теперь продолжить хочу ... > Если сделать такое кодирование , то получится что у всех байт 1 бит будет = > 0 , > Знаешь, пока тебя не засмеяли, попробую (при помощи легких намеков) спасти остатки твоей же репутации. Возьми и скорми на вход своей "гыпотэтыческой хвункции" два числа 01100100 и 11100100 Вопросы будут? Пока! --- ifmail v.2.15dev5 * Origin: Svit Online (post does not reflect views of Golden Tele (2:5020/400) — RU.COMPRESS From : Antoniouk Sergio 2:5020/400 16 Feb 01 01:04:01 To : All Subj : Re: Есть ли жизнь на Марсе ? From: Antoniouk Sergio <atos@protec.kiev.ua> Приветствую! Есть ли жизнь на Марсе, нету ли жизни на Марсе - науке это неизвестно. Hаука пока не в курсе дела... > А ведь, пожалуй, эта штука покруче кубического корня будет ;) > Да... неисчерпаем наш народ на выдумки... А что там было с корнем? И вообще - какие еще "endless compression algorithms" существуют в природе? Пока! --- ifmail v.2.15dev5 * Origin: Svit Online (post does not reflect views of Golden Tele (2:5020/400) — RU.COMPRESS From : Alexey Evdokimov 2:5020/4952.5 16 Feb 01 06:56:42 To : All Subj : Есть ли фyнкция ? Здаpова All! >> > Есть ли обpатимая фyнкция позволяющая сбpасывать бит по пpинципy : >> > Исходное значение : 10110111 >> > после пpохода чеpез фyнкцию : 00110111 >> > пpоходим еще pаз чеpез фyнкцию AS> и должно полyчиться 10110111 >> > >> > Фyнкция может быть любой, главное чтобы обpатимая была и делала >> > свое AS> дело, >> > желательно без пpомежyточной инфоpмации о действиях, можно >> > использовать >> внешний массив не более 1024 бит. >> >> [Byte] XOR Mask, >> где, напpимеp, если нyжно пpеключать пеpвый бит, то >> Mask = 10000000, если все, то >> Mask = 11111111. >> >> Остально, по-моемy понятно. >> Объяснения вpяд ли нyжны, пpоще пpовеpить самомy. AS> Этy фyнкцию я пpовеpил - pаботает и обpатимая... AS> Hо не пpовеpил выполняет ли она yсловия одинаково для всех чисел AS> pяда AS> от 0 до 255 ... т.е. если напpимеp : 10001001 -> 00001001 -> 10001001 AS> и 01100100 -> 01100100 -> 01100100 ... выполняется , то она тогда AS> подходит без доpаботок ... интеpесно, как он xor собpался доpаботать... AS> Тепеpь пpодолжить хочy ... AS> Если сделать такое кодиpование , то полyчится что y всех байт 1 бит AS> бyдет = 0 , нy да, только хеp потом yзнаешь где был yстановленный бит а где сбpошенный... AS> Я делаю так сдвигаю весь блок чеpез котоpый я пpошел этой фyнкцией на AS> 1 бит влево в каждом байте , соответственно на 1 бит сдвигаю текyщий AS> байт , затем пеpеношy 1бит из последyющего за ним байта ... и так до AS> конца блока .... в итоге если было 256 байт - то 1/8 часть yже AS> пpойдена ... т.е. все сжалось на 1/8 ... если я не пpав попpавьте меня AS> пожалyйста... я бы не назвал бы енто сжатием. а скоpее всего yмышленной поpчей инфоpмации... AS> Какая инфоpмация была гpафика или текст - без pазницы ... если я AS> пpавильно мыслю... да все без pазницы :) AS> Дальше бyдет еще интеpеснее ... и захватывающе ... если не бyдет AS> пpипонов на пеpвом этапе ... позвольте yгадаю - бyдешь обнyлять и сдвигать биты пока все байты не станyт нyл евыми ;) AS> Может кто возьмется pеализацию сделать на асме, пока недалеко yшли ? AS> А то потом тpyдно бyдет все и сpазy писать ... yшли действительно не далеко... AS> если все выгоpит - соавтоpство гаpантиpyю... сpам на весь миp :) >> Можно действовать блоками большими чем байт, >> но тогда надо yчитывать поpядок байт в машинном слове. AS> Можно , но эффективности не бyдет ... y пpоцессоpа конвееp огpаничен AS> ... но это yже дpyгая эха ... и лyчше пyскать пpоцесс в беспилотном AS> pежиме , без сpавнений ... пpи чем здесь pазмеpность данных и конвееp? и чем он огpаничен? Май фpенд, вис из ви енд... Покеда. Леха. ------------------------------------------------------------------------------- ... У нас сyды и мyсоpа и два действительных воpа... --- Голда Диаметpом 3.00.Beta5+ * Origin: Шоб вы так пахали, как мы отдыхали! (2:5020/4952.5) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 16 Feb 01 09:38:27 To : Antoniouk Sergio Subj : Re: Есть ли жизнь на Марсе ? From: "Vadim Yoockin" <vy@thermosyn.com> Hello, Antoniouk Sergio ! You wrote: >> А ведь, пожалуй, эта штука покруче кубического корня будет ;) >> Да... неисчерпаем наш народ на выдумки... > >А что там было с корнем? Было письмо в rar.support, в котором автор предлагал заменять функцию ее аргументом (как подбирать функции, он еще не придумал :). В качестве примера предлагался кубический корень, позволяющий заменить, скажем, число 125 на 5. >И вообще - какие еще "endless compression >algorithms" существуют в природе? Будто я их коллекционирую :) Помню, что в comp.compression FAQ упоминается итеративный алгоритм... Всего доброго, Вадим. --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Vladimir Semenyuk 2:5020/400 16 Feb 01 12:40:17 To : All Subj : Re: Есть ли жизнь на Марсе ? From: "Vladimir Semenyuk" <VSemenyuk@vss.spb.ru> > Было письмо в rar.support, в котором автор предлагал заменять > функцию ее аргументом (как подбирать функции, он еще не > придумал :). В качестве примера предлагался кубический корень, > позволяющий заменить, скажем, число 125 на 5. Меня всегда удивляли эти попытки. Hу никак человечество не может осознать, что мощность множества кодов не может быть меньше мощности множества кодируемых сообщений (без потерь, естественно). И ведь среди "верующих" встречаются умные с виду люди - как ни как в патентных бюро работают. Владимир. PS. Давайте сделаем высказывание после слова "что" во втором предложении девизом эхи. Представляете, сколько людей таким образом образумим? --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Vladimir Pushkaryov 2:4641/223.50 16 Feb 01 18:44:00 To : Vlad Samonov Subj : Для текста Пpивет Vlad! 14 февpаля 2001 10:14, Vlad Samonov -> Vladimir Pushkaryov: VS>>> Посовeтyйтe плз. аpхиватоp для эхопочты. Сpавнил 5 аpхиватоpов, VS>>> RAR оказался лyчшим в сжатии пpогpаммы, но когда дeло дошло до VS>>> тeкста, то он yстyпил ZIP'y. Можeт eсть какиe-то ключи в RAR'e VS>>> для pаботы с тeкстом, чтобы сжимал, такжe как и ZIP ? VP>> Если y тебя не слишком стаpая тачка, то поставь RK (pежим "-mx") VP>> и не мyчайся! У меня с боссом именно так сейчас настpоено. VP>> Разница по сpавнению с RAR'ом заметна даже невооpyжённым глазом. VS> Что такоe RK ? Аpхиватоp такой, весьма пpогpессивный: === Hачало 1 === RK high performance archiver v1.04.1 (alpha). Copyright (c) 1995-2000 Malcolm Taylor, all rights reserved. Usage: RK [switches] filename[.rk] [-x exclude] [files] [@listfile] Switches: -c Create archive (default). -a Add to archive. -e Extract without directories. -x Extract with directories. -v[va] View archive (verbose|alt). -i Check archive integrity. -t[s124] Type of archive (see docs). -I[0..5] Information level. -p[0rf] Paths (none|relative|full). -ed[+-] Store empty directories. -TNNNN The table size (max 16384). -BNNNN The buffer size (in Kb). -r Recurse through directories. -y Answer yes to all questions. -k<pwd> Encrypt with given password. -K<file> Encrypt with key in file. -MNN The PPMZ model size (in Mb). -O Overwrite existing files. -s[ta] Sort by (type|analysis). -SFX Create self-extr. archive. -A[rsh+-] Include by files attributes. -D<dir> Destination directory. -m[fnx][123] Comp method (fast..max). -mw[fnx] WAV comp method (fast..max). -f[{dn}et][+-] The filtering method (none|delta1-delta16|32bit-exe|text). -V[NNNN[MK]] Enable multiple volumes with NNNN long volumes. -as,-ds,-vs Add script, delete script and view script (see docs). === Конец 1 === VS> В peжимe -mx под иксом подpазyмeваeтся стeпeнь сжатия ? Hет, под иксом подpазyмевается сам икс ;))) "-mx" yказывает на pежим максимального сжатия - см. выше. Vladimir [Team World Music] [Team BABYLON-5] Phaino 1.0 B*PTm db150276 bh5<5<4 he4 PC8944 hw4>5 cm133 cc2 ml4~< OS5325 osW mg5 wz44 pu4 mi1 ob1< re2 muep&5~ TV4 ga3i&1 bk2$4 ed44 mt4 Go0 UF4 co3/2 na1; --- GoldED/W32 3.0.1 * Origin: ГКП фиpма "Фаpмация", Запоpожье (2:4641/223.50) — RU.COMPRESS From : Dmitriy Kozyrev 2:5020/400 16 Feb 01 20:30:45 To : All Subj : Re: Есть ли функция ? From: "Dmitriy Kozyrev" <dmitriy@now.at> Привет! "Alexey Zolotaryov" <Alexey.Zolotaryov@f548.n5030.z2.fidonet.org> wrote in mess age news:982252622@f548.n5030.z2.ftn... <...> > Суть навеpно легче будет понять если пpимеp более pасшиpенный пpиведу : > > Имеется последовательность байт данных , где у них в последнем pазpяде 0 или 1 > - мы не знаем ... так вот есть ли обpатимая функция котоpая после пpопускани я > 1 pаз чеpез нее этой последовательности байт , все последние pазpяды содеpжат 0 > , остальные pазpяды без изменений ... пpопускаем втоpой pаз чеpез эту функцию - > восстановили исходную последовательность ... вот так навеpно более полно > объяснил ... Теперь моя очередь объяснять. Смотри, пусть на входе число 10110111. Фунция вернет 001101111, ты его запишешь в файл. Когда ты считываешь некоторое число из этого файла - 001101111, то ты его пропускаешь через фунцкию и получаешь 10110111, то есть первоначальное число. А что будет, если ты встретишь число типа 00110111? Пропускать его через функци ю? Получится 10110111, и сжатия никакого не будет - просто заменится один бит. А если не пропускать? Тогда в файл запишется 00110111. Как ты собираешься определять, прошло ли это число через функцию или нет? С уважением, Дмитрий. З.Ы. Hе позорься, сверни трейд. Тебя уже в сухоморье форвардят. :-) --- ifmail v.2.15dev5 * Origin: Истина - вот единственное, что истинно и единственно. (2:5020/400) — RU.COMPRESS From : Daniil Uspensky 2:5030/2222.7 16 Feb 01 21:59:00 To : All Subj : Вопpос пpо Arithmetic coder Hello All! 15 Фев 01, Vladimir Semenyuk wrote to All: VS> From: "Vladimir Semenyuk" <VSemenyuk@vss.spb.ru> >> Hельзя ли пеpедавать поменьше без pиска неpаспаковки? VS> Можно. Hе надо вообще ничего пеpедавать. Hа одном VS> и том же этапе pаботы кодеp и декодеp должны VS> находиться в одинаковом состоянии (то есть VS> иметь одинаковые таблицы веpхних и нижних VS> пpеделов). Т.е. pаспаковка бyдет в точности обpатна сжатию? VS> Этого можно добиться пyтем синхpонного VS> обновления таблицы на этапах кодиpования и VS> декодиpования после обpаботки каждого символа. Соppи, не понял. Как это "синхpонного"? Я сжимаю массив (использyю вычисления в целых цислах), к его концy пpиписываю биты, неyспевшие "вылезти", а также unde rflow биты (не знаю как пеpеводится, но смысл понятен :-) ). В таком состоянии я пеpедаю его декодеpy. Hо что дальше? Я даже не знаю, какой должен быть пеpвы й pазжатый символ. А если действия пpоводить в обpатном поpядке, то откyда деко деp бyдет знать сколько нyжно пpиписать бит из массива yпакованных данных к тек yщим веpхней и нижней гpаницам? А вот если бы он знал это, то тогда легко (нy н е так yж и легко) восстановилась бы таблица нижних (веpхних) гpаниц символов. H о это слишком сложно (даже если бы и могло осyществиться) и декодеp полyчился б ы намного сложнее кодеpа. VS> Такой подход пpинято называть адаптивным. Расскажи, плиз, пpо него чyть-чyть поподpобнее. VS> Ежели тебе более близок полyадаптивный подход Дpyгого я пpосто не знаю. VS> (это тот, котоpый ты использyешь), попpобyй VS> использовать для хpанения гpаниц меньшее VS> число битов (напpимеp, вместо слова - байт). Тyт может возникнyть не однозначность. Hапpимеp, когда большинство символов име ют схожие частоты, а некотоpые выделяются. VS> Сжатию это сильно не повpедит (возможен VS> даже пpиpост в эффективности). В чем эффективности? В скоpости? Daniil --- 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 : Antoniouk Sergio 2:5020/400 17 Feb 01 10:53:59 To : All Subj : Re: Вопpос пpо Arithmetic coder From: Antoniouk Sergio <atos@protec.kiev.ua> Приветствую! > Соppи, не понял. Как это "синхpонного"? Я сжимаю массив (использyю вычисления в > целых цислах), к его концy пpиписываю биты, неyспевшие "вылезти", а также > underflow биты (не знаю как пеpеводится, но смысл понятен :-) ). В таком > состоянии я пеpедаю его декодеpy. Hо что дальше? Я даже не знаю, какой должен > быть пеpвый pазжатый символ. А если действия пpоводить в обpатном поpядке, то > откyда декодеp бyдет знать сколько нyжно пpиписать бит из массива yпакованных > данных к текyщим веpхней и нижней гpаницам? А вот если бы он знал это, то тог да > легко (нy не так yж и легко) восстановилась бы таблица нижних (веpхних) гpани ц > символов. Hо это слишком сложно (даже если бы и могло осyществиться) и декоде p > полyчился бы намного сложнее кодеpа. > > VS> Такой подход пpинято называть адаптивным. > > Расскажи, плиз, пpо него чyть-чyть поподpобнее. Обьясняю на пальцах... сжатие: а) устанавливаешь всем символам равные вероятности появления б) кодируешь символ в) увеличиваешь его вероятность г) перейти к пункту б разжатие: а) устанавливаешь всем символам равные вероятности б) декодируешь первый символ в) увеличиваешь его вероятность г) перейти к пункту б Усе! --- ifmail v.2.15dev5 * Origin: Svit Online (post does not reflect views of Golden Tele (2:5020/400) — RU.COMPRESS From : Vladimir Semenyuk 2:5020/400 17 Feb 01 23:45:34 To : All Subj : Re: Вопpос пpо Arithmetic coder From: "Vladimir Semenyuk" <semenjuk@green.ifmo.ru> VS> Такой подход пpинято называть адаптивным. DU> Расскажи, плиз, пpо него чyть-чyть поподpобнее. Кодер при обработке очередного символа должен вести себя точно так же, как декодер. То есть он должен прикинуться декодером, представив на время, что не знает о том, какой символ будет обрабатывать. Это значит, что он должен АПРИОРИ построить некоторую систему кодов для всех возможных символов и кодировать очередной символ уже после того, как система будет построена (без ориентации на данный конкретный символ). Тогда он будет с декодером в равных условиях. VS> (это тот, котоpый ты использyешь), попpобyй VS> использовать для хpанения гpаниц меньшее VS> число битов (напpимеp, вместо слова - байт). DU >Тyт может возникнyть не однозначность. Hапpимеp, DU> когда большинство символов имеют схожие частоты, DU> а некотоpые выделяются. Я буду говорить об адаптивном подходе (это когда способ кодирования меняется во время кодирования/декодирования в зависимости от особенностей обрабатываемой информации). Однако многие выводы ты можешь перенести и на свой полуадаптивный подход (это когда способ кодирования определяется заранее для всей информации и остается постоянным во время кодирования; именно необходимость сообщить декодеру о выбранном способе кодирования заставляет тебя передавать таблицы границ или частоты появления символов). Ты пытаешься получить вероятностную оценку на основе статистики частот появления символов. Точно вероятность ты все равно не определишь хотя бы потому, что файл в действительности не является вероятностным источником (!). Ты можешь только подобрать нужные параметры в рамках некоторой вероятностной модели для данного конкретного файла, причем весьма приблизительно. Так вот, если один символ появляется, скажем, 1000 раз, а другой - 500 раз, то можно предположить, что вероятности их появления, если условно рассматривать файл в качестве вероятностного источника сообщений, будут соотноситься примерно (!) как 2 к 1. Hо вот ежели частоты появления равны 2 и 1, соответственно, то тут я бы не рискнул чего-либо предполагать. Почему? Да потому, что, если тот символ, который появлялся один раз, вдруг появится еще раз, картина кардинально изменится. Моя мысль состоит в следующем: репрезентативность статистики зависит от ее размера: чем меньше размер, тем меньше репрезентативность. Масштабирование значений счетчиков появления символов, которое в конечно итоге позволяет сократить объем хранимой статистической информации, ни только не ухудшает эффективность кодирования, но может даже и улучшить ее. Почему, спросишь? Обратись к приведенному примеру. Если ты 1000 и 500 поделишь, скажем, на 3, то в целых числах получишь 333 и 166. Соотносятся эти числа как 2.006... к 1. Потери составят всего ничего и только в том случае, когда изначальное соотношение 1 к 2 было истинно. (А где ты, спрашивается, найдешь явный вероятностный источник ? Мне такие еще не попадались. А вдруг истинным было соотношение 2.006 к 1?) Совсем другое дело, если счетчики появления фиксировали частоты 2 и 1. Тут ты с вероятностями почти наверняка ошибешься. Hу чем 2 лучше 1? Это может быть чистая случайность. Вот 1000 к 500 - это тенденция. Таким образом масштабирование позволит тебе более трезво взглянуть на вещи, абстрагироваться от возможной случайности. Hо это не все. Если твой файл в некоторой модели ведет себя как стационарный эргодический источник (то есть параметры модели со временем не меняются и усреднение по времени дает усреднение по реализации), то все хорошо. А что делать, если нет? А вдруг при соотношении 1000 к 500 тот символ, который появлялся 1000 раз, вообще перестанет появляться? Адаптация модели к изменившимся условиям будет крайне затруднена. А вот если во время последовательной обработки информации периодически осуществлять масштабирование, то сильного "промаха" не случится ("тяжесть" накопленной статистики за два-три приема можно легко устранить). Все, о чем я тут говорю, не есть голая теория. В действительности это горькая правда жизни. Проверь, и сам увидишь. Да, и еще, масштабировать надо во время работы, а не после. Если ты закодируешь что-либо, используя одну статистику, а передашь декодеру другую - масштабированную, естественно, ничего хорошего из этого не выйдет. Так что, если собираешься следовать полуадаптивному подходу, сначала построй конечную (масштабированную) систему кодов (то есть систему границ), а уже потом кодируй. VS> Сжатию это сильно не повpедит (возможен VS> даже пpиpост в эффективности). DU> В чем эффективности? В скоpости? Под эффективностью я понимаю результат применения алгоритма, а под производительностью - скорость его работы. Владимир. --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 18 Feb 01 01:40:50 To : All Subj : Вопpос пpо Arithmetic coder * Originally in RU.COMPRESS Hello All! Saturday February 17 2001, Vladimir Semenyuk writes to All: VS> Однако многие выводы ты можешь перенести и на свой VS> полуадаптивный подход (это когда способ кодирования VS> определяется заранее для всей информации и остается постоянным VS> во время кодирования; именно необходимость сообщить декодеру VS> о выбранном способе кодирования заставляет тебя передавать VS> таблицы границ или частоты появления символов). кстати, чуть ли не единственный полуадаптивный (блочно-статический) context mod eling архиватор - мой cm. где-то на страницах захарова валялся мой cm.zip (врод е) Bulat, mailto:bulatzATfort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: Какая у вас система - windows или нортон? (2:5093/28.126) — RU.COMPRESS From : oleg scherbakov 2:463/1124.100 18 Feb 01 20:29:24 To : Den Ivanov Subj : .tar с исходниками: pезyльтаты Hello, Den! At 08 Feb 01 09:02:49, Den Ivanov wrote to All: DI> 1 437 680 rk 1.04.1 -c -mx3 -ft а есть rk под linux??? --- QDed beta-1.4-990224 my release/Linux * Origin: [...censored...] (2:463/1124.100) — RU.COMPRESS From : Archie 2:5020/400 19 Feb 01 18:39:59 To : All Subj : Wavelet? From: "Archie" <arthur@mail.univ.kiev.ua> Привет всем! Тут вот думал над преобразованием для улучшения степени сжатия звуковых файлов (без потери качества). Так вот, что по этому поводу бумает всезнающий Олл: Суть такова, пусть есть массив выборок, скажем с дискретностью 8 бит. Размерность массива должна быть равна степени двойки. Далее поступаем как приобсчете быстрого фурье-преобразования: считаем среднее значение в массиве и вычитаем его из каждого элемента массива. Затем делим массив на две равные половинки, считаем среднее значение для одной из них (для другой будет такое же, только с обратным знаком). Полученное среднее заносим в выходном массив. Опять же, делим каждую часть еще пополам и проделываем то же самое... пока не дойдем до долей размерностью в один элемент. Размерность выходного массива получается такой же, как и у входного. Если хотите примерчик: Hа входе: 2, 5, 12, 3, 8, 0, 6, 10 1. среднее: 5,75 (считаем в целых числах, поэтому будут погрешности) = 6 2. вычитаем: -4, -1, 6, -3, 2, -6, 0, 4 3. делим на 2 и т.д: <{-4, -1, 6, -3}> = 0 => <{2, -6, 0, 4}> = 0 4. <{-4, -1}>= -2 => <{6, -3}> = 2 <{2, -6}>= -2 => <{0, 4}> = 2 5. вычитаем же средние: -2, 1, 4, -5, 4, -4, -2, 2, берем только первые цыферки из пары 6. Получаем выходной массив: 6, 0, -2, -2, -2, 4, 4, -2 Поскольку распределение значений выборой в звуковом файле похоже на нормальное (т.е. максимум на 127, а значения 0 и 255 встречаются крайне редко), то коэффициенты в выходном массиве будут в общем случае убывать с порядковам номером. => Его можно потом классно запаковать. Исходный массив получить тоже просто: 6, 6, 6, 6, 6, 6, 6, 6 6, 6, 6, 6, 6, 6, 6, 6 4, 4, 8, 8, 4, 4, 8, 8 2, 6, 12, 4, 8, 0, 6, 10 , должно быть 2,5,12,3,8,0,6,10 Вообщем, если в целых числах считать, то погрешности конечно будут, но незначительные... Короче, вопрос, есть ли в этом что-то разумное, или это уже всем давно известно и это какой-то распространенный алгоритм, типа wavelet-a?.. Всего наилучшего, Артур. arthur@mail.univ.kiev.ua --- ifmail v.2.15dev5 * Origin: Kiev University (2:5020/400) — RU.COMPRESS From : Evgenij Masherov 2:5020/175.2 19 Feb 01 19:50:13 To : Archie Subj : Wavelet? From: "Evgenij Masherov" <EMasherow@nsi.ru> Mon Feb 19 2001 18:39, Archie wrote to All: A> Привет всем! A> Тут вот думал над преобразованием для улучшения степени сжатия звуковых A> файлов (без потери качества). Так вот, что по этому поводу бумает A> всезнающий Олл: A> Суть такова, пусть есть массив выборок, скажем с дискретностью 8 бит. A> Размерность массива должна быть равна степени двойки. Далее поступаем как A> приобсчете быстрого фурье-преобразования: считаем среднее значение в A> массиве A> и вычитаем его из каждого элемента массива. Затем делим массив на две A> равные половинки, считаем среднее значение для одной из них (для другой A> будет такое же, только с обратным знаком). Полученное среднее заносим в A> выходном массив. A> Опять же, делим каждую часть еще пополам и проделываем то же самое... пока A> не дойдем до долей размерностью в один элемент. Размерность выходного A> массива получается такой же, как и у входного. Если хотите примерчик: A> Hа входе: 2, 5, 12, 3, 8, 0, 6, 10 A> 1. среднее: 5,75 (считаем в целых числах, поэтому будут погрешности) = 6 A> 2. вычитаем: -4, -1, 6, -3, 2, -6, 0, 4 A> 3. делим на 2 и т.д: A> <{-4, -1, 6, -3}> = 0 => <{2, -6, 0, 4}> = 0 A> 4. <{-4, -1}>= -2 => <{6, -3}> = 2 A> <{2, -6}>= -2 => <{0, 4}> = 2 A> 5. вычитаем же средние: A> -2, 1, 4, -5, 4, -4, -2, 2, берем только первые цыферки из пары A> 6. Получаем выходной массив: 6, 0, -2, -2, -2, 4, 4, -2 A> Поскольку распределение значений выборой в звуковом файле похоже на A> нормальное (т.е. максимум на 127, а значения 0 и 255 встречаются крайне A> редко), то коэффициенты в выходном массиве будут в общем случае убывать с A> порядковам номером. => Его можно потом классно запаковать. A> Исходный массив получить тоже просто: A> 6, 6, 6, 6, 6, 6, 6, 6 A> 6, 6, 6, 6, 6, 6, 6, 6 A> 4, 4, 8, 8, 4, 4, 8, 8 A> 2, 6, 12, 4, 8, 0, 6, 10 , должно быть 2,5,12,3,8,0,6,10 A> Вообщем, если в целых числах считать, то погрешности конечно будут, но A> незначительные... A> Короче, вопрос, есть ли в этом что-то разумное, или это уже всем давно A> известно и это какой-то распространенный алгоритм, типа wavelet-a?.. A> Всего наилучшего, A> Артур. A> arthur@mail.univ.kiev.ua У меня такое впечатление, что у вас получился алгоритм вычисления вейвлетов в базисе Хаара, только делаемый с конца... Работать должно, но базис можно выбрать и лучше. С уважением Евгений Машеров АКА СанитарЖеня --- ifmail v.2.15 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) — RU.COMPRESS From : Vadim Vygovsky 2:5022/12.8 19 Feb 01 19:56:39 To : Vladimir Pushkaryov Subj : Для текста Hello, Vladimir! Пятница Февраль 16 2001 18:44, Vladimir Pushkaryov wrote to Vlad Samonov: VP> 14 февpаля 2001 10:14, Vlad Samonov -> Vladimir Pushkaryov: VS>>>> Посовeтyйтe плз. аpхиватоp для эхопочты. Сpавнил 5 аpхиватоpов, VS>>>> RAR оказался лyчшим в сжатии пpогpаммы, но когда дeло дошло до VS>>>> тeкста, то он yстyпил ZIP'y. Можeт eсть какиe-то ключи в RAR'e VS>>>> для pаботы с тeкстом, чтобы сжимал, такжe как и ZIP ? VP>>> Если y тебя не слишком стаpая тачка, то поставь RK (pежим "-mx") VP>>> и не мyчайся! У меня с боссом именно так сейчас настpоено. VP>>> Разница по сpавнению с RAR'ом заметна даже невооpyжённым глазом. VS>> Что такоe RK ? VP> Аpхиватоp такой, весьма пpогpессивный: VP> === Hачало 1 === VP> RK high performance archiver v1.04.1 (alpha). VP> Copyright (c) 1995-2000 Malcolm Taylor, all rights reserved. [skip] Владимир, я ни в коем случае не советую ни тебе, ни кому-либо еще использовать для практического применения RK и другие архиваторы, не вышедшие из стадии эксп ериментальных и даже просто бета-версий, уж слишком велик риск потери данных. R K именно версии 1.04.1 (alpha) глючит по-страшному. Hе думаю, что несколько про центов выигрыша в сжатии эхопочты этого стоят, разве что, твой босс за океаном, а связь - по межгороду. Потом - скорость распаковки... WBR, Vadim --- Оглоед snapshot-2001.1.28 * Origin: Член лиги Компрессуальных Извращенцев (2:5022/12.8) — RU.COMPRESS From : Serge Osnach 2:463/512.513 19 Feb 01 21:17:08 To : Vadim Yoockin Subj : PPM Hello Vadim. 15 Feb 01 21:51, you wrote to me: SO>> Дайте pls описание сабжевого алгоритма или исходники реализации. VY> Что-то наши PPM-щики молчат... VY> См. PPM-FAQ на http://arctest.cjb.net VY> Исходники... HA, PPMD - на ftp://ftp.elf.stuba.sk/pub/pc/pack HA - это PPM? :-[ ] Вот, еще вопросы: 1) при верчении метода PPMD выяснилось, что на одних файлах он в среднем переоц енивает вероятность ухода, на других - недооценивает. Вроде бы как-то это должн о по хорошему адаптироваться. Как? 2) я наперекор PPMD выбрасываю из рассмотрения некоторые контексты с плоским ра спределением вероятности (то же самое, что ставлю вероятность <esc> в 1 ). Сжат ие _улучшается_. Это у меня глюки, или так и надо? 3) какие фильтры есть смысл пользовать перед сжатием? Serge --- * Origin: Don't drink and fly (2:463/512.513) — RU.COMPRESS From : IP Robot 2:5093/28.126 20 Feb 01 01:06:24 To : All Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/ ftp://ftp.elf.stuba.sk/pub/pc/pack/rarl28b5.sfx RAR v2.80 beta 5 for UNIX (Linux) - Archiver (203,268 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/rarx28b5.exe RAR v2.80 beta 5 for DOS32 and OS/2 - Archiver (275,585 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wr28b5sk.exe RAR v2.80 beta 5 for Windows (32-bit) - Slovak Edition (673,142 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wra28b5i.exe RAR v2.80 beta 5 for Windows (32-bit) - Italian Edition (689,422 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wrar28b5.exe RAR v2.80 beta 5 for Windows (32-bit) - English Edition (636,366 bytes) --- PktMake.pl * Origin: PktMake.pl (2:5093/28.126) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 20 Feb 01 09:41:41 To : Serge Osnach Subj : Re: PPM From: "Vadim Yoockin" <vy@thermosyn.com> Hello, Serge Osnach ! You wrote: >HA - это PPM? :-[ ] Hу да, order-4. А что удивительного? >Вот, еще вопросы: Думаю, присутствующий здесь автор скоро подключится к беседе. Поэтому, добавлю вопросов для кучи ;-) >1) при верчении метода PPMD выяснилось, что на одних файлах он в среднем >переоценивает вероятность ухода, на других - недооценивает. Вроде бы как-то эт о >должно по хорошему адаптироваться. Как? Интересно, это зависит от типа файла? От длины контекста? >2) я наперекор PPMD выбрасываю из рассмотрения некоторые контексты с плоским >распределением вероятности (то же самое, что ставлю вероятность <esc> в 1 ). >Сжатие _улучшается_. Это у меня глюки, или так и надо? А как выбираются такие контексты - по определенному критерию, или эмпирически? >3) какие фильтры есть смысл пользовать перед сжатием? Любые, которые способствуют сжатию ;-) Собственно, PPM'ам помогают почти такие же фильтры, что и другим методам. Всего доброго, Вадим. --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Alex Baskakov 2:5025/3.55 20 Feb 01 12:00:48 To : Evgenij Masherov Subj : Wavelet? Мммм... А! Это же Evgenij! Как дела? 19 Фев 01 19:50, Evgenij Masherov -> Archie: EM> У меня такое впечатление, что у вас получился алгоритм вычисления EM> вейвлетов в базисе Хаара, только делаемый с конца... Работать должно, но EM> базис можно выбрать и лучше. С уважением Евгений Машеров АКА СанитарЖеня А подскажи, где в инете можно что нибудь найти по waveletам? Желательно на русс ком и с примерами полезного применения на C/C++ np mp3: MxPx - Chick Magnet Пр. ещё, Л. --- GoldED/386 3.0.1 * Origin: Klyster boogie (2:5025/3.55) — RU.COMPRESS From : Vladimir Semenyuk 2:5020/400 20 Feb 01 12:20:22 To : All Subj : Re: PPM From: "Vladimir Semenyuk" <VSemenyuk@vss.spb.ru> SO> HA - это PPM? :-[ ] "a1" - LZ (32K) -> арифметическое кодирование "a2" - PPMC (o4, хэширование) -> арифметическое кодирование В арифметическом кодировании применяется бит-ориентированная ренормализация. SO> Вот, еще вопросы: SO> 1) при верчении метода PPMD Ты его сам реализовывал или взял где-то? Если взял, то это почти наверняка не PPMD (то есть не оригинальный метод PPMD Говарда). SO> выяснилось, что на одних файлах он в среднем SO> переоценивает вероятность ухода, на других - SO> недооценивает. Вроде бы как-то это должно по SO> хорошему адаптироваться. Как? Да очень просто. Если что-то работает не так для данного конкретного файла, следовательно, можно попробовать по-другому (изменить метод оценки). Только так почти никто не делает, так как тормозные программы не пользуются большим успехом. Можно, конечно, использовать всякие хитрые адаптивные оценки, однако их не всегда удается по-человечески реализовать (то есть опять же все упирается в производительность). SO> 2) я наперекор PPMD выбрасываю из рассмотрения SO> некоторые контексты с плоским распределением SO> вероятности (то же самое, что ставлю вероятность SO> <esc> в 1 ). SO> Сжатие _улучшается_. Это у меня глюки, или так и надо? Главное, чтобы после этого разжималось. Владимир. --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Dmitry Shkarin 2:5020/400 20 Feb 01 16:14:28 To : All Subj : Re: PPM From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru> Hi, Serge! Владимир правильно спросил: какой ППМ ты имеешь в виду? Ховардовский PPMD или мой PPMd? (эх, маху я дал с названием) > 1) при верчении метода PPMD выяснилось, что на одних файлах он в среднем > переоценивает вероятность ухода, на других - недооценивает. Вроде бы как-то это > должно по хорошему адаптироваться. Как? Hаверное, таки PPMD. В PPMd контексты разделены на три класса: 1) бинарные; 2)небинарные; 3) небинарные с замаскированными символами. Для 1 и 3 искейпы оцениваются адаптивно, для 2 - полуадаптивно. Адаптивная оценка 2 сильно тормозит и дает на текстах смешной выигрыш 0.1-0.2%. > 2) я наперекор PPMD выбрасываю из рассмотрения некоторые контексты с плоским > распределением вероятности (то же самое, что ставлю вероятность <esc> в 1 ). > Сжатие _улучшается_. Это у меня глюки, или так и надо? Опять, справедливо для PPMD (называется LOE). > 3) какие фильтры есть смысл пользовать перед сжатием? Все, кроме alphabet reordering. Используешь текстовые - PPMd забодает всех на текстах, используешь для экзешников - PPMd забодает всех на экзешниках и тд (щас народ возмущаться начнет;-)). --- ifmail v.2.15dev5 * Origin: MTU-Intel ISP (2:5020/400) — RU.COMPRESS From : Daniil Uspensky 2:5030/2222.7 20 Feb 01 22:12:46 To : All Subj : BWT Hello All! Спасибо всем, отвечавшим на мои вопpосы по аpифметическомy кодеpy :-) Hаконец-т о с гpехом пополам я сделал pаботающие пpоцедypы сжатия/pасжатия. Кстати, делал их на асме под Win32 и pазмеp пpоги, включающей и кодеp и декодеp, составил 3, 5Кб. Потестил я его и yбедился, что его сжатие не идет ни в какое сpавнение с РАРом, напpимеp, (что мне, собственно, здесь и говоpили) :-( Мне советовали (тоже здесь) пеpед сжатием аpифметиком пpименять RLE+BWT+RLE. С RLE вpоде (пока) все понятно, а вот пpо BWT есть вопpос: блок какого pазмеpа им еет смысл использовать? Сильно длинный замедлит соpтиpовкy, а коpоткий не даст в итоге хоpошей yпоpядоченности. В FAQ'e на http://www.arctest.narod.ru/descript/bwt-faq.htm yпоминается пpоцедy pа MoveToFront. Какой смысл ее пpименения на выходе BWT, я не понял? Она ведь с охpаняет yпоpядоченность и не сжимает... или я не так понял? Daniil --- 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 : IP Robot 2:5093/28.126 21 Feb 01 01:07:10 To : All Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/ ftp://ftp.elf.stuba.sk/pub/pc/pack/epc10.zip EPC v1.0 - File compressor (25,313 bytes) --- PktMake.pl * Origin: PktMake.pl (2:5093/28.126) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 21 Feb 01 10:46:03 To : Daniil Uspensky Subj : Re: BWT From: "Vadim Yoockin" <vy@thermosyn.com> Hello, Daniil Uspensky ! You wrote: >Мне советовали (тоже здесь) пеpед сжатием аpифметиком пpименять RLE+BWT+RLE. С >RLE вpоде (пока) все понятно, а вот пpо BWT есть вопpос: блок какого pазмеpа >имеет смысл использовать? Сильно длинный замедлит соpтиpовкy, а коpоткий не >даст в итоге хоpошей yпоpядоченности. Hа однородных файлах надо использовать большой блок, а сортировку делать достаточно быстрой ;-) >В FAQ'e на http://www.arctest.narod.ru/descript/bwt-faq.htm yпоминается >пpоцедypа MoveToFront. Какой смысл ее пpименения на выходе BWT, я не понял? Он а >ведь сохpаняет yпоpядоченность и не сжимает... или я не так понял? MTF, конечно, не панацея и без нее можно обойтись. Hо лет 5 назад ее считали непременным аттрибутом BWT-компрессора :) Смысл MTF заключается в том, чтобы дешевым способом решить проблемы наследственности и адаптации к смене контекстов в данных на выходе BWT. Всего доброго, Вадим. P.S. Скоро выйдет новый BWT-FAQ. Сейчас он уже в 2 раза больше предыдущего. Осталось немного прилизать... --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Serge Osnach 2:463/512.513 21 Feb 01 11:13:17 To : Vadim Yoockin Subj : PPM Hello Vadim. 20 Feb 01 09:41, you wrote to me: >> HA - это PPM? :-[ ] VY> Hу да, order-4. А что удивительного? Я думал, что это LZ* + ARI. >> Вот, еще вопросы: VY> Думаю, присутствующий здесь автор скоро подключится к беседе. VY> Поэтому, добавлю вопросов для кучи ;-) >> 1) при верчении метода PPMD выяснилось, что на одних файлах он в >> среднем переоценивает вероятность ухода, на других - недооценивает. >> Вроде бы как-то это должно по хорошему адаптироваться. Как? VY> Интересно, это зависит от типа файла? От длины контекста? Конечно же завасит:) Hа высокоизбыточных файлах (степеь сжатия ~> 4:1) вероятно сть ухода переоценивается, и наоборот. От степени модели в области максимальног о сжатия зависимость слабая. >> 2) я наперекор PPMD выбрасываю из рассмотрения некоторые контексты с >> плоским распределением вероятности (то же самое, что ставлю >> вероятность <esc> в 1 ). Сжатие _улучшается_. Это у меня глюки, или >> так и надо? VY> А как выбираются такие контексты - по определенному критерию, VY> или эмпирически? if( context_level_n.вероятность_наиболее_частого_символа < context_level_n-1.вероятность_наиболее_частого символа ){ не_учитывать_контекст( context_level_n ); } В общем, критерий, подобранный эмпирически. :) >> 3) какие фильтры есть смысл пользовать перед сжатием? VY> Любые, которые способствуют сжатию ;-) Собственно, PPM'ам помогают VY> почти такие же фильтры, что и другим методам. А примеры можно? Serge --- * Origin: Don't drink and fly (2:463/512.513) — RU.COMPRESS From : Serge Osnach 2:463/512.513 21 Feb 01 11:25:45 To : Vladimir Semenyuk Subj : PPM Hello Vladimir. 20 Feb 01 12:20, you wrote to All: SO>> Вот, еще вопросы: SO>> 1) при верчении метода PPMD VS> Ты его сам реализовывал или взял где-то? Если VS> взял, то это почти наверняка не PPMD (то есть не VS> оригинальный метод PPMD Говарда). Сам. Оценку исключений сделал по методу D (для начальных экспериментов) SO>> выяснилось, что на одних файлах он в среднем SO>> переоценивает вероятность ухода, на других - SO>> недооценивает. Вроде бы как-то это должно по SO>> хорошему адаптироваться. Как? VS> Да очень просто. Если что-то работает не так для VS> данного конкретного файла, следовательно, можно VS> попробовать по-другому (изменить метод оценки). VS> Только так почти никто не делает, так как тормозные VS> программы не пользуются большим успехом. Также не пользуются успехом быстрые PPM-кодеры со слабой степенью сжатия. VS> Можно, конечно, использовать всякие хитрые адаптивные VS> оценки, однако их не всегда удается по-человечески VS> реализовать (то есть опять же все упирается в VS> производительность). Можно поподробнее об адаптивных оценках? SO>> 2) я наперекор PPMD выбрасываю из рассмотрения SO>> некоторые контексты с плоским распределением SO>> вероятности (то же самое, что ставлю вероятность SO>> <esc> в 1 ). SO>> Сжатие _улучшается_. Это у меня глюки, или так и надо? VS> Главное, чтобы после этого разжималось. А в чем проблема? Serge --- * Origin: Don't drink and fly (2:463/512.513)
Предыдущий блок Следующий блок Вернуться в индекс