Re: PPMonstr I

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

E-Mail:

URL:

Город:

Страна:

Вежливый и подробный комментарий:
(Форматируйте его, пожалуйста, как почту - короткими строками
Еnter в конце строки, пустая строка между параграфами).
> > Я не верно понял вопрос. > > Тогда еще раз. > > AFAIK, причина -- расширение > > механизма вторичной оценки символа > > (в H. выполнялось только для самых > > часто встреч-ся) и совмещение его с RS. > Понял. > Возникла мысль - завести еще контексты, где хранить инфу в духе "средняя вероятность того, что в произвольном контексте после символа А будет символ Б - 12/39 ..." и заниматься RS скажем для первых 3-х наиболее вероятных символов. Первые прикидки (с априорными формулами) показали ограниченную полезность такого подхода. Стабильно как минимум 0.05% выиграша. > Да, обьясни магию чисел - в маскированных контекстах увеличиваю частоту на 1/4 для всех символов, которые (Symbol XOR Recent) Думаю, целесообразнее задать > > вопрос прямо автору :-) > Сомневаюсь, что он даст полезный ответ. > > > Посчитаем количество бит в выходном > > потоке у нормального компрессора, и > > компрессора, который не пишет в выход > > Escape (точнее, не дает их арифметику). > > Разница размеров и есть "количество > > Escape". > > Хорошо. А как ведет себя размер оставшейся части? :-) > А куда ж ему деваться? Уменьшается, естественно. > > > Естественно, что кодовое пространство > > Escape при RS уменьшается, если мы > > оцениваем счетчик уходов, а не > > вероятность ухода. Но это уменьшение > > будет компенсировано увеличением оценки > > счетчика ухода при адаптивной оценке. > > это, опять же, зависит от реализации > > SEE. Насколько я помню, в моем PPMN > > это компенсируется, но не всегда.

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

[an error occurred while processing this directive]