bugGNU Octave - Bugs: bug #36612, rref incorrect output

 
 

bug #36612: rref incorrect output

Submitter:  None
Submitted:  Sat 09 Jun 2012 07:34:25 AM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Wont Fix Assigned to:  None
Originator Name:  Will Kelly Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.4.3
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 10 Jun 2012 05:04:19 AM UTC, comment #1: 

Part of the issue is knowing your input and your algorithm. 

The current algorithm uses a tolerance to decide which elements are legitimately non-zero.  After multiple calculations with a matrix mathematical errors accumulate which are on the order of eps.  The current algorithm uses a tolerance based on eps to decide which matrix elements are legitimately non-zero and which are only non-zero due to the problems of computing with limited precision on computers.

The example you gave is pathological in that the first non-zero element is 30 orders of magnitude smaller than the next non-zero element.  If this matrix had been the result of ordinary calculations then Octave would have certainly made the correct choice to ignore the 1e-30 entry and assume it was due to errors in calculating with floating point numbers.

As an example, consider sin (pi) which should be zero, but is not.


sin (pi)
ans =  1.2246e-16
A = [ pi, 0
       0, pi/2];
B = sin (A)
B =

   0.00000   0.00000
   0.00000   1.00000

B(1)
ans =  1.2246e-16
rref (B)
ans =

   0   1
   0   0


In this case Octave gets it quite right.  There is only one non-zero entry.

The second thing is to know your input.  If the sample matrix arose not through calculation, but say a direct measurement, and the 1e-30 value was real then you can simply tell Octave not to ignore it by providing a smaller tolerance.  For example,


rref ([1e-30, 0; 0, 1], 1e-31)
ans =

   1   0
   0   1



Rik <rik5>
Group administrator
Sat 09 Jun 2012 07:34:25 AM UTC, original submission:  

For a given matrix X (see input.m) if one of the values is small enough rref(X) will not scale this value to one. I haven't really had a chance to compare Octave's rref script with my own. My script, however, does produce the correct results. I've provided it so that if you wish, you can compare and contrast the two. (Or use it if it meets your standards.) I only briefly took a look at your script, long enough to copy the header information and the usage script. I'm not sure your script utilized partial pivoting, but I haven't really delved too deep into the matter.
GNU Octave, version 3.4.3
Octave was configured for \"x86_64-redhat-linux-gnu\".
Fedora 16. Running Octave in QtOctave.


rref([1E-30,0;0,1;])
ans =
      0 1
      0 0
Not equal to expected :
ans =
      1 0
      0 1


Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #25998:  RREF.diff added by None (8KiB - text/x-patch)
file #25999:  input.m added by None (436B - text/x-objcsrc)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  •  

    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.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-06-10 rik5 Open/ClosedOpen Closed
    2012-06-10 rik5 Item GroupRegression None
        StatusNone Wont Fix
    2012-06-09 None Attached File- Added RREF.diff, #25998
        Attached File- Added input.m, #25999

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code