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

 
 

bug #36612: rref incorrect output

Submitted by:  None
Submitted on:  Sat 09 Jun 2012 07:34:25 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: Wont FixAssigned to: None
Originator Name: Will KellyOriginator Email: -unavailable-
Open/Closed: ClosedRelease: 3.4.3
Operating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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.

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,

Rik <rik5>
Project 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.

Anonymous

 

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

Attach File(s):
   
   
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
  • -unavailable- added by rik5 (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 10 Jun 2012 04:12:46 PM UTCrik5Open/ClosedOpen=>Closed
    Sun 10 Jun 2012 05:04:19 AM UTCrik5Item GroupRegression=>None
      StatusNone=>Wont Fix
    Sat 09 Jun 2012 07:34:25 AM UTCNoneAttached File-=>Added RREF.diff, #25998
      Attached File-=>Added input.m, #25999

    Back to the top


    Powered by Savane 3.1-cleanup1