| Предыдущий блок | Следующий блок | Вернуться в индекс |
— RU.COMPRESS From : Vadim Yoockin 2:5020/400 25 Jul 00 11:29:21 To : ZAB Subj : Re: Что посоветуете? From: "Vadim Yoockin" <vy@thermosyn.com> Hello, ZAB ! You wrote: >> Hезачем это. Задача-то - в подсчете числа одинаковых контекстов. >> Для уникальных же контекстов обратное преобразование ничем >> не отличается от BWT-шного. > >Ага! Только вот для такого подсчёта потребуется ~4 Гб!!! А это как считать... Ведь не надо считать все контексты одновременно. Всего доброго, Вадим. --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 25 Jul 00 22:08:05 To : Eugene Goncharuk Subj : Энтропия * Originally in RU.COMPRESS Hello Eugene! Wednesday July 26 2000, Eugene Goncharuk writes to All: EG> Как измерить энтропию файла ? EG> Я так полагаю, что у файла состоящего из нулей она будет мааленькая а EG> у скажем doom.wad она будет несколько побольше, как её численно EG> измерить? степенью сжатия. абсолютного, независимого от архиваторов, числа нет Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Andrew Aksyonoff 2:5036/29.2 26 Jul 00 01:05:03 To : Eugene Goncharuk Subj : Энтропия Hello Eugene! 26 Jul 00 01:00, Eugene Goncharuk wrote to All: EG> Как измерить энтропию файла ? Вся проблема в том, что она зависит от используемой модели источника данных. Чем лучше модель, тем меньше энтропия. ;) - Andrew ... and thinking is not really something they are cut out for... --- ged386-pl2.50-dos & * Origin: unknown. (2:5036/29.2) — RU.COMPRESS From : Eugene Goncharuk 2:5045/27.51 26 Jul 00 02:00:28 To : All Subj : Энтропия Как поживаете, All ? Как измерить энтропию файла ? Я так полагаю, что у файла состоящего из нулей она будет мааленькая а у скажем doom.wad она будет несколько побольше, как её численно измерить? C уважением, Eugene Goncharuk. --- УТВЕРЖДАЮ. MSG-редактор капитан 2.5 ранга Голд Дедович фор ДОС UNREG * Origin: Как SP не исправляй, он все в стек смотрит (2:5045/27.51) — RU.COMPRESS From : ZAB 2:5020/400 26 Jul 00 02:31:12 To : All Subj : Re: Что посоветуете? From: "ZAB" <ZAnatolyB@mail.ru> Vadim Yoockin <vy@thermosyn.com> сообщил в новостях следующее:8ljevp$bb8$1@news.kiev.sovam.com... > Hello, ZAB ! You wrote: > > >Может я чё не понимаю в теории, но по хешу не так просто индексироваться, > >нужна процедура поиска! > > Зато хэш более устойчив к большому количеству похожих контекстов. > > >Я уже так сдалал, т.е. собираю массив из N 4-ёх > >байтных элементов (контекстов), и ещё один такой же, но вместо контекстов в > >нём индексы на исходный блок, потом ещё массив 0..65535 для того, чтобы > >бинарный поиск по первому массиву начинался с диапозона на более 655536, > >т.е. этот третий массив является таблицей индексов на первые 2 байта > >контекстов! Помоему реализачия вполне оптимальна, по крайней мере для > >обратного преобразования 3-ёх мегабайт (всех целиком, одним блоком) ей надо > >~3,5 секунды! > > А если весь блок состоит из одинаковых символов, сколько требуется времени? > ;) Упаковка 8 сек! Распаковка 8 сек! > Кстати, для чистоты эксперимента сравни с szip'ом. > >ЗЫ: Для шифровки требуется 4,5 секунд! Кто сказал, что распаковка > >тормознутее? > > А это странно. Может, у тебя прямое преобразование какое-то не то? > Там же делов-то - на пару проходов radix-sort'а. Радикс, это тот, что на два массива делит? У меня не он, я по битам сортирую, именно по этому и вышел тормоз, при однородном содержимым, ему пришлось каждый раз весь массив сортировать (для каждого бита и индекса - 64 раза)! > >ЗЗЫ: После оптимизации процедур сортировки: > >паковка (преобразование): 4,203 сек > >распаковка (преобразование): 3,3 сек > >Жрёт 35 мегов в пиковой нагрузке и мне кажется, что уменьшать размер блока > >меннее 3-ёх мегабайт нет необходимости! > > Это да. > >ЗЗЗЫ: Кстати! Какой порядок контекстов даёт лучший результат? Ато доделать > >это до 8 - 12 можно без потерь в скорость более 1 секунды! > > За исключением некоторых данных, чем больше - тем лучше. > Hа большинстве текстов 8-12 будет вполне достаточно. Ладно! Значит буду дорабатывать до 12! ЗЫ: Совсем забыл о машине! P-III 500 (разогнан по шине до 560) 64 мега оперативки! --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : ZAB 2:5020/400 26 Jul 00 02:31:15 To : All Subj : Re: Что посоветуете? From: "ZAB" <ZAnatolyB@Mail.ru> Vadim Yoockin <vy@thermosyn.com> сообщил в новостях следующее:8ljevp$bb8$1@news.kiev.sovam.com... > Hello, ZAB ! You wrote: > > >Может я чё не понимаю в теории, но по хешу не так просто индексироваться, > >нужна процедура поиска! > > Зато хэш более устойчив к большому количеству похожих контекстов. > > >Я уже так сдалал, т.е. собираю массив из N 4-ёх > >байтных элементов (контекстов), и ещё один такой же, но вместо контекстов в > >нём индексы на исходный блок, потом ещё массив 0..65535 для того, чтобы > >бинарный поиск по первому массиву начинался с диапозона на более 655536, > >т.е. этот третий массив является таблицей индексов на первые 2 байта > >контекстов! Помоему реализачия вполне оптимальна, по крайней мере для > >обратного преобразования 3-ёх мегабайт (всех целиком, одним блоком) ей надо > >~3,5 секунды! > > А если весь блок состоит из одинаковых символов, сколько требуется времени? > ;) Упаковка 8 сек! Распаковка 8 сек! > Кстати, для чистоты эксперимента сравни с szip'ом. > >ЗЫ: Для шифровки требуется 4,5 секунд! Кто сказал, что распаковка > >тормознутее? > > А это странно. Может, у тебя прямое преобразование какое-то не то? > Там же делов-то - на пару проходов radix-sort'а. Радикс, это тот, что на два массива делит? У меня не он, я по битам сортирую, именно по этому и вышел тормоз, при однородном содержимым, ему пришлось каждый раз весь массив сортировать (для каждого бита и индекса - 64 раза)! > >ЗЗЫ: После оптимизации процедур сортировки: > >паковка (преобразование): 4,203 сек > >распаковка (преобразование): 3,3 сек > >Жрёт 35 мегов в пиковой нагрузке и мне кажется, что уменьшать размер блока > >меннее 3-ёх мегабайт нет необходимости! > > Это да. > >ЗЗЗЫ: Кстати! Какой порядок контекстов даёт лучший результат? Ато доделать > >это до 8 - 12 можно без потерь в скорость более 1 секунды! > > За исключением некоторых данных, чем больше - тем лучше. > Hа большинстве текстов 8-12 будет вполне достаточно. Ладно! Значит буду дорабатывать до 12! ЗЫ: Совсем забыл о машине! P-III 500 (разогнан по шине до 560) 64 мега оперативки! --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : ZAB 2:5020/400 26 Jul 00 02:31:27 To : All Subj : Re: Что посоветуете? From: "ZAB" <ZAnatolyB@mail.ru> Vadim Yoockin <vy@thermosyn.com> сообщил в новостях следующее:8ljevp$bb8$1@news.kiev.sovam.com... > Hello, ZAB ! You wrote: > > >Может я чё не понимаю в теории, но по хешу не так просто индексироваться, > >нужна процедура поиска! > > Зато хэш более устойчив к большому количеству похожих контекстов. > > >Я уже так сдалал, т.е. собираю массив из N 4-ёх > >байтных элементов (контекстов), и ещё один такой же, но вместо контекстов в > >нём индексы на исходный блок, потом ещё массив 0..65535 для того, чтобы > >бинарный поиск по первому массиву начинался с диапозона на более 655536, > >т.е. этот третий массив является таблицей индексов на первые 2 байта > >контекстов! Помоему реализачия вполне оптимальна, по крайней мере для > >обратного преобразования 3-ёх мегабайт (всех целиком, одним блоком) ей надо > >~3,5 секунды! > > А если весь блок состоит из одинаковых символов, сколько требуется времени? > ;) Упаковка 8 сек! Распаковка 8 сек! > Кстати, для чистоты эксперимента сравни с szip'ом. > >ЗЫ: Для шифровки требуется 4,5 секунд! Кто сказал, что распаковка > >тормознутее? > > А это странно. Может, у тебя прямое преобразование какое-то не то? > Там же делов-то - на пару проходов radix-sort'а. Радикс, это тот, что на два массива делит? У меня не он, я по битам сортирую, именно по этому и вышел тормоз, при однородном содержимым, ему пришлось каждый раз весь массив сортировать (для каждого бита и индекса - 64 раза)! > >ЗЗЫ: После оптимизации процедур сортировки: > >паковка (преобразование): 4,203 сек > >распаковка (преобразование): 3,3 сек > >Жрёт 35 мегов в пиковой нагрузке и мне кажется, что уменьшать размер блока > >меннее 3-ёх мегабайт нет необходимости! > > Это да. > >ЗЗЗЫ: Кстати! Какой порядок контекстов даёт лучший результат? Ато доделать > >это до 8 - 12 можно без потерь в скорость более 1 секунды! > > За исключением некоторых данных, чем больше - тем лучше. > Hа большинстве текстов 8-12 будет вполне достаточно. Ладно! Значит буду дорабатывать до 12! ЗЫ: Совсем забыл о машине! P-III 500 (разогнан по шине до 560) 64 мега оперативки! --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : ZAB 2:5020/400 26 Jul 00 02:31:29 To : All Subj : Re: Что посоветуете? From: "ZAB" <ZAnatolyB@Mail.ru> Vadim Yoockin <vy@thermosyn.com> сообщил в новостях следующее:8ljevp$bb8$1@news.kiev.sovam.com... > Hello, ZAB ! You wrote: > > >Может я чё не понимаю в теории, но по хешу не так просто индексироваться, > >нужна процедура поиска! > > Зато хэш более устойчив к большому количеству похожих контекстов. > > >Я уже так сдалал, т.е. собираю массив из N 4-ёх > >байтных элементов (контекстов), и ещё один такой же, но вместо контекстов в > >нём индексы на исходный блок, потом ещё массив 0..65535 для того, чтобы > >бинарный поиск по первому массиву начинался с диапозона на более 655536, > >т.е. этот третий массив является таблицей индексов на первые 2 байта > >контекстов! Помоему реализачия вполне оптимальна, по крайней мере для > >обратного преобразования 3-ёх мегабайт (всех целиком, одним блоком) ей надо > >~3,5 секунды! > > А если весь блок состоит из одинаковых символов, сколько требуется времени? > ;) Упаковка 8 сек! Распаковка 8 сек! > Кстати, для чистоты эксперимента сравни с szip'ом. > >ЗЫ: Для шифровки требуется 4,5 секунд! Кто сказал, что распаковка > >тормознутее? > > А это странно. Может, у тебя прямое преобразование какое-то не то? > Там же делов-то - на пару проходов radix-sort'а. Радикс, это тот, что на два массива делит? У меня не он, я по битам сортирую, именно по этому и вышел тормоз, при однородном содержимым, ему пришлось каждый раз весь массив сортировать (для каждого бита и индекса - 64 раза)! > >ЗЗЫ: После оптимизации процедур сортировки: > >паковка (преобразование): 4,203 сек > >распаковка (преобразование): 3,3 сек > >Жрёт 35 мегов в пиковой нагрузке и мне кажется, что уменьшать размер блока > >меннее 3-ёх мегабайт нет необходимости! > > Это да. > >ЗЗЗЫ: Кстати! Какой порядок контекстов даёт лучший результат? Ато доделать > >это до 8 - 12 можно без потерь в скорость более 1 секунды! > > За исключением некоторых данных, чем больше - тем лучше. > Hа большинстве текстов 8-12 будет вполне достаточно. Ладно! Значит буду дорабатывать до 12! ЗЫ: Совсем забыл о машине! P-III 500 (разогнан по шине до 560) 64 мега оперативки! --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : ZAB 2:5020/400 26 Jul 00 02:31:31 To : All Subj : Re: Что посоветуете? From: "ZAB" <ZAnatolyB@mail.ru> Vadim Yoockin <vy@thermosyn.com> сообщил в новостях следующее:8ljevp$bb8$1@news.kiev.sovam.com... > Hello, ZAB ! You wrote: > > >Может я чё не понимаю в теории, но по хешу не так просто индексироваться, > >нужна процедура поиска! > > Зато хэш более устойчив к большому количеству похожих контекстов. > > >Я уже так сдалал, т.е. собираю массив из N 4-ёх > >байтных элементов (контекстов), и ещё один такой же, но вместо контекстов в > >нём индексы на исходный блок, потом ещё массив 0..65535 для того, чтобы > >бинарный поиск по первому массиву начинался с диапозона на более 655536, > >т.е. этот третий массив является таблицей индексов на первые 2 байта > >контекстов! Помоему реализачия вполне оптимальна, по крайней мере для > >обратного преобразования 3-ёх мегабайт (всех целиком, одним блоком) ей надо > >~3,5 секунды! > > А если весь блок состоит из одинаковых символов, сколько требуется времени? > ;) Упаковка 8 сек! Распаковка 8 сек! > Кстати, для чистоты эксперимента сравни с szip'ом. > >ЗЫ: Для шифровки требуется 4,5 секунд! Кто сказал, что распаковка > >тормознутее? > > А это странно. Может, у тебя прямое преобразование какое-то не то? > Там же делов-то - на пару проходов radix-sort'а. Радикс, это тот, что на два массива делит? У меня не он, я по битам сортирую, именно по этому и вышел тормоз, при однородном содержимым, ему пришлось каждый раз весь массив сортировать (для каждого бита и индекса - 64 раза)! > >ЗЗЫ: После оптимизации процедур сортировки: > >паковка (преобразование): 4,203 сек > >распаковка (преобразование): 3,3 сек > >Жрёт 35 мегов в пиковой нагрузке и мне кажется, что уменьшать размер блока > >меннее 3-ёх мегабайт нет необходимости! > > Это да. > >ЗЗЗЫ: Кстати! Какой порядок контекстов даёт лучший результат? Ато доделать > >это до 8 - 12 можно без потерь в скорость более 1 секунды! > > За исключением некоторых данных, чем больше - тем лучше. > Hа большинстве текстов 8-12 будет вполне достаточно. Ладно! Значит буду дорабатывать до 12! ЗЫ: Совсем забыл о машине! P-III 500 (разогнан по шине до 560) 64 мега оперативки! --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : Vladimir Vassilevsky 2:5020/400 26 Jul 00 02:35:54 To : All Subj : Re: Упаковка сигнала в real-time From: Vladimir Vassilevsky <vlv@fullnet.net> Andre N Belokon wrote: > > Vladimir Vassilevsky <vlv@fullnet.net> сообщил в новостях > следующее:3972F93E.7E0D43C2@fullnet.net... > > Hапример, предсказатель первого > > порядка идеально предсказывает константу, второго порядка - экспоненты и > > синусоиды, более высокие порядки - более сложные стационарные процессы. > > Вычисление коэффициентов предсказания - достаточно сложная задача, > > которая не ляжет в палку. Передавать надо только текущую ошибку > > предсказания. При достаточно высоком порядке ошибка предсказания > > является [почти] Гауссовским случайным процессом с распределением типа > > exp(-x*x) > > скажу пару слов касательно LPC. возился я с ним применительно к вопросу > lossless компрессии аудио-сигналов. работа велась с несколькими музыкальными > CD-треками. дискретизация 44100 16 бит. сигнал разбивался на фреймы и для > каждого фрейма вычислялись коэффициенты LPC. и вот что интересно - LPC > высоких порядков (10-12) показывают худший результат по сравнению с более > низкими порядками (3-5). под худшим результатом подразумевается большая > дисперсия ошибки предсказания. > > "обскакал" всех другой алгоритм (на всякий случай ставим (с) :)) адаптивного > LPC. суть следующая. есть небольшое окно. на основании отсчетов этого окна > вычисляем LPC невысокого порядка. предсказываем след. отсчет. сдвигаем окно > на один отсчет и добавляем только что закодированный отсчет в окно. + и - > такого алгоритма: +коэффициенты LPC никогда не передаются в явном виде. > +повышенная адаптивность ко входному сигналу. -меньшее быстродействие. > > будет интересно узнать мнение общественности - изобретен велосипед или > вечный двигатель ? :)) > > PS если кто-то работает над вопросами lossless копрессии аудиосигналов и > статических изображений - будет интересно пообщаться > > -- > WBR Andre N Belokon > http://softlab.od.ua > http://algo.4u.ru --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Vladimir Vassilevsky 2:5020/400 26 Jul 00 02:37:12 To : All Subj : Re: Упаковка сигнала в real-time From: Vladimir Vassilevsky <vlv@fullnet.net> Andre N Belokon wrote: > > скажу пару слов касательно LPC. возился я с ним применительно к вопросу > lossless компрессии аудио-сигналов. работа велась с несколькими музыкальными > CD-треками. :)))) Аналогично. > дискретизация 44100 16 бит. сигнал разбивался на фреймы и для > каждого фрейма вычислялись коэффициенты LPC. и вот что интересно - LPC > высоких порядков (10-12) показывают худший результат по сравнению с более > низкими порядками (3-5). под худшим результатом подразумевается большая > дисперсия ошибки предсказания. > "обскакал" всех другой алгоритм (на всякий случай ставим (с) :)) адаптивного > LPC. суть следующая. есть небольшое окно. на основании отсчетов этого окна > вычисляем LPC невысокого порядка. предсказываем след. отсчет. сдвигаем окно > на один отсчет и добавляем только что закодированный отсчет в окно. + и - > такого алгоритма: +коэффициенты LPC никогда не передаются в явном виде. > +повышенная адаптивность ко входному сигналу. -меньшее быстродействие. Я делал так: вычислял LPC в скользящем окне, пересчитывая коэффициенты для каждого нового отсчета, используя для вычисления предыдущие значения сигнала, т.е. сами коэфф. ЛПК не передаются. Оптимальный порядок LPC для музыки 44khz/16bit получался ~ 64, длина окна ~ 512 отсчетов. Форма окна тоже существенна - наилучшие результаты получались с окном Хемминга (а вовсе не Барнвелла, как ни странно). Выигрыш от ЛПК получался порядка 20dB, и еще порядка 3dB может дать предсказание основного тона. Остаточная ошибка дожимается по Хаффману. При сжатии без потерь можно съекономить примерно до восьми бит на отсчет, впрочем, это весьма зависит от содержания трека. > будет интересно узнать мнение общественности - изобретен велосипед или > вечный двигатель ? :)) Технология с вычислением коэфф. ЛПК по сигналу хорошо известна и используется, например, в стандарте LDCELP G.728. У этой технологии есть три основных недостатка: 1. При быстром изменении спектра сигнала ЛПК адаптируется не оптимальным образом. 2. Если алгоритм сжатия с потерями, то при некоторых условиях получается размножение потерь. 3. Большой объем вычислений. > PS если кто-то работает над вопросами lossless копрессии аудиосигналов и > статических изображений - будет интересно пообщаться Мы так, плюшками балуемся. Вообще-то существует формат MLP (Meridian Loseless Packing, если не подводит память), специально для сжатия аудио без потерь. Точно не знаю, как построен их алгоритм, но сжатие примерно двухкратное. VLV --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Alexey Komarov 2:5054/66.1 26 Jul 00 02:45:22 To : Eugene Goncharuk Subj : Энтpопия Пpивет, Eugene! 26 Июл 00 в 02:00 ты писал All: EG> Как измеpить энтpопию файла ? А хотя бы диспеpсию для начала посчитать и сpавнить с найденной для известных т ипов файлов? Там yже ваpианты... Пpостой способ - по степени сжатия известными аpхиватоpами :)) EG> Я так полагаю, что y файла состоящего из нyлей она бyдет мааленькая а EG> y скажем doom.wad она бyдет несколько побольше, как её численно EG> измеpить? А она вообще имеет точное количественное опpеделение? :-\ С yважением, Alexey --- GoldED+/W32 1.1.4.5 * Origin: KewlZyzop of MelodyHacker station (2:5054/66.1) — RU.COMPRESS From : Andre N Belokon 2:5020/400 26 Jul 00 04:50:57 To : All Subj : Re: Упаковка сигнала в real-time From: "Andre N Belokon" <algo@softlab.od.ua> Reply-To: "Andre N Belokon" <algo@softlab.od.ua> Vladimir Vassilevsky <vlv@fullnet.net> сообщил в новостях следующее:397D7DF3.A4416E75@fullnet.net... > Я делал так: вычислял LPC в скользящем окне, пересчитывая коэффициенты > для каждого нового отсчета, используя для вычисления предыдущие значения > сигнала, т.е. сами коэфф. ЛПК не передаются. делал тоже самое > Оптимальный порядок LPC для > музыки 44khz/16bit получался ~ 64, длина окна ~ 512 отсчетов. wow - порядок 64 - это не сильно ли много ??? очень сильно зависит от типа сигнала. на "жестких" джаз-роковых композициях окно и порядок гораздо меньше - я выходил на порядок 3-7 при окне 32-64. > Форма окна > тоже существенна - наилучшие результаты получались с окном Хемминга (а > вовсе не Барнвелла, как ни странно). с окном вообще ничего не делал - прямоугольное тоесть. надо будет попробовать > Выигрыш от ЛПК получался порядка > 20dB странно, я выходил на большие цифры, хотя и не намного. > и еще порядка 3dB может дать предсказание основного тона. imho хорошо для speech, но не для audio > Остаточная ошибка дожимается по Хаффману. тут тоже есть над чем подумать. это всетаки не алфавит из 256 символов дожимать. > Мы так, плюшками балуемся. > Вообще-то существует формат MLP (Meridian Loseless Packing, если не > подводит память), специально для сжатия аудио без потерь. Точно не знаю, > как построен их алгоритм, но сжатие примерно двухкратное. 2х кратное - мало. я тут с нейросетками в качестве предиктора побаловался - результаты более чем впечатляющие, хотя процесс сжатия дюже медленный. imho реально достичь типичного сжатия 1:3 - 1:5 и 1:2 на очень "плохом сигнале". -- WBR Andre N Belokon http://softlab.od.ua http://algo.4u.ru --- ifmail v.2.15dev5 * Origin: Rostelecom/Internet Centre (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 26 Jul 00 10:20:56 To : ZAB Subj : Re: Что посоветуете? From: "Vadim Yoockin" <vy@thermosyn.com> Hello, ZAB ! You wrote: >> А если весь блок состоит из одинаковых символов, сколько требуется >времени? >> ;) > >Упаковка 8 сек! Распаковка 8 сек! Молодец, это вполне хорошая устойчивость к вырожденным данным. >> >ЗЫ: Для шифровки требуется 4,5 секунд! Кто сказал, что распаковка >> >тормознутее? >> >> А это странно. Может, у тебя прямое преобразование какое-то не то? >> Там же делов-то - на пару проходов radix-sort'а. > >Радикс, это тот, что на два массива делит? У меня не он, я по битам >сортирую, именно по этому и вышел тормоз, при однородном содержимым, ему >пришлось каждый раз весь массив сортировать (для каждого бита и индекса - 64 >раза)! 64 прохода по файлу - это многовато. Лучше сделай сортировку по словам. Для большого блока это должно окупиться. >ЗЫ: Совсем забыл о машине! P-III 500 (разогнан по шине до 560) 64 мега >оперативки! Чтобы не привязываться в измерениях к машине, все ж сравни с szip'ом. Правда, там около половины времени отжирает кодер... Всего доброго, Вадим. --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Andrew Filinsky 2:452/4.11 26 Jul 00 14:18:43 To : All Subj : Как быстpо отсоpтиpовать стpоки в BWT? -++++++++¬ С гоpячим электpонным пpиветом! LTTTTTTTT- Как быстpо отсоpтиpовать стpоки в BWT? Я вижу несколько ваpиантов: 1. /QuickSort/. 2. /HeapSort/. Однако оба ваpианта стpадают тем недостатком, что количество сpавнений стpок имеет сложность O(n*log(n)), что само по себе неплохо, но вот пpи сpавнении множества почти одинаковых стpок пpиводит к катастpофическим pезультатам. 3. /Деpево контекстов/. Возможно, это называется как-то иначе, но по стpуктуpе напоминает Деpево контекстов для PPM. В общем-то, пpоблема та же. Пpи внесении почти одинаковых стpок длина ветвей (и вpемя внесения стpоки) недопустимо велика. _Вопpос_: Как гpамотно отсоpтиpовать стpоки в BWT, чтобы наличие множества почти одинаковых стpок не сказывалось на вpемени соpтиpовки катастpофическим обpазом? С моих слов записано веpно. Andrew Filinsky. --- No tears GoldED+/W32 * Origin: Теpпение... (2:452/4.11) — RU.COMPRESS From : Vladimir Vassilevsky 2:5020/400 26 Jul 00 16:02:56 To : All Subj : Re: Упаковка сигнала в real-time From: Vladimir Vassilevsky <vlv@fullnet.net> Andre N Belokon wrote: > > > Я делал так: вычислял LPC в скользящем окне, пересчитывая коэффициенты > > для каждого нового отсчета, используя для вычисления предыдущие значения > > сигнала, т.е. сами коэфф. ЛПК не передаются. > > делал тоже самое Кстати, не обязательно пересчитывать коэффициенты на каждый новый отсчет. Вполне достаточно делать это раз на десяток отсчетов. > > Оптимальный порядок LPC для > > музыки 44khz/16bit получался ~ 64, длина окна ~ 512 отсчетов. > > wow - порядок 64 - это не сильно ли много ??? IMHO 32...64 - в самый раз. > очень сильно зависит от типа сигнала. на "жестких" джаз-роковых композициях > окно и порядок гораздо меньше - я выходил на порядок 3-7 при окне 32-64. > > > Форма окна > > тоже существенна - наилучшие результаты получались с окном Хемминга (а > > вовсе не Барнвелла, как ни странно). > > с окном вообще ничего не делал - прямоугольное тоесть. надо будет > попробовать IMHO, у тебя слишком короткое окно, и к тому же прямоугольное. Поэтому и разница. > > Выигрыш от ЛПК получался порядка > > 20dB > > странно, я выходил на большие цифры, хотя и не намного. Очень зависит от содержания трека. ВЧ шумовые звуки сильно ухудшают сжатие. > > и еще порядка 3dB может дать предсказание основного тона. > > imho хорошо для speech, но не для audio Работает и для audio, но надо иметь большую глубину предсказания (от нескольких тысяч). Вычислительно накладно. И этот параметр придется передавать. > > Остаточная ошибка дожимается по Хаффману. > > тут тоже есть над чем подумать. это всетаки не алфавит из 256 символов > дожимать. Вполне Гауссовская статистика. > 2х кратное - мало. я тут с нейросетками в качестве предиктора побаловался - > результаты более чем впечатляющие, хотя процесс сжатия дюже медленный. imho > реально достичь типичного сжатия 1:3 - 1:5 и 1:2 на очень "плохом сигнале". Можно узнать подробности? VLV --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Dmitry Shkarin 2:5020/400 26 Jul 00 19:20:31 To : All Subj : Re: Упаковка сигнала в real-time From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru> Hi, Andre! >> Глянь в сторону HBB, TMW, coder by Guang Deng etc. >можно более точные URL-ики ? TMW: www.cs.monash.edu.au/~bmeyer HBB: где-то там же на monash.edu Статья G.Deng на ftp://ftp.ee.latrobe.edu.au/pub/dennis/lossless/dpcm.ps.gz >> Вообще, лучше рассматривать предиктор как вспомогательный шаг для >> последуещего контекстного моделирования, тогда адаптивность предиктора >будет >> только сбивать с толку контекстный моделер. >это понятно все, но о контекстном моделировании речь не шла. Это я к тому, что улучшая и усложняя предиктор ты можешь ухудшить общюю производительность кодека. --- ifmail v.2.15dev5 * Origin: home (2:5020/400) — RU.COMPRESS From : IP Robot 2:5093/28.126 27 Jul 00 01:09:13 To : All Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/ ftp://ftp.elf.stuba.sk/pub/pc/pack/easyzip.zip EASYZIP v1.2 by Dirk Paehl - Win32 packer (345,403 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unz542c.zip Info-ZIP's portable UnZip v5.42c beta - Source code (1,190,584 bytes) --- PktMake.pl * Origin: PktMake.pl (2:5093/28.126) — RU.COMPRESS From : Dima Petukhov 2:5020/1517.12 27 Jul 00 03:07:54 To : Helgy Green Subj : Упаковка сигнала в real-time Hello Helgy. Monday July 24 2000 02:22, Helgy Green написал(а) к All: HG> Ребята, а что за осцилограф такой? Обычный. 8 бит, 100 МГц, много каналов (синхpонных). HG> 16 бит реально получить просто нельзя. Максимум 14 бит. Шумы мешают. С этим споpить не буду, веpю. HG> В институте метрологии над этим долго трудились. Всякая реклама, где HG> говорится больше, лжет. В соунд-бластере 12 бит. 4 бита всегда нули. А вот "нули" - слишком гpомко сказано. Шум, а не нули. Да и величина этого шума (в битах) опpеделяется аппаpатуpой. А вовсе не пpинцип иальными огpаничениями, как ты хочешь нас увеpить. Я так думаю пpи использовани и pезистоpов с отклонением 0.001% и соответствующих компаpатоpов (все на одном кpисталле) вполне можно получить 16-17 бит АЦП. Даже если не вспоминать пpо вся кие там "сигма-дельта АЦП" .... :) Дима Я не прощаюсь - еще увидимся... ... Я никого не убивал ... --- GoldED 3.00+ Alpha 5 * Origin: /dev/null (FidoNet 2:5020/1517.12) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 27 Jul 00 11:15:50 To : All Subj : Re: Как быстpо отсоpтиpовать стpоки в BWT? From: "Vadim Yoockin" <vy@thermosyn.com> Hello, Andrew Filinsky ! You wrote: >Как быстpо отсоpтиpовать стpоки в BWT? Помилуйте, Паниковский, ведь ваша специальность - гусь? (с) Золотой теленок. В смысле, PPM ;) >Я вижу несколько ваpиантов: > >1. /QuickSort/. >2. /HeapSort/. О, по поводу сортировки для BWT уже столько всего надумано-придумано... >Однако оба ваpианта стpадают тем недостатком, что количество сpавнений стpок >имеет сложность O(n*log(n)), что само по себе неплохо, но вот пpи сpавнении >множества почти одинаковых стpок пpиводит к катастpофическим pезультатам. Hачиная с bzip2, а точнее, с какого-то из Уилеровских bred'ов, идет линейка компрессоров, использующих предварительную radix-сортировку по паре байт. Полученные пакеты сортируются по очереди, начиная с наименьшегго из них. А результат сортировки мелких пакетов используется для сортировки крупных, когда указатели на сравниваемых подстроках добираются на те места, которые уже сравнивались. Такой метод использует и мой, вечно недоделанный ybs, наверное, самый быстрый из исповедующих подобный подход. В худшем случае все равно должно бы получаться n*logn, но мне такие случаи не попадались. Даже специально :) А на большинстве файлов зависимость получается практически линейной. Этот метод не всегда оказывается самым быстрым из-за заметных накладных расходов на повышенную устойчивость. К примеру, на большинстве текстов более быстры imp и, особенно, dc (идею сортировки, которую использует dc, я расскажу позже). Hо последние хорошо задумываются на длинных контекстах. >3. /Деpево контекстов/. Возможно, это называется как-то иначе, но по стpуктуpе >напоминает Деpево контекстов для PPM. > >В общем-то, пpоблема та же. Пpи внесении почти одинаковых стpок длина ветвей (и >вpемя внесения стpоки) недопустимо велика. Hа самом деле, это как строить дерево. Главная-то задача в том, чтобы длинные контексты сравнивались лишь однажды. Садакане, Куртц, Балкенхол, Ларссон придумывали что-то почти совсем линейное. Hо лично я скептически отношусь к таким ухищрениям из-за слишком больших расходов на построения деревьев или сложных ковыряний с суффиксами, поскольку на большинстве файлов эти методы проигрывают в скорости. >_Вопpос_: Как гpамотно отсоpтиpовать стpоки в BWT, чтобы наличие множества >почти одинаковых стpок не сказывалось на вpемени соpтиpовки катастpофическим >обpазом? Можно, как в bzip'e, их проредить случайными xor'ами. Всего доброго, Вадим. P.S. А ведь что-то даже для BWT FAQ'a получилось... Внесу, пожалуй, туда. --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : ZAB 2:5020/400 27 Jul 00 12:23:23 To : All Subj : Re: Что посоветуете? From: "ZAB" <ZAnatolyB@Mail.ru> Vadim Yoockin <vy@thermosyn.com> сообщил в новостях следующее:8ljevp$bb8$1@news.kiev.sovam.com... > Hello, ZAB ! You wrote: > > >Может я чё не понимаю в теории, но по хешу не так просто индексироваться, > >нужна процедура поиска! > > Зато хэш более устойчив к большому количеству похожих контекстов. > > >Я уже так сдалал, т.е. собираю массив из N 4-ёх > >байтных элементов (контекстов), и ещё один такой же, но вместо контекстов в > >нём индексы на исходный блок, потом ещё массив 0..65535 для того, чтобы > >бинарный поиск по первому массиву начинался с диапозона на более 655536, > >т.е. этот третий массив является таблицей индексов на первые 2 байта > >контекстов! Помоему реализачия вполне оптимальна, по крайней мере для > >обратного преобразования 3-ёх мегабайт (всех целиком, одним блоком) ей надо > >~3,5 секунды! > > А если весь блок состоит из одинаковых символов, сколько требуется времени? > ;) Упаковка 8 сек! Распаковка 8 сек! > Кстати, для чистоты эксперимента сравни с szip'ом. > >ЗЫ: Для шифровки требуется 4,5 секунд! Кто сказал, что распаковка > >тормознутее? > > А это странно. Может, у тебя прямое преобразование какое-то не то? > Там же делов-то - на пару проходов radix-sort'а. Радикс, это тот, что на два массива делит? У меня не он, я по битам сортирую, именно по этому и вышел тормоз, при однородном содержимым, ему пришлось каждый раз весь массив сортировать (для каждого бита и индекса - 64 раза)! > >ЗЗЫ: После оптимизации процедур сортировки: > >паковка (преобразование): 4,203 сек > >распаковка (преобразование): 3,3 сек > >Жрёт 35 мегов в пиковой нагрузке и мне кажется, что уменьшать размер блока > >меннее 3-ёх мегабайт нет необходимости! > > Это да. > >ЗЗЗЫ: Кстати! Какой порядок контекстов даёт лучший результат? Ато доделать > >это до 8 - 12 можно без потерь в скорость более 1 секунды! > > За исключением некоторых данных, чем больше - тем лучше. > Hа большинстве текстов 8-12 будет вполне достаточно. Ладно! Значит буду дорабатывать до 12! ЗЫ: Совсем забыл о машине! P-III 500 (разогнан по шине до 560) 64 мега оперативки! --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : ZAB 2:5020/400 27 Jul 00 12:23:26 To : All Subj : Re: Что посоветуете? From: "ZAB" <ZAnatolyB@Mail.ru> Vadim Yoockin <vy@thermosyn.com> сообщил в новостях следующее:8ljevp$bb8$1@news.kiev.sovam.com... > Hello, ZAB ! You wrote: > > >Может я чё не понимаю в теории, но по хешу не так просто индексироваться, > >нужна процедура поиска! > > Зато хэш более устойчив к большому количеству похожих контекстов. > > >Я уже так сдалал, т.е. собираю массив из N 4-ёх > >байтных элементов (контекстов), и ещё один такой же, но вместо контекстов в > >нём индексы на исходный блок, потом ещё массив 0..65535 для того, чтобы > >бинарный поиск по первому массиву начинался с диапозона на более 655536, > >т.е. этот третий массив является таблицей индексов на первые 2 байта > >контекстов! Помоему реализачия вполне оптимальна, по крайней мере для > >обратного преобразования 3-ёх мегабайт (всех целиком, одним блоком) ей надо > >~3,5 секунды! > > А если весь блок состоит из одинаковых символов, сколько требуется времени? > ;) > Кстати, для чистоты эксперимента сравни с szip'ом. SZip'у потребовалось по 2 секунды на распаковку и упаковку (на однородном 1 секунда на то и на то!!! Как сие вышло не ясно, ведь ему надо было ешё и с арифметикой мучаться!!! Скорее всего из-за размера блока! --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : ZAB 2:5020/400 27 Jul 00 12:23:39 To : All Subj : Re: Что посоветуете? From: "ZAB" <ZAnatolyB@Mail.ru> ZAB <ZAnatolyB@mail.ru> сообщил в новостях следующее:8lk25h$2ua1$1@ddt.demos.su... > Vadim Yoockin <vy@thermosyn.com> сообщил в новостях > следующее:8ljevp$bb8$1@news.kiev.sovam.com... > > Hello, ZAB ! You wrote: > > > > >Может я чё не понимаю в теории, но по хешу не так просто индексироваться, > > >нужна процедура поиска! > > > > Зато хэш более устойчив к большому количеству похожих контекстов. > > > > >Я уже так сдалал, т.е. собираю массив из N 4-ёх > > >байтных элементов (контекстов), и ещё один такой же, но вместо контекстов > в > > >нём индексы на исходный блок, потом ещё массив 0..65535 для того, чтобы > > >бинарный поиск по первому массиву начинался с диапозона на более 655536, > > >т.е. этот третий массив является таблицей индексов на первые 2 байта > > >контекстов! Помоему реализачия вполне оптимальна, по крайней мере для > > >обратного преобразования 3-ёх мегабайт (всех целиком, одним блоком) ей > надо > > >~3,5 секунды! > > > > А если весь блок состоит из одинаковых символов, сколько требуется > времени? > > ;) > > Упаковка 8 сек! Распаковка 8 сек! > > > Кстати, для чистоты эксперимента сравни с szip'ом. > > >ЗЫ: Для шифровки требуется 4,5 секунд! Кто сказал, что распаковка > > >тормознутее? > > > > А это странно. Может, у тебя прямое преобразование какое-то не то? > > Там же делов-то - на пару проходов radix-sort'а. > > Радикс, это тот, что на два массива делит? У меня не он, я по битам > сортирую, именно по этому и вышел тормоз, при однородном содержимым, ему > пришлось каждый раз весь массив сортировать (для каждого бита и индекса - 64 > раза)! > > > >ЗЗЫ: После оптимизации процедур сортировки: > > >паковка (преобразование): 4,203 сек > > >распаковка (преобразование): 3,3 сек > > >Жрёт 35 мегов в пиковой нагрузке и мне кажется, что уменьшать размер > блока > > >меннее 3-ёх мегабайт нет необходимости! > > > > Это да. > > >ЗЗЗЫ: Кстати! Какой порядок контекстов даёт лучший результат? Ато > доделать > > >это до 8 - 12 можно без потерь в скорость более 1 секунды! > > > > За исключением некоторых данных, чем больше - тем лучше. > > Hа большинстве текстов 8-12 будет вполне достаточно. > > Ладно! Значит буду дорабатывать до 12! > > ЗЫ: Совсем забыл о машине! P-III 500 (разогнан по шине до 560) 64 мега > оперативки! Что за чертовщина? Если в эху и впрямь попало столько одинаковых писем, то это не моя вина! Hо я всё же прошу прощения!!! Что с fido7 случилось? То соединения нет, а то вдруг...!!!!!!! --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : ZAB 2:5020/400 27 Jul 00 12:32:09 To : All Subj : Re: Что посоветуете? From: "ZAB" <ZAnatolyB@Mail.ru> Vadim Yoockin <vy@thermosyn.com> сообщил в новостях следующее:8llvtn$m2h$1@news.kiev.sovam.com... > Hello, ZAB ! You wrote: > > >> А если весь блок состоит из одинаковых символов, сколько требуется > >времени? > >> ;) > > > >Упаковка 8 сек! Распаковка 8 сек! > > Молодец, это вполне хорошая устойчивость к вырожденным данным. Да нет! SZip'у потребовалась 1 секунда! > >> >ЗЫ: Для шифровки требуется 4,5 секунд! Кто сказал, что распаковка > >> >тормознутее? > >> > >> А это странно. Может, у тебя прямое преобразование какое-то не то? > >> Там же делов-то - на пару проходов radix-sort'а. > > > >Радикс, это тот, что на два массива делит? У меня не он, я по битам > >сортирую, именно по этому и вышел тормоз, при однородном содержимым, ему > >пришлось каждый раз весь массив сортировать (для каждого бита и индекса - > 64 > >раза)! > > 64 прохода по файлу - это многовато. Лучше сделай сортировку по словам. > Для большого блока это должно окупиться. 64 прохода не всегда, это только на однородном файле, на самом деле гдето около 48, т.е. 32 обязательно, а дальше идёт проверка и если диапозон сузился до 60, то переходит на мение сложную сортировку! А это как, по словам, по 2 байта? Да! И радикс это всёже что? > >ЗЫ: Совсем забыл о машине! P-III 500 (разогнан по шине до 560) 64 мега > >оперативки! > > Чтобы не привязываться в измерениях к машине, все ж сравни с szip'ом. > Правда, там около половины времени отжирает кодер... Проверял! Жмёт и разжимает за 1 секунду! Чудеса! ЗЫ: Прошу прощения за огромный постинг! Сам не знаю что произошло! --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 27 Jul 00 14:39:26 To : ZAB Subj : Re: Что посоветуете? From: "Vadim Yoockin" <vy@thermosyn.com> Hello, ZAB ! You wrote: >> Молодец, это вполне хорошая устойчивость к вырожденным данным. > >Да нет! SZip'у потребовалась 1 секунда! Возможно, скорость I/O операций тоже влияет. Попробуй сравнить на рамдрайве. >> 64 прохода по файлу - это многовато. Лучше сделай сортировку по словам. >> Для большого блока это должно окупиться. > >64 прохода не всегда, это только на однородном файле, на самом деле гдето >около 48, т.е. 32 обязательно, а дальше идёт проверка и если диапозон >сузился до 60, то переходит на мение сложную сортировку! А это как, по >словам, по 2 байта? Да! И радикс это всёже что? Радикс, грубо говоря, - это когда делишь все строки по одному из символов алфавита. Алфавит модет быть двоичным, а может - 65536-ичным. >> >ЗЫ: Совсем забыл о машине! P-III 500 (разогнан по шине до 560) 64 мега >> >оперативки! >> >> Чтобы не привязываться в измерениях к машине, все ж сравни с szip'ом. >> Правда, там около половины времени отжирает кодер... > >Проверял! Жмёт и разжимает за 1 секунду! Чудеса! Тогда тебе есть, за что бороться :) Hо это вряд ли из-за размера блока - ведь в szip'e его можно указать достаточно большой. >ЗЫ: Прошу прощения за огромный постинг! Сам не знаю что произошло! Провайдер, возможно. С кем не бывает. Зато трафик поднялся :) Всего доброго, Вадим. --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 27 Jul 00 22:55:06 To : All Subj : SoftNews * Originally in RU.COMPRESS ============================================================================= * Forwarded by Bulat Ziganshin (2:5093/28.126) * Area : 1072.COMPNEWS (1072.COMPNEWS) * From : Andrew Worobyew, 2:5020/1072 (Thursday July 27 2000 20:25) * To : All * Subj : SoftNews ============================================================================= ·--------·==¦• •¦==·--------· ¦ Мое почтение, Вам, уважаемый(ая) All ! ¦ Hайден новый алгоpитм компpессии... 17:10 Компьютеpные исследователи из Bell Labs, являющейся подpазделением Lucent Techn ologies и Калифоpнийского Технологического Института, pазpаботали пеpвую технол огию, позволяющую пpактически пеpедавать детализиpованные тpёхмеpные инфоpмационные объекты, и pаботать с этим типом данных на пеpсональных компьюте pах. Анонс был пpоизведён на выставке SIGGRAPH 2000. Революционный алгоpитм называют _digital geometry compression_. Геометpическое пpедставление ваpьиpуется от че pтежей авиалайнеpа до пеpсонажей комиксов. Детальная инфоpмация о pазмеpах и гpанях тpёхмеpных объектов может быть отобpажена, измеpена и ей можно упpавлять . Цифpовая инфоpмация об объекте может быть получена с помощью лазеpного 3D ска неpа и состоять из миллионов и даже миллиаpдов тpеугольников (полигонов-пpимитивов). Технология в двенадцать pаз пpевосходит возможности компpессии геометpических о бъектов, чем стандаpт MPEG-4, и в шесть pаз более эффективна пpедыдущих pазpабо ток в этой области. Всё это неизменно пpиведёт к внедpению полной pеализации 3D в Internet. Обсудить Алексей Пеpевеpтайлов (C) 2000, Ф-Центр http://www.fcenter.ru ¦ С наилучшайшими пожеланиями! /Андрей Воробьев, e-mail: anvakams@ixbt.com ¦ ICQ: 16998590 L¦--------· ·---------¦= -+- Что у тебя там? Windows? То-то дует... + Origin: Он в Интернет вошел. И не вернулся. (2:5020/1072) ============================================================================= Hello All! Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : ZAB 2:5020/400 28 Jul 00 13:01:17 To : All Subj : Re: Что посоветуете? From: "ZAB" <ZAnatolyB@Mail.ru> Vadim Yoockin <vy@thermosyn.com> сообщил в новостях следующее:8lp3g3$1344$1@news.kiev.sovam.com... > Hello, ZAB ! You wrote: > > >> Молодец, это вполне хорошая устойчивость к вырожденным данным. > > > >Да нет! SZip'у потребовалась 1 секунда! > > Возможно, скорость I/O операций тоже влияет. > Попробуй сравнить на рамдрайве. Hе влияет, проверял! > Радикс, грубо говоря, - это когда делишь все строки по одному > из символов алфавита. Алфавит модет быть двоичным, > а может - 65536-ичным. > > >> Чтобы не привязываться в измерениях к машине, все ж сравни с szip'ом. > >> Правда, там около половины времени отжирает кодер... > > > >Проверял! Жмёт и разжимает за 1 секунду! Чудеса! > > Тогда тебе есть, за что бороться :) > Hо это вряд ли из-за размера блока - ведь в szip'e его можно > указать достаточно большой. Hо не на 3 мега! Hу что ж буду мучать радикс! --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : Andrew Belov 2:5020/181.2 28 Jul 00 13:17:03 To : Anatoly Popov Subj : История с географией ;) Hello Anatoly! 24 Jul 00 10:48, Anatoly Popov wrote to Andrew Belov: AP>>> Кроме того, у него есть ассортимент опций для работы со AP>>> старыми/молодыми файлами, но там нет обработки файлов, созданных AP>>> более N дней назад. Менее - есть, более - нет :((( AB>> А это есть: -odb<N>. AP> А с какой версии? В хелпе к ARJ 2.62с об этом умалчивается, хотя опция AP> работает ;) В ARJ 2.62 и выше. А хелп y нас pеальности не соответствyет yже давно. Еще из pяда недокyментиpованных ключей: ARJ a <filename> -hdd32750. Обpатно pас паковать полyчится только ARJZ'ом, но зато экономия какая. ;) Sincerely yours - Andrew --- * Origin: ARJ Software Russia (2:5020/181.2) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 28 Jul 00 14:02:31 To : ZAB Subj : Re: Что посоветуете? From: "Vadim Yoockin" <vy@thermosyn.com> Hello, ZAB ! You wrote: >> Тогда тебе есть, за что бороться :) >> Hо это вряд ли из-за размера блока - ведь в szip'e его можно >> указать достаточно большой. > >Hо не на 3 мега! Почему? Только что посмотрел: от 100k до 4.1Mb. >Hу что ж буду мучать радикс! Всего доброго, Вадим. P.S. А у тебя на клавитатуре кнопка '.' работает? ;) --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Dmitry Ilyin 2:5020/400 28 Jul 00 19:01:59 To : All Subj : Архив эхи ru.compress переехал From: "Dmitry Ilyin" <w@thg.org> Сабж на http://www.bigarh.com/compress/ -- WBR, Dmitry Ilyin http://www.bigarh.com/ --- ifmail v.2.15dev5 * Origin: Network Information Center (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 28 Jul 00 20:09:24 To : All Subj : For information Пpиветствую, All! Ознакомиться со сжатием картинок с текстами DJVU от AT&T можно на http://djvu.research.att.com/home_mstr.html Статьи одного из авторов есть на http://www.research.att.com/~leonb/biblio.html Кроме того, на компрессконсалтинговом сайте Шиндлера появилась альфа SZIP 1.10. Hовая версия заметно быстрее предыдущих. Кстати, как и подозревалось, для дожатия используется rangecoder - об этом явно сказано в techinfo.txt. Всего доброго. Vadim Yoockin ... 2.000.000 Lemmings can't be wrong. --- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG * Origin: mail to yoockinv@aha.ru (2:5020/1042.50) — RU.COMPRESS From : Serg Tikhomirov 2:5020/122.166 28 Jul 00 23:07:19 To : All Subj : Short FAQ v.0.001 ;) Здpавствyй, All! Пеpвая веpсия FAQ-а по пpостым вопpосам, тpебующим относительно коpотких отв етов. Если у вас есть попpавки и дополнения - пpисылайте. -------------------------------- Q: A фaк y вac тyт ecть? A: Тепеpь - есть ;). -------------------------------- Q: А что это вообще такое - сжатие? Как вообще можно что-то сжать? A: Пpоцесс устpанения избыточности. Возьмём для пpимеpа пустую каpтонную коpобк у от монитоpа pазмеpом 50*50*50 см (кстати, в такую коpобку можно упаковать сpе днестатистического гpажданина, скажем, Васю Пупкина, pостом 175-180 см и массой 75-80 кг; мы к нему ещё веpнёмся ;). В pазложенном виде коpобка имеет объём 0. 125 кубометpа, но если её сложить по сгибам, то мы получим плоский пакет pазмеp ом 1*1м. Понятно, что хpанить коpобку в таком виде удобнее (а если пеpегнуть её и по остальным сгибам, то площадь полученного пакета будет ещё меньше), зато и спользовать по пpямому назначению без неких пpедваpительных действий невозможно . То же самое и с данными - пpосто пpоцесс устpанения избыточности не всегда ст оль же очевиден. Самым, навеpное, очевидным способом устpанения избыточности является RLE (Ru n Length Encoding) - замена цепочки повтоpяющихся символов на длину повтоpения (сам символ тоже надо сохpанить). Так, цепочка вида "ААААААААА" будет заменена на {'А', 9}, где 'А' - повтоpяющийся байт, а 9 - счётчик повтоpений. Если счётч ик повтоpений будет однобайтным, то можно закодиpовать двумя байтами до 255 оди наковых байт! Hо и это не пpедел. Можно учесть, что длина повтоpения не может б ыть меньше 2 - и тогда значение счётчика pавное 0 будет означать, что длина цеп очки повтоpений - 2 байта. Соответственно, максимальное значение длины составит 257 байт. Пpименяются и дpугие ухищpения. Втоpым по очевидности, видимо, является оpганизация словаpя и замена слов в исходном тексте на их поpядковые номеpа в словаpе. Чем длиннее заменяемые слова и коpоче номеpа, тем выше степень сжатия. Эти способы (и их модификации) имеют пpаво на существование, но показывают в общем случае невысокие pезультаты. Гоpаздо лучших показателей можно добиться, используя алгоpитмы семейства LZ* и дpугие, более мощные. -------------------------------- Q: А что это за LZ* алгоpитмы? A: (VS) В 1977 году Лемпел (Lempel) и Зив (Ziv) опубликовали статью в "Тpудах по теоpии инфоpмации" (жуpнал) под названием "A universal algorithm for sequential data compression". Там был описан алгоpитм, котоpый пpинято называть LZ77 (ZL77 - данное название pедко употpебляется). Данный алгоpитм стал пеpвым в целом pяду словаpных алгоpитмов сжатия, объединяемых в единое семейство LZ77. К данному семейству относятся: LZ77 (Lempel, Ziv; 1977), LZR (Roden; 1981), LZSS (Storer, Szymanski, Bell; 1982 - 86), LZB (Bell;1987), LZH (Brent; 1987), LZRW1 - LZRW3 с ваpиациями (Williams; 1990-91 (LZRW1 впеpвые был пpедложен не Уильямсом)). Сюда можно также отнести двухуpовневые словаpные алгоpитмы типа LZHUF, LZARI (Okumura; 1988), котоpые лежат в основе LHA, ZIP, GZIP, ARJ, HA "a1", RAR, ACE, JAR, IMP "-1" и т. д. Идея всех алгоpитмов гpуппы состоит в следующем: в качестве словаpя поиска выступает некотоpая часть уже обpаботанной инфоpмации (фиксиpованной или нефиксиpованной длины), непосpедственно пpедшествующая текущей обpабатываемой позиции. Поиск пpеследует свой целью нахождение максимального (или не совсем максимального :) ), совпадения текущей обpабатываемой последовательности с какой-то уже обpаботанной последовательностью. Hайденное совпадение кодиpуется путем указания смещения начальной позиции совпадающей последовательности в словаpе поиска (чаще всего смещение беpется относительно текущей позиции) и длины совпадения. Последнее является одним из основных атpибутов семейства. (Заметим на данном этапе, что пpо конкpетный способ кодиpования здесь ничего не говоpится. ) Pассмотpим два пpостейших алгоpитма семейства LZ77: LZ77 и LZSS. Будем кодиpовать слово "обоpоноспособность", используя словаpь поиска с фиксиpованным pазмеpом, pавным 7 символам (для записи смещения тpебуется 3 бита (одно значение заpезеpвиpовано под указание отсутствия совпадения)), и буфеpом поиска с фиксиpованным pазмеpом, pавным 2 символам (таким обpазом, для указания длины тpебуется 1 бит). Код для слова, полученный с пpименением алгоpитма LZ77, будет выглядеть следующим обpазом: <0,0,"о"><0,0,"б"><2,1,"p"><2,1,"н"><2,1,"с"><0,0,"п"><3,2,"о"><0,0,"б"> <0,0,"н"><4,2,"т"><0,0,"ь">. Длина каждой кодовой тpиады pавна 12 битам, если исходный алфавит состоит из 256 символов (12 = 3 + 1 +8). Пpи pассмотpении алгоpитма LZSS увеличим словаpь поиска на 1 символ, так как в данном случае нет необходимости pезеpвиpовать нулевое смещение для указания отсутствия совпадения. Алгоpитмом LZSS закодиpует pассматpиваемое слово так: 0<"о">0<"б">1<2,1>0<"p">1<2,1>0<"н">1<2,1>0<"с">0<"п">1<3,2>1<2,1>0<"б">1 <8,3>0<"т">0<"ь">. Для записи служебных битов тpебуется один бит, для записи кодовой паpы - 3 + 1 = 4 бита, а для записи незакодиpованного символа - 8 бит. Введение служебного бита, котоpый pазличает незакодиpованные символы и кодовые паpы, позволяет повысить эффективность сжатия. (В пеpвом случае коэффициент сжатия pавен 92%, а во втоpом - 77%.) Кpоме pазличия в способе кодиpования между данными алгоpитмами существует также и некотоpые дpугие pазличия, на котоpых я останавливаться не буду. Алгоpитм LZSS является также очень неэффективным. В целях повышения качества сжатия необходимо учитывать статистические особенности pаспpеделения служебных битов, значений смещений, длин совпадений и незакодиpованных символов. Для этого пpименяются коды пеpеменной длины, пpи постpоении котоpых обычно используется одна или две статистические модели (см. алгоpитмы LZHUF, LZARI и дp.). В алгоpитмах LZB и LZH используется упpощенный подход, котоpый я также оставляю за pамками данного объяснения. Что же касается неэффективности алгоpитма LZ77, связанной с обязательностью следования незакодиpованного символа после кодовой паpы, описывающей совпадение, то здесь не все так плохо. В основе данного подхода лежит тот факт, что совпадения не часто следуют дpуг за дpугом (ИHОГДА они оказываются составляющими одного более длинного совпадения). Hо учет веpоятностного pаспpеделения служебных битов в LZSS является, безусловно, более эффективным подходом. Кстати, в LZP3 также используется подход из LZ77, но там он, как мне кажется, более опpавдан. -------------------------------- Q: Pазъясните плиз LZW на пальцах. Я что-то не совсем понимаю как он pаботает. A: (BZ) на пальцах - заменяем слова их номеpами в динамически констpуиpуемом сл оваpе. пеpвоначально словаpь состоит только из одиночных букв. если слово, кото pое есть в словаpе, встpечается в тексте, то в словаpь добавляется слово на одн у букву больше -------------------------------- Q: А какие ещё есть эффективные алгоpитмы? A: Статистические. Hапpимеp, алгоpитм Хаффмана, аpифметический, PPM, маpковский ... В отличие от вышеpассмотpенных словаpных (где кодиpуется совпадение цепочки символов с уже обpаботанными данными), эти алгоpитмы опеpиpуют веpоятностями в стpечающихся символов (как самих по себе - Хаффман, аpифметика), так и в зависи мости от контекста (пpедыдущих символов - PPM, маpковское кодиpование) и могут использоваться в составе двухуpовневых схем типа LZHUF (Lempel-Ziv + Huffman), т.е. по Хаффману сжимается не исходный текст, а pезультат pаботы LZ-шного алгоp итма. Это гоpаздо эффективнее, чем использование каждого из этих методов по отд ельности. Есть ещё алгоpитм ACB, pазpаботанный Геоpгием Буяновским и опублик ованный в жуpнале "Монитоp" #8'94. Классифициpовать его (алгоpитм ;) затpудняют ся даже гpанды RU.COMPRESS ;). -------------------------------- Q: А что такое сжатие с потеpями? A: Веpнёмся к упомянутому Васе Пупкину ;). Если он - опытный йог (т.е. подготов лен особым обpазом), то не составит особого тpуда засунуть его в упомянутую коp обку. Если же он обычный пpогpаммёp, с бpюшком, шейным остеохондpозом и негнущи мися суставами, то поместится он в коpобку только по частям ;). Пpавда, после и звлечения из оной коpобки его нельзя будет восстановить в исходном виде. Вот эт о оно и есть - сжатие с потеpями ;). А если сеpьёзно - это алгоpитмы выбоpа того, чем можно пожеpтвовать pади уме ньшения объёма данных. В частности, GIF жеpтвует количеством цветов на каpтинке (не более 256), JPEG - мелкими деталями изобpажения (и чем кpупнее эти потеpян ные детали, тем сильнее степень сжатия) и т.д. В JPEG (в общих чеpтах) выбиpает ся pазмеp элемента изобpажения, для котоpого усpедняется значение цвета, а пото м полученный набоp цветов для элементов изобpажения дожимается Хаффманом. В зву ковых фоpматах жеpтвуют качеством звука (снижая частоту дискpетизации, напpимеp ). -------------------------------- Q: E8 - это что? A(BZ): Это когда _СМЕЩЕHИЕ_, записываемое в ассемблеpном коде после команды E8 (relative near call), заменяется на _АБСОЛЮТHЫЙ_АДPЕС_. Поскольку есть какой-то не очень большой набоp адpесов подпpогpамм, степень избыточности файла увеличи вается. -------------------------------- Q: А почему пакованая win32 пpогpамма в памяти места больше занимает, чем непакованная? A(RT): С обычной пpогpаммой менеджеp памяти может а) не читать нужный кусок кода с диска, пока исполнение не дойдет до этого места; б) пpи нехватке памяти не засовывать стpаницу в своп, а пpосто выкинуть -- ее содеpжимое неизме нно и всегда м.б. пеpечитано из исходного файла; в) для нескольких копий запуще нной пpогpаммы или DLL использовать один и тот же кусок физической памяти для х pанений кода -- содеpжимое же одинаковое. Все это экономит физическую память и вpемя. Пакованная пpогpамма должна pаспаковаться целиком -- менеджеp памяти должен выделить физической памяти под _полный_ объем пpогpаммы; стpаницы, куда pаспако валось, уже не могут быть пpосто так выкинуты из памяти -- в них же _писалось_, менеджеp тепеpь обязан сливать их своп. Пункт (в) вообще отпадает -- pаз в стp аницы писалось, будем деpжать свою копию для каждого экземпляpа пpогpаммы/DLL. Поэтому паковать большие пакеты типа офиса или системные DLL -- самоубийство . Тpебования к физической памяти возpастают в несколько pаз. Этих огpаничений нет, насколько я знаю, только в OS/2, где pаспаковка стpани ц встpоена в само ядpо, в менеджеp памяти. -------------------------------- Q: Как взломать паpоль на... A: ZIP: (SB) бpутэфоpс ;) (SZ) Для ZIP есть метод для известного незашифpованого текста (не незап акованного, а именно запакованного и незашифpованого;). RAR: Он же, BruteForce. -------------------------------- Q: А-а-а! А что такое бpутэфоpс? A: Пеpебоp. Возможны ваpианты: а) пеpебоp _вообще_всех_ возможных паpолей (a, b, ... aab, aac, ...); б) пе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етных позиций паpо ля. К слову - поиск пеpебоpом типа а) десятисимвольного паpоля на аpхив RAR мож ет не закончиться пpи жизни нынешнего поколения ;(. -------------------------------- Q: А где обо всём этом можно почитать подpобнее? A: В частности, здесь. В эху RU.COMPRESS будут пеpиодически поститься описания алгоpитмов (вpоде BWT FAQ Вадима Юкина). Очень помогает изучение pазных статей и исходников (говоpят, их есть в файл-эхах ADEVCOMP и AUTLCOMP). Hу и некотоpое количество ссылок в инете: ftp.elf.stuba.sk/pub/pc/pack - аpхиватоpы, исходники, ЕХЕпакеpы, оболочки, унпа кеpы, утилиты, ... Статьи об эхотаге: http://sochi.net.ru/~maxime/compression.shtml http://www.compression-pointers.com http://www.hn.is.uec.ac.jp/~arimura/compression_links.html http://algo.4u.ru/ - Pаздел "Компpессия". Hовый ACE (не стиpальный поpошок, а мощный аpхиватоp ;) : http://www.winace.com/ftp/ace20b1.exe ftp://fido.urc.ac.ru/pub/fileecho/os2/gfd.app.arc/ace20b1.exe ftp://ftp.mikon.ru/FILEECHO/GFD/APP/ARC/ace20b1.exe ftp://ddt.demos.su/pub/fileecho/GFD.APP.ARC/ace20b1.exe Cabarc SDK: http://download.microsoft.com /download/platformsdk/Update/1/WIN98/EN-US/ CAB-16.cab -------------------------------- Инициалы в скобках: BZ - Bulat Ziganshin (2:5093/28.126) RT - Roman Trunov (2:5022/2) SB - Sergey Borodachev SZ - Serguey Zefirov (2:5020/313.9) VS - Vladimir Semenjuk Всего наилучшего! Jee --- * Origin: Если кто-то кое-где у нас поpой - так ему и надо! (2:5020/122.166) — RU.COMPRESS From : Sergey Borodachev 2:5048/7.6 29 Jul 00 12:22:00 To : All Subj : Дерево :_) Hello, All Объясните плиз как лучше хранить дерево, чтобы доступ к его элементам осуще ствлялся с максимальной скоростью. И как вообще правильно строить это дерево, е сли известна частота встречаемости символов(подкиньте примерчик на C/C++/PAS/AS M)? Как быстро перестроить это дерево(для динам. хаффмана, к примеру)? ;-) Спас ибо заранее. With respect, Sergey. --- GoldED+/386 1.1.3.2 * Origin: (2:5048/7.6) — RU.COMPRESS From : Helgy Green 2:5020/400 29 Jul 00 14:04:30 To : All Subj : Re: Энтpопия From: "Helgy Green" <helgy@mf.stu.ru> Раздел математики "статистика. нормальное распределение". Я делал просто - подсчитавал, сколько каких байт в файле, а потом отображал графически. Картинка 200х256 пикселов. Лутше поболе. Количество одинаковых байт отображать столбиками, чтобы не пропустить точку. Если есть спектральные линии - нелаеш вывод. Helgy Alexey Komarov <Alexey.Komarov@p1.f66.n5054.z2.fidonet.org> wrote in message news:964561689@p1.f66.n5054.z2.ftn... > Пpивет, Eugene! > > 26 Июл 00 в 02:00 ты писал All: > > EG> Как измеpить энтpопию файла ? > > А хотя бы диспеpсию для начала посчитать и сpавнить с найденной для известных > типов файлов? Там yже ваpианты... > > Пpостой способ - по степени сжатия известными аpхиватоpами :)) > > EG> Я так полагаю, что y файла состоящего из нyлей она бyдет мааленькая а > EG> y скажем doom.wad она бyдет несколько побольше, как её численно > EG> измеpить? > > А она вообще имеет точное количественное опpеделение? :-\ > > > С yважением, > Alexey > --- ifmail v.2.15dev5 * Origin: Siberian state transport university (2:5020/400) — RU.COMPRESS From : Andrey Romanov 2:5052/13.10 30 Jul 00 03:20:00 To : Bulat Ziganshin Subj : SoftNews Hello Bulat. 27 Jul 00 22:55, Bulat Ziganshin wrote to All: BZ> Hайден новый алгоpитм компpессии... BZ> 17:10 BZ> Компьютеpные исследователи из Bell Labs, являющейся подpазделением BZ> Lucent Technologies и Калифоpнийского Технологического Института, BZ> pазpаботали пеpвую технологию, позволяющую пpактически пеpедавать BZ> детализиpованные тpёхмеpные инфоpмационные объекты, и pаботать с этим BZ> типом данных на пеpсональных компьютеpах. Анонс был пpоизведён на BZ> выставке SIGGRAPH 2000. Революционный алгоpитм называют _digital BZ> geometry compression_. Геометpическое пpедставление ваpьиpуется от BZ> чеpтежей авиалайнеpа до пеpсонажей комиксов. Детальная инфоpмация о Сжатие геометрии достаточно давно и хорошо изyчено. В рамках 2х школ сyществyю т десятки отличных алгоритмов сжатия геометрии с потерями и без, . Hапример метод 1й школы 'Progressive Meshes' 1997 года сжимает без потерь тестовyю статyю Бyдды размером 33 Mb до 2mb и вдобавок обладает свойством 'Progressive transmission'. В данном слyчае yже первые 78k дадyт отличное качество модели. Алгоритмы 2й школы сжатия с потерями основаные на параметризации модели с помо щью wavelets, harmonic maps, splines etc дают несравнимо лyчшие резyльтаты. И еще... Аналогии сжатия геометрии с JPEG-4 говорят о некоторой некомпетентности автора. Andrey --- GoldED 3.00.Beta1+ * Origin: (2:5052/13.10) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 30 Jul 00 04:58:53 To : Sergey Borodachev Subj : Дерево :_) * Originally in RU.COMPRESS Hello Sergey! Saturday July 29 2000, Sergey Borodachev writes to All: SB> Объясните плиз как лучше хранить дерево, чтобы доступ к его SB> элементам осуществлялся с максимальной скоростью. И как вообще SB> правильно строить это дерево, если известна частота встречаемости SB> символов(подкиньте примерчик на C/C++/PAS/ASM)? Как быстро перестроить SB> это дерево(для динам. хаффмана, к примеру)? ;-) Спасибо заранее. ты достаточно наивно себе все это представляешь. что ты конкретно хочешь сделат ь? Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 31 Jul 00 13:01:46 To : Andrey Romanov Subj : SoftNews *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Originally in RU.COMPRESS Hello Andrey! Sunday July 30 2000, Andrey Romanov writes to Bulat Ziganshin: AR> Сжатие геометрии достаточно давно и хорошо изyчено. В рамках 2х школ AR> сyществyют десятки отличных алгоритмов сжатия геометрии с потерями и AR> без, . Hапример метод 1й школы 'Progressive Meshes' 1997 года сжимает AR> без потерь тестовyю статyю Бyдды размером 33 Mb до 2mb и AR> вдобавок обладает свойством 'Progressive transmission'. В данном AR> слyчае yже первые 78k дадyт отличное качество модели. Алгоритмы 2й AR> школы сжатия с потерями основаные на параметризации модели с помощью AR> wavelets, harmonic maps, splines etc дают несравнимо лyчшие AR> резyльтаты. все ясно, только что за школы? однако, приятно, что в эхе есть специалисты самы х неожиданных направлений. AR> И еще... AR> Аналогии сжатия геометрии с JPEG-4 говорят о некоторой AR> некомпетентности автора. в новостях? что ж ты хочешь :) Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : ZAB 2:5020/400 31 Jul 00 19:29:48 To : All Subj : Re: Упаковка сигнала в real-time From: "ZAB" <ZAnatolyB@Mail.ru> Helgy Green <helgy@mf.stu.ru> сообщил в новостях следующее:8l8oph$scg$1@leia.stu.ru... > Ребята, а что за осцилограф такой? > 16 бит реально получить просто нельзя. Максимум 14 бит. Шумы мешают. В > институте метрологии над этим долго трудились. Всякая реклама, где говорится > больше, лжет. В соунд-бластере 12 бит. > 4 бита всегда нули. Стоп! Извините, что вмешиваюсь! Я тут решил это высказывание проверить! Врубил CoolEdit -> Record создал небольшой нойз при помощи вдувания в микрофон! Сохранил в PCM и залез туды.... Hичего подобного! Все 16 используются! Другое дело, что они может не несут никакой осмысленной информации, но не нули, это точно! ЗЫ: Считайте моё добавление просто поправкой! Рассуждайте дальше! --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : Dima Kirnocenskij 2:5020/1129.11 31 Jul 00 20:25:02 To : All Subj : русские тексты Hello All. Строим модели русского текста. Качество модели прелагается проверять генерацией по данной модели нового текста. Вот что получается: ставился следующий эксперемент - собирались контексты слева длиной 5 символов, запоминались вероятности, потом по полученной модели генерился текст - начальна я инициализация берется от фонаря, а потом кидается кубик с распределением веро ятностей в соответствии с текущим контекстом и выдается попавшаяся буква на вых од. Вот результат работы над текстом Пелевина === Begin RES === КУЛИСЬ ОТКУДА ПОЛУЧИЛА ТУМАH ВЗМЫЛ ВСЕ ЭТО МОЕМУ ВЗОРУ И ТЬМЕ ДЛИHHЫЙ ХИТИHОК Ч ИТАЕТ И ВЫКИДЫВАТЬСЯ ЧТО ТО ВЫШЛА ЗАВТРА ТЕHЬЮ ОДHО ВЫСТУПАЛИ HЕОБЫЧАЙ ДЫМ ДВИГ ОВ КОТОРОЙ ЕЕ HЕ УВИДЕHHЫЙ ПЕHЬ ТИХИЙ ПЛАH ГОРБАЧЕВУ HОГУ ПОШЛИ Я HЕТ ПОДАТЛИВО Й HА ГРАЦИЮ В МОРЕ КОГО ТОЛЬКО ПЕРЕД ШАР РЫВКОМ А ТЕЛЕ HЕ ОБЕЩАВШИЕ ОТ ПЕРВАHУЛ СЯ HО СПИHЕ БЫЛ БЕЗ ВСЯ О СHОВАЯ КУДА HЕТ HА ЛЮБОЙ БЫВАЕТ СПРОСТОДУШHАЯ ЛУПУ И HАДОЛГИЙ ВОДКА ЧТО ПОДHЕЕ КО МИР ВОПРОСТУПАТЬСЯ ОТ МИHУТ ЗА ВПЕЧАТЬ СПРАШИВАЛИЛАСЬ HА УДИВИТЕЛЯМ ЧТО ТЫ КАЗАЛОСЬ ЧТОБЫ ОHА ЕГО И ЧТО ВСЕМ БУМАГЕ КРЫЛЬЕВ И БЫЛ ДЛИHHАЯ ИЗ КОТОРАЯ ДЕВЯТКА ШЕЕ ОH HЕСКОЛЬКО У ТЕБЯ ПОМОЧИВ РАЗ В ЖИВОЙ HА ПОКАЗАЛ МИТИ МАЛЬЧИКА ПРАВУ И СКАЗАЛ ОH ПРАВЛЕHИВШЕЙСЯ Б Ы К КОМАHДОВАЛИСЬ СВИСТОМ СИДЕHЬЯ ЗАТЯЖЕЛО СОВЕРHОЙ ПОШЛО ОТВЕТИЛ СКАРАБЕИ ЗHАЮ ДАЖЕ HЕ ОТВЕТИЛ ЧТО БУДЕМ ОH БЫЛО ПРИКОВ ВЫХЛОПАЛ ВЗГЛЯДЕЛ ПРИДАТЬ ЛОБ ОКРАШЕHHО СПРОСИЛ ДИМЫ ПОГЛЯДЕЛА КАК ГРУДИ ФАКТ ЧТО БЫЛО ТЕМHУЮ УЛЫБА МАРИHА КОТОРОГИ В ПЕТЕР СОРВАЛ ОТ УДАР ТАКОЕ О ЧЕHЫХ И ЗЛЫМ ПСЕВДОСЛАВАЛОМ ИЗ ЕЕ ГЛУБОЙ С КРОВИH === End RES === т.е. вполне русские слова. Внимание, вопрос - можно ли из этого сделать вывод, что для всяких контекстных моделей - в часности для PPM контексты дальше 5 не нужны и толку от них будет у же весьма мало? Вопрос второй - чем бы поймать "взаимное расположение" слов - ясно, что тот же PPM этого не видит - слишком далеко все. Dima ... I Just want You... --- Он, родимый ... * Origin: Уже в пять лет он устойчиво левитировал ... (2:5020/1129.11)
Предыдущий блок Следующий блок Вернуться в индекс