bugGNU Octave - Bugs: bug #55424, [octave forge] (communications)...

 
 

bug #55424: [octave forge] (communications) rsdec() returns incorrect result if shortened message is used

Submitter:  Klaus Braun <kmb721>
Submitted:  Tue 08 Jan 2019 09:07:02 PM UTC
   
 
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  None Assigned to:  None
Originator Name:  Klaus Braun Open/Closed:  * Open
Release:  * 4.4.1 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 11 Jan 2019 07:35:32 PM UTC, comment #1: 

Sorry, I missunderstood the selection "Operating System".
This issue impacts surely Any Operating System.
Perhaps this increases the chance of attention.

Klaus Braun <kmb721>
Tue 08 Jan 2019 09:07:02 PM UTC, original submission:  

communications *|   1.2.1 |
rsdec() returns errors (in longer messages uncorrectable errors), when I use shortened messages, i.e. the message is shorter than k.
In the following example (encode - decode) there should be of course no error:

m = 3;           % Number of bits per symbol
n = 2^m - 1;     % Codeword length
k = 5;           % Message length
sk = 3;   %shortened message length

msg = gf([2 7 3; 4 0 6],m);

code = rsenc(msg,n-k+sk,sk);

[msg2, nerr] = rsdec(code,n-k+sk,sk);
disp(nerr); # returns [1;1] (should be [0;0])


The same example but with full lenght message returns no error:

m = 3;           % Number of bits per symbol
n = 2^m - 1;     % Codeword length
k = 5;           % Message length

msg = gf([0 0 2 7 3; 0 0 4 0 6],m);

code = rsenc(msg,n,k);

[msg2, nerr] = rsdec(code,n,k);
disp(nerr); # returns [0;0] (correct)


vague guess where the bug could hide:
in gf.cc (ca. line 1741 - 1773)
from:
 // Find a corresponding fcr and prim that coincide with the roots.
 to
  /* Find prim-th root of 1, used in decoding */
maybe "n" should be replaced by "nn"? (in several places).


---------
Another problem (maybe a following error):
If I use rsgenpoly(?,?,?,0) with zero as b-parameter, then octave crashes when executing rsdec():

m = 3;           % Number of bits per symbol
n = 2^m - 1;     % Codeword length
k = 5;           % Message length

msg = gf([0 0 2 7 3; 0 0 4 0 6],m);

p=11;
polynom = rsgenpoly(n, k, p, 0); # <- here zero

code = rsenc(msg,n,k);

[msg2, nerr] = rsdec(code,n,k,polynom); # crash

Octave crashes (disappears) or if I use poly also for rsenc, then rsdec() executes very long/endless.
I am not really sure if b=0 is a useful input, but nevertheless octave should never crash.

Klaus Braun <kmb721>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by kmb721 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-08 mtmiller Summary[octave forge](communications) rsdec() returns incorrect result if shortened message is used [octave forge] (communications) rsdec() returns incorrect result if shortened message is used

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code