LINUX.ORG.RU

RFC 5053


0

0

Доброе время суток.

Сталкивался ли кто-нибудь с реализацией алгоритма Raptor FEC, указанным в этом RFC? Или есть люди, которые занимались этим? Есть проблемма в декодировании символов, методом указанным в RFC. В какой-то момент необходимо решить уравнение A*C=D (C - искомый вектор) в поле GF(2). Если решать методом гаусса, то все получается отлично(находим вектор C). Если же использовать метод указанный в RFC то вектор C не совпадает с тем что получен, первым методом. Неужели ошибка в RFC?

Какие имплементации?

LamerOk ★★★★★
()
Ответ на: комментарий от beastie

Так в том то и дело что не ясно, где именно ошибка. Если делать преобразования матрицы А способом из RFC то мы в итоге получаем единичную матрицу (собственно цель преобразований), но неправильные intermediate символы. Я собственно поэтому и спрашивала, разбирался кто-нибудь с этим или нет, а ссылку на RFC дала чтобы освежить память.

irishka
() автор топика
Ответ на: комментарий от beastie

Предположительно не ясен этот момент:

5.5.2.5.  Fourth Phase

   For each of the first i rows of A, for each group of 8 columns in the
   U_upper submatrix of this row, if the set of 8 column entries in
   U_upper are not all zero, then the row of the precomputation matrix
   U' that matches the pattern in the 8 columns is exclusive-ORed into
   the row, thus zeroing out those 8 columns in the row at the cost of
   exclusive-ORing one row of U' into the row.
Нужно ли XOR'ть символы в векторе D в соответствии с
5.5.2.1.  General
....
 -  Each time row i of A is exclusive-ORed into row i' in the decoding
      schedule, then in the decoding process, symbol D[d[i]] is
      exclusive-ORed into symbol D[d[i']].

И вообще не понятно назначение U' если только для того чтобы обнулить U_upper, то зачем такое сложное описание?

irishka
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.