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

E-Mail:

URL:

Город:

Страна:

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

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