gap-packages/guava

ReedSolomon decoding is broken

fblomqvi opened this issue · 0 comments

I run GAP 4.8.8 with Guava 3.14 on Fedora 28. The ReedSolomon decoding seems to be broken in at least two ways.

The decoder crashes with some inputs:

gap> C := ReedSolomonCode(10,5);
a cyclic [10,6,5]3..4 Reed-Solomon code over GF(11)
gap> r := Codeword([7,10,3,2,4,9,5,7,5,9], C);
[ 7 10 3 2 4 9 5 7 5 9 ]
gap> Decodeword(C, r);
Error, FFE operations: <divisor> must not be zero in
  return Value( rnew, a ^ (- i) ) / Value( pol, a ^ (- i) )
 ; at /usr/lib/gap/pkg/guava/lib/decoders.gi:380 called from
func( C[i] ) at /usr/lib/gap/lib/coll.gi:746 called from
List( ErrorLocator, function ( i )
      return Value( rnew, a ^ (- i) ) / Value( pol, a ^ (- i) );
  end ) at /usr/lib/gap/pkg/guava/lib/decoders.gi:380 called from
SpecialDecoder( C )( C, c
 ) at /usr/lib/gap/pkg/guava/lib/decoders.gi:146 called from
<function "unknown">( <arguments> )
 called from read-eval loop at line 28 of *stdin*
you can replace <divisor> via 'return <divisor>;'
brk>

The same also happens with eg.

r := Codeword([ 10 7 3 1 8 1 8 7 4 8 ], C);
r := Codeword([ 4 0 0 6 5 0 0 0 0 0 ], C);
r := Codeword([ 5 1 1 7 2 6 4 6 1 5 ] , C);

Additionally, the decoder fails silently with some inputs:

gap> C := ReedSolomonCode(10,4);
a cyclic [10,7,4]2..3 Reed-Solomon code over GF(11)
gap> r := Codeword([2,7,8,3,7,10,3,4,3,4], C);
[ 2 7 8 3 7 10 3 4 3 4 ]
gap> c := Decodeword(C, r);
[ 2 7 8 3 3 10 3 4 3 4 ]
gap> c in C;
false

The distance from r to a closest codeword is 2, so r might not be uniquely decodable. Thus this could be considered a feature. On the other hand, we have:

gap> C:=ReedSolomonCode(10,5);
a cyclic [10,6,5]3..4 Reed-Solomon code over GF(11)
gap> r := Codeword([3,7,5,5,1,10,3,9,2,8], C);
[ 3 7 5 5 1 10 3 9 2 8 ]
gap> Decodeword(C, r);
Error, not decodable called from
SpecialDecoder( C )( C, c ) at /usr/lib/gap/pkg/guava/lib/decoders.gi:146 called from
<function "unknown">( <arguments> )
 called from read-eval loop at line 17 of *stdin*
you can 'quit;' to quit to outer loop, or
you can 'return;' to continue
brk> 

and hence it seems logical to consider the silent failure a bug.

I am aware that the special decoder used for ReedSolomon codes is the BCH decoder. So maybe it would be more appropriate to say that the BCH decoder is broken. I have, however, only used the decoder with ReedSolomon codes, so I'm choosing the more conservative title.