diff liboctave/numeric/lu.cc @ 24811:a8df0552cc42

* lu.cc: Note possible issues with ipvt vector.
author John W. Eaton <jwe@octave.org>
date Thu, 01 Mar 2018 11:18:44 -0500
parents 194eb4bd202b
children 6652d3823428
line wrap: on
line diff
--- a/liboctave/numeric/lu.cc	Thu Mar 01 11:12:38 2018 -0800
+++ b/liboctave/numeric/lu.cc	Thu Mar 01 11:18:44 2018 -0500
@@ -46,9 +46,15 @@
 {
   namespace math
   {
+    // FIXME: PermMatrix::col_perm_vec returns Array<octave_idx_type>
+    // but ipvt is an Array<octave_f77_int_type>.  This could cause
+    // trouble for large arrays if octave_f77_int_type is 32-bits but
+    // octave_idx_type is 64.  Since this constructor is called from
+    // Fluupdate, it could be given values that are out of range.  We
+    // should ensure that the values are within range here.
+
     template <typename T>
-    lu<T>::lu (const T& l, const T& u,
-               const PermMatrix& p)
+    lu<T>::lu (const T& l, const T& u, const PermMatrix& p)
       : a_fact (u), l_fact (l), ipvt (p.transpose ().col_perm_vec ())
     {
       if (l.columns () != u.rows ())
@@ -70,6 +76,15 @@
         {
           l_fact = L ();
           a_fact = U (); // FIXME: sub-optimal
+
+          // FIXME: getp returns Array<octave_idx_type> but ipvt is
+          // Array<octave_f77_int_type>.  However, getp produces its
+          // result from a valid ipvt array so validation should not be
+          // necessary.  OTOH, it might be better to have a version of
+          // getp that doesn't cause us to convert from
+          // Array<octave_f77_int_type> to Array<octave_idx_type> and
+          // back again.
+
           ipvt = getp ();
         }
     }