Автор: Serge Osnach, <ench@intelserv.kiev.ua>
Киев, Украина, 27 мая 2002 года в 17:46:56
В ответ на : Re: PPMonstr I от Maxim Smirnov
в 27 мая 2002 года в 16:54:01:
> > > Правда, для некоторых файлов выгодно
> > > даже в этом случае использовать RS.
> > > Например, obj2.
> > Видимо, использовать адаптивное RS.
> > Тогда коэффициент в RS может
> принимать значения > > [SEE]> Неадаптивный RS вообще не особо
> хорошо работает.
Какие случаи при этом рекомендуется рассматривать?
Я подобрал эмпирически (для немаскированных контекстов):
1) отдельно считаем RS для наиболее вероятного символа
2) Recent суффикса совпадает с Recent текущего контекста
3) Предыдущие 2 символа были Recent в своих контекстах
4) Также коэффициент RS зависит от количества символов в контексте. (numSymbols >= 4 и numSymbols [SEE]
> > Если в контексте хоть раз происходила
> нормализация частот, делим SeeEscFreq
> пополам.
> > Имеем: RealEscFreq = (A*EscFreq + (1-
> A)*SeeEscFreq)*B[order] > что такое A и B ?
> Магические константы?
Естественно, нет. Иначе ничего хорошего мы не получим.
В принципе, ради простоты можно положить A=0, и оценивать только B. ===
RealEscFreq = SeeEscFreq * fixsee[order]/(1-fixsee[order]);
...
if( !Escape )
fixsee[order]-=(fixsee[order])*SeeEscFreq/(TolalFreq*48);
else
fixsee[order]+=(1-fixsee[order])*(TotalFreq-SeeEscFreq)/(TolalFreq*48);
=== Надо попробовать, может и в самом деле смешивание с EscFreq можно убрать за счет более простых методов > > В моей реализации на 1 предсказание
> идет 7 умножений и 3 деления (в
> основном, ради прозрачности кода). У
> меня основное требование к компрессору -
> - сжимать, и посильнее, поэтому мне
> такие расходы кажутся оправданными. > Многовато. Особенно 3 деления.
> В общем, представления об эффективности
> у нас несколько расходятся :-)
Деления можно реализовать таблично :) > Ради 0.x % я бы не мучался.
|