All streams
Search
Write a publication
Pull to refresh
29
17.1
Анатолий @sci_nov

Пользователь

Send message
Этот метод гораздо быстрее чем метод преобразования Фурье

Интересно, причём здесь преобразование Фурье?..
Как всё-таки лаконичен английский для технических приложений — коротко и ясно.
Например, у двоичного кода Хэмминга, исправляющего все однократные ошибки, количество проверочных битов r и длина выходного кодового слова n связаны как n = 2^r — 1, так как количество ненулевых r-разрядных двоичных комбинаций как раз-таки и равно этому числу. То есть возможен ряд (n,k)-кодов (3,1), (7, 4), (15,11)… где k — количество информационных битов.

Для порчи следует применять несистематические коды, когда кодовое слово не делится на два блока, типа «ИИИИППП», где И — информационные символы, П — проверочные (контрольные). Иначе можно легко заметить закономерность.

Если требуется вводить две, три и более ошибок на слово, то можно посмотреть в сторону кодов Боуза-Чоудхури-Хоквингема.

А, вообще, странно защищать информацию избыточными кодами…
хочется управлять степенью восстановления

то есть Вы имели ввиду «управлять степенью порчи»? Так тогда можно сознательно портить один символ на слово, два символа на слово, три и тому подобное. Код выбирать таким, чтобы он 100% восстанавливал однократную, двукратную, трёхкратную ошибки и так далее согласно степени порчи. Под символом можете понимать байт, два байта… в общем, всё, что покажется удобным. Позиция ошибки в слове будет случайной, но код её всё равно исправит, так как ему важна лишь кратность ошибки.
Ладно с табличным декодированием, видимо терминология разная. Это самый примитивный способ декодирования, но и самый трудоёмкий (перебираем всю кодовую таблицу и считаем расстояния между принятым словом и всеми разрешёнными словами, затем выбираем то кодовое слово, которое ближе всего к принятому).

По-поводу «жёсткости». Демодулятор работает в мягком режиме и поэтому на вход декодера уже поступают не двузначные символы (биты), а многозначные (3, 4, 5… как правило, более восьми нет смысла делать). Ладно. Декодер всё-таки должен работать в жёстком режиме (на выходе имеется ввиду), так как потребителю, в конечном счёте, нужны биты. Из-за этого у меня путаница и возникла. По сути, демодулятор по принятому импульсу вычисляет число (уровень напряжения) и смотрит в какой интервал оно попало. Чем дальше от центра, тем более достоверным будет результат (в случае передачи битов). Насколько я помню, если область выходных значений демодулятора делится на три интервала (минимальная степень мягкости), то на вход декодера приходят биты 0 и 1 и так называемый стёртый символ (его можно обозначить как X). Линейные блочные коды (тем более и циклические) могут восстанавливать стёртые символы, причём на это требуется столько же ресурсов, сколько и на обнаружение. В этом-то и есть «фишка» мягкого режима, причём есть ещё плюс: с точки зрения теории информации декодеру будет поступать больше информации, чем при жёсткой демодуляции. С этих позиций чем отличается алгоритм Чейзера? Количеством интервалов (то есть там будут стёртые символы X1, X2, Xm)?
… Что-то сложно… Про алгоритм Чейза ни разу не слышал… Это что, табличное декодирование по минимуму расстояния? И всё-таки, «жёсткий» или «мягкий» декодер? И почему помехи искажают вектор из нулей и единиц в дробные числа?.. Что-то я вообще в ауте, хотя преподаю кодирование…
Придётся что-нибудь написать :).
Представляя число 123456789 в десятитысячной системе счисления, мы получаем сразу два преимущества: во-первых, сокращаем количество потребляемой памяти, так как вместо массива из 9 чисел нам достаточно хранить массив из 3 чисел (1, 2345 и 6789)

Это неверно. Теоретически объём памяти не изменяется, так как мы в обоих случаях используем безизбыточные системы счисления и информацию никоим образом не сжимаем и тем более не теряем. Это всего лишь изменение основания.
Например, для передачи 256-значного символа требуются восьмибитовые кодовые слова (байты). Представляя 256-значный символ в шестнадцатеричной системе счисления, получим, что потребуется два символа по 4 бита, то есть тот же байт.
log(256)/log(16)*log2(16) = log(256)/log(2)*log2(2) => log(M)/log(N1)*log2(N1) = log(M)/log(N2)*log2(N2).
При практической реализации возможны некоторые дробления, так как ячейки памяти удобно бить на байты.
Да нет, в прямом смысле. Бывает после действительно напряжённой умственной работы встаёшь, а зад вспотел…
Работники умственного труда работают в поте жопы :).
Исправил ошибку, связанную с сохранением уровня сигнала на выходе сглаживающего фильтра: должна быть равна единице сумма коэффициентов фильтра, а не сумма их квадратов… Никто из комментировавших не поправил… Какое тут новое, понять бы старое!
Как я понял, хабрахабр — это научно-популярный ресурс, одна из целей которого — разжёвывание чего-либо.
Нового я бы здесь не стал выкладывать (для нового есть патентные ведомства, наконец, читаемые журналы).
Хорошо, что пришло.
Без спектров никак, так как это тонкий инструмент, позволяющий доказать «правильность» какого-либо алгоритма (подробности — в переделанной статье).
Как раз-таки, наоборот, я хотел акцентировать внимание на то, что на алгоритмы полезно смотреть с разных точек зрения и соотносить это со своей целью.
Способ построения частотной характеристики для любого линейного алгоритма дан, импульсной — думаю, он очевиден, способ расчёта энергии — дан, и всё это без рядов Фурье, интегралов, свёрток, z-образов, апериодических звеньев, а только лишь на основании знания комплексных чисел и рядов Тэйлора.
Это не лабораторная и не реферат, хотя никто не запрещает сделать на этой основе какую-нибудь лабораторную (-ые).
Согласен, немного переделаю. Сглаживание — это фильтрация скачков (резких перепадов) и шум здесь специфический. Это была первая итерация, рецензия всегда полезна.
Термин «сглаживание», всё-таки, есть.
Всё-таки знания линейной алгебры первого курса ВУЗа здесь необходимы. Да, 1/3. В статье есть указание на 1/3.
1. Многие называют сглаживанием… Я специально не стал усложнять фильтрацией.
Цитата из Вики:
Сгла́живание — технология, используемая для устранения эффекта «зубчатости», возникающего на краях одновременно выводимого на экран множества отдельных друг от друга плоских, или объёмных изображений. Сглаживание было придумано в 1972 в Массачусетском технологическом институте в Architecture Machine Group, которая позже стала основной частью Media Lab.

2. Белый шум (но опять я не стал вводить такого термина...).

Ну, тогда это не для Вас.
Да, цель — объяснить на пальцах, так как прочитав заметку habrahabr.ru/post/183986/ я увидел простой алгоритм сглаживания изображения по девяти точкам и вспомнил, что здесь есть подводные камни.
Я понимаю, что есть строгие определения и так далее; эта статья — для программиста, разрабатывающего/использующего какие-либо алгоритмы, и не всегда имеющего представления о частотных, импульсных характеристиках, об энергии сигнала, о корреляции.
Специалистам в области ЦОС её читать особо не имеет смысла, хотя для обучения стилю преподавания, объяснения — думаю, можно.
Я здесь специально ушёл от z-преобразования, от интегралов.
Ваша заметка натолкнула меня на написание статьи habrahabr.ru/post/184728/
12 ...
35

Information

Rating
428-th
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity

Specialization

Backend Developer
Senior
From 180,000 ₽
Python
Git
Linux
Qt
C++ STL