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

E-Mail:

URL:

Город:

Страна:

Вежливый и подробный комментарий:
(Форматируйте его, пожалуйста, как почту - короткими строками
Еnter в конце строки, пустая строка между параграфами).
> Здравствуйте, Alex! > > Здравствуйте Vadim ! > > В прошлый раз забыл переключить на английский. > > Наворотил абракадабры на форуме. Извините. Да и перед > > Людьми неудобно. Сейчас стоит на английском. 1 раз ENTER > > В конце и ОК. Все равно абракадабра. С 4 раза все нормально. > > Система – XP. Может и здесь что-то посоветуете. > По правде говоря, никогда с такой проблемой не сталкивался ни под NT, ни под 2000, ни под XP (и русскими, и английскими). Может, это зависит от броузера? Я использую Оперу и изредка IE. > > А то, что при широком интервале вообще с ним не нужно > > ничего делать, (если есть общие биты), для меня явилось > > полной неожиданностью. Я считал, что выводить нужно > > всегда, если появились совпавшие. > Во-первых, если вы помните, я писал, что совпадение - это не самый лучший признак необходимости выполнения вывода (контрпример, в котором уже можно подавать на выход: hi=1000000000000000, low=0111111111111111). > Во-вторых, можно выводить всегда, как только есть воможность. Никто не запрещает :) А можно выводить чуть реже, если данные позволяют. Сжатие ухудшится на мелкие доли процентов, а скорость возрастет заметно. О критерии см. ниже. > > Опять спрошу о ширине интервала. Вы уже не один раз > > объясняли, что расширять интервал нужно по мере > > достаточности ширины интервала для того, чтобы > > он был шире, чем ширина интервала очередного > > кодируемого символа. Это я понял. > Прошу отметить важный момент. При применении опредленной степени моделирования мы всегда можем прикинуть минимальную вероятность любого символа. Подчеркиваю, любого, а не очередного. И вот из этой минимальной вероятности мы и исходим, когда решаем, выполнять ли нормализацию, или нет. > > При кодировании ширина следующего символа > > служит неким параметром, из которого можно > > Вычислить колл. необходимых этапов расширения. > Как я написал выше, очередной символ тут роли не играет. > > (Применяя нормализацию или перенос. То, что больше > > подходит в данный момент). > Что значит, "что больше подходит"? :) Одно с другим тесно связано и последовательность жестко детерминирована. > > Мне непонятно какой параметр при раскодировании, когда > > декодировщик подойдет к этому же месту, можно будет использовать > > для такого же колл. расширений. Здесь ведь следующий символ неизвестен, > > как при кодировании. > Повторюсь, следующий символ на не нужен. При расчете мы всегда используем некий гипотетический символ с самой минимальной возможной вероятностью, какая может встретиться в выбранной нами моделью. > > Везде описывается, что для сохранения точности достаточно > > растягивать интервал до ? или половины полного интервала. > Вот именно, "достаточно". Но не необходимо. Если у вас цель - добиться максимального сжатия, то растяггивать надо при первой же возможности. Если хочется побыстрее, то можно пореже, но не слишком. > > Единственной непонятной мне проблемой при этом подходе > > является то, на основании чего или кого можно будет узнать > > необходимое колл. расширений, когда декодировщик подойдет > > к этому же месту. > Надо, чтобы интервал был заметно больше, чем 1/(минимально возможная вероятность любого символа модели). Чем больше это "заметно", тем лучше сжатие и меньше скорость. > > В источниках, которые я читал, преобладает > > детерминированный подход. В книге “Методы > > Сжатия данных” (Д. Ватолин, А. Ратушняк, > > М. Смирнов, В. Юкин) при описании целочисленного > > алгоритма написано. “Минимизация потерь > > по точности достигается благодаря тому, что длина > > целочисленного интервала всегда! не менее половины > > всего интервала. В пояснении к программе на > > С++, которой забит Интернет, сказано. > > Следуя этим рекомендациям, кодировщик гарантирует, > > что после операций сдвига будет или > > low или > > low (Далее). Значит, пока целочисленный интервал, > > охватываемый накопленными частотами, помещается в ее > > четверть, представленную в code_value, проблема отрицательного > > переполнения не возникает. > Обратите внимание, пункт "Арифметическое сжатие" сотоит из двух частей - из описания классического варианта и из описания интервального кодирования. Поскольку разрядная сетка у нас ограничена, то даже классический вариант является закамуфлированным интервальным кодированием :) > По крайней мере, я описывал именно второй вариант, а не классический :) В свое оправдание могу сказать, что на практике в последнее время применяется именно он. Чтобы распространить наши рассуждения на классический вариант, надо забыть про перенос и считать, что нормализацию выполняем всегда, при первой же возможности :)

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