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

E-Mail:

URL:

Город:

Страна:

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

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