Войти
ПрограммированиеФорумОбщее

Упаковка графика функции (5 стр)

Страницы: 1 2 3 4 5
#60
23:57, 30 ноя. 2016

foxes
>было бы неплохо здесь запомнить диапазон для исходного отрезка
Ясное дело. Код был чисто примером алгоритма. По хорошему диапазон тоже сохранить.

>В этом случае можно отбросить часть высоко частотных коэффициентов.
Кстати да, внятно можно делать.

>Еще раз уточню если диапазоны не будут выходить за рамки 32-бит то разницы между сжатием только коэффициентов или части коэффициентов и хранения дополнительных бит не должно быть.
Так в ходе работы самого алгоритма трансформации ведь округления набегут, вроде?
Или предлагаешь DCT в повышенной точности считать?
Хотя можно, вообще, если вдуматься.


#61
0:34, 1 дек. 2016

FordPerfect
писал писал и запорол ответ. Короче:
Если представить минимальное и максимальное значение ряда в виде фиксированной точки то у тебя может потребоваться к примеру 37 бит (разница экспонент + 23 бита на мантису, но не факт что все 23 бита минимального числа будут использованы). Когда ты переводишь коэффициенты в целые числа то у тебя всего 32 бита (23 мантиса + 8 бит на разницу между экспанентами и знак). Прелесть вычисления DCT в том что числа ряда умножаются на коэффициенты с чередованием знака (условно) (+-)1/n, а это сумма значений на несколько порядков больше требуемой точности, отсюда избыточность коэффициентов. По этому если даже числа будут выходить за точность 23 бит, но не за 32, это не приведет к искажениям, только после приведения к целым.

То есть если у тебя диапазон от 0 до 2^31 то самый большой коэффициент будет чуть больше 2^30, а основная масса не больше 2^24 - эти коэффициенты будут характеризовать основную форму графика функции, а самые минимальные коэффициенты и будут влиять на точность. Если взять формулу быстрого разложения в ряд Фурье то там видно что проблема с округлением float будет возникать при сильном скачке на графике (быстрое изменение функции). Поскольку числа получаются составными то их точность может достигать 46 бит (в любом случае больше 23).

За счет того что самые большие числа задают форму графика, при большом диапазоне значений они могут отличаться от минимальных значений на 2^128 - вот тут и будет проблема скачка экспоненты, когда на минимальных значениях порядки между приближенной и исходной функциями отличаются +-2^89. А для больших значений в выбранном отрезке это просто не соответствие младшего бита мантисы, по этому половина отрезка сожмется и даст при вычитании малые значения, а половина даст шум.

> Или предлагаешь DCT в повышенной точности считать?
Кстати да, для самого вычисления можно точность повысит. Будет более правильно работать для привычных форм графика, но проблема в целом ни куда не денется.

#62
10:20, 1 дек. 2016

foxes
> Вкратце, по мере чтения данных формируется словарь последовательностей, которые
> кодируются минимально возможным количеством бит.

Основной сути LZW ты так и не назвал... Ну да ладно

#63
12:04, 1 дек. 2016

innuendo
Ну так назови открой мне глаза, а то понты какие то и не больше.

FordPerfect
Кстати есть вариант решения данной проблемы это вариативный отрезок функции, аналогично "rle". Брать последовательность значений подходящих по фиксированный диапазон точности не более 256 значений не меньше 16. Не будет необходимости сжимать и мудрить с участками имеющие паразитирующие скачки графика. Но это опять же нужно будет тестировать. Будут неудобства с распаковкой отдельного блока но это решиться через индексацию, не обязательную для хранения.

И еще момент диапазон будет двойным и логарифмическим и его нет необходимости сохранять [2^(max exp);2^(max exp-32)] и [-2^(max exp-32);-2^(max exp)]

#64
12:08, 1 дек. 2016

foxes
> Ну так назови открой мне глаза, а то понты какие то и не больше.

При добавлении нового слова в словарь всегда добавляется новый символ к уже существующему слову

#65
13:05, 1 дек. 2016
Молодец, осталось только найти оправдания и основания твоему первоначальному вбросы не в тему, и степень влияние всего этого на незыблемость обозначенных мною фактов. Окромя очередного виртуального собеседования в сообщество gamedev.
#66
14:11, 1 дек. 2016

foxes
> Молодец, осталось только

Осталось только понять, зачем ты сказал про LZW... Если бы было про LZ* тогда вопросов не было бы :)

#67
14:53, 1 дек. 2016
ок, продолжаем понтоваться, и искать доказательства сомнению моих слов совершенно отличных от темы обсуждения предметных областях.

innuendo
lzw для всех lz* алгоритмов является основой, FordPerfect использовал аналог, zip. И какой бы аналог для примера я не назвал, это ни как не влияет на отсутствие/присутствие указанного мной в них недостатка. Так что вопрос твой ни как не проливает свет, не то что на сжатие при помощи zip, но и на решения поставленной задачи тем более. И его присутствие здесь ни как не оправданно.
Страницы: 1 2 3 4 5
ПрограммированиеФорумОбщее

Тема в архиве.