[Octave-bug-tracker] [bug #36612] rref incorrect output

[Rik]

Update of bug #36612 (project octave):

              Item Group:              Regression => None                   
                  Status:                    None => Wont Fix               

    _______________________________________________________

Follow-up 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




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36612>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/