[an error occurred while processing this directive] [an error occurred while processing this directive]

Re: PPMonstr I

Сайт о сжатии >> Форум #Компрессор# >> [Ответить] [Ответы]

Автор: Serge Osnach, <ench@intelserv.kiev.ua>
Киев, Украина, 27 мая 2002 года в 10:21:23

В ответ на : Re: PPMonstr I от Maxim Smirnov в 26 мая 2002 года в 20:25:04:

> > Попробую выразить проще -- во многих
> случаях в маскированных контекстах
> вероятность Recent-символа полезно
> уменьшать, а не увеличивать.

> А, терминологические затруднения.
> Маскированный -- это текущий с
> замаскированными символами?
> Тогда понятно. Что ж тут
> удивительного?
> Правда, для некоторых файлов выгодно
> даже в этом случае использовать RS.
> Например, obj2.
Видимо, использовать адаптивное RS.
Тогда коэффициент в RS может принимать значения > > [SEE]
> > > Нет, я с этим особо не
> > > экспериментировал. Насколько помню,
> > > результаты замеров возможных
> улучшений меня не особо увлекли своей
> > > значимостью.
> > Может, дело просто в неудачной
> реализации?

> Это запросто.

> > Я реализовал балансировку отдельно
> для каждого порядка контекста, и
> результатом доволен. И потом,
> балансировщик позволяет более вольно
> обходиться с оценкой вероятности
> символов...

> Каковы реальные изменения сжатия
> и скорости работы "оценивателя"
> (без учета поиска контекстной
> информации) ?
Статистика, увы, не сохранилась. Что-то порядка 0.1% - 0.2%.
Оцениватель, чую, прийдется переделывать. Сейчас происходит следующее: берем контекст, по нему SEE-предсказатель, схожий с Шкаринским, строит SeeEscFreq.
Если в контексте хоть раз происходила нормализация частот, делим SeeEscFreq пополам.
Имеем: RealEscFreq = (A*EscFreq + (1-A)*SeeEscFreq)*B[order]

После кодирования смотрим, кто больше врет - EscFreq или SeeEscFreq, и корректируем значение A.
Если пришел Escape, увеличиваем B пропорционально кодовому пространству символов, иначе уменьшаем B пропорционально кодовому пространству ухода.
Для каждого порядка модели значение B свое, на контексте 0 порядка уход на -1 порядок предсказывается совсем отдельно.
В моей реализации на 1 предсказание идет 7 умножений и 3 деления (в основном, ради прозрачности кода). У меня основное требование к компрессору -- сжимать, и посильнее, поэтому мне такие расходы кажутся оправданными.

Ответы:

Re: PPMonstr I Maxim Smirnov 16:54:01 27/5/2002 (5)
- Re: PPMonstr I Serge Osnach 17:46:56 27/5/2002 (4)
  - Re: PPMonstr I Maxim Smirnov 14:17:02 28/5/2002 (3)
    - Re: PPMonstr I Serge Osnach 14:58:20 28/5/2002 (2)
      - Re: PPMonstr I Maxim Smirnov 16:54:02 28/5/2002 (1)
        
        Re: PPMonstr I DS 16:58:58 31/5/2002 (0)

[an error occurred while processing this directive]

Ответить на это сообщение

Тема:

Имя (желательно полное):

E-Mail:

URL:

Город:

Страна:

Вежливый и подробный комментарий:
(Форматируйте его, пожалуйста, как почту - короткими строками
Еnter в конце строки, пустая строка между параграфами).
> > > Попробую выразить проще -- во многих > > случаях в маскированных контекстах > > вероятность Recent-символа полезно > > уменьшать, а не увеличивать. > > А, терминологические затруднения. > > Маскированный -- это текущий с > > замаскированными символами? > > Тогда понятно. Что ж тут > > удивительного? > > Правда, для некоторых файлов выгодно > > даже в этом случае использовать RS. > > Например, obj2. > Видимо, использовать адаптивное RS. > Тогда коэффициент в RS может принимать значения > > [SEE] > > > > Нет, я с этим особо не > > > > экспериментировал. Насколько помню, > > > > результаты замеров возможных > > улучшений меня не особо увлекли своей > > > > значимостью. > > > Может, дело просто в неудачной > > реализации? > > Это запросто. > > > Я реализовал балансировку отдельно > > для каждого порядка контекста, и > > результатом доволен. И потом, > > балансировщик позволяет более вольно > > обходиться с оценкой вероятности > > символов... > > Каковы реальные изменения сжатия > > и скорости работы "оценивателя" > > (без учета поиска контекстной > > информации) ? > Статистика, увы, не сохранилась. Что-то порядка 0.1% - 0.2%. > Оцениватель, чую, прийдется переделывать. Сейчас происходит следующее: берем контекст, по нему SEE-предсказатель, схожий с Шкаринским, строит SeeEscFreq. > Если в контексте хоть раз происходила нормализация частот, делим SeeEscFreq пополам. > Имеем: RealEscFreq = (A*EscFreq + (1-A)*SeeEscFreq)*B[order] > После кодирования смотрим, кто больше врет - EscFreq или SeeEscFreq, и корректируем значение A. > Если пришел Escape, увеличиваем B пропорционально кодовому пространству символов, иначе уменьшаем B пропорционально кодовому пространству ухода. > Для каждого порядка модели значение B свое, на контексте 0 порядка уход на -1 порядок предсказывается совсем отдельно. > В моей реализации на 1 предсказание идет 7 умножений и 3 деления (в основном, ради прозрачности кода). У меня основное требование к компрессору -- сжимать, и посильнее, поэтому мне такие расходы кажутся оправданными.

Пожалуйста, заполните все поля.
И не нажимайте по два раза на кнопку! Дождитесь ответа сервера.

[an error occurred while processing this directive]