Closed Hi-Angel closed 6 years ago
Hi, Konstantin;
The problem you're running into is because of the Reed-Solomon "Symbol" size (in bits). An RS<4095...> codeword consists of symbols that are 12 bits in size. To contain these symbols, ezpwd RS requires vectors of uint16_t data, not uint8_t. Give that a try.
To contain these symbols, ezpwd RS requires vectors of uint16_t data, not uint8_t
Thanks! I tried making use of ezpwd, but now this requirement made me try exploring other libraries as well. To my surprise, I often encounter these magic numbers 255
,256
. This made me wondering: whether ezpwd's lack of API to just encode an arbitrary-sized buffer being a limitation of the library or the Reed-Solomon codes per se?
IOW, can't the library encode a 4095-bytes (and why not 4096 anyway?) buffer as uint8_t because it's how the library designed, or because it's how does Reed-Solomon codes work?
IOW, can't the library encode a 4095-bytes (and why not 4096 anyway?) buffer as uint8_t because it's how the library designed, or because it's how does Reed-Solomon codes work?
FTR, I asked at work, and turned out it's specific to Reed-Solomon codes per se. The reason for specific numbers like 256 and 4096 being something about irreducible polynomials over a Galua field for e.g. 2⁸=256, because whole byte-sequence from POV of Reed-Solomon being a 256 or 4096 coefficients of the polynomial. I am not sure, but probably e.g. 2⁹ is not an irreducible polynomial.
The reason for 12 bit elements I didn't really understand, but it does exist.
And the reason for the off-by-one, i.e. 255 instead of 256, and 4095 instead of 4096 is because polynomial calculation for the element at zero-th position doesn't have same effect as for the others.
An example from README stops working once capacity increased from 255 to 4095.
Steps to reproduce:
test.cpp
:int main() { // Reed Solomon codec w/ 4095 symbols, up to 4091 data, 4 parity symbols ezpwd::RS<4095,4091> rs; std::vector data;
}