[Numpy-tickets] [NumPy] #446: numpy.linalg.qr bug on 64-bit platforms

[NumPy]

#446: numpy.linalg.qr bug on 64-bit platforms
--------------------+-------------------------------------------------------
 Reporter:  fperez  |       Owner:  somebody
     Type:  defect  |      Status:  new     
 Priority:  normal  |   Milestone:          
Component:  Other   |     Version:          
 Severity:  normal  |    Keywords:          
--------------------+-------------------------------------------------------
 Hi all,

 I recently got a report of a bug triggered only on 64-bit hardware, and on
 a machine (in case it's relevant) that runs python 2.5:

 {{{

 In [1]: import numpy

 In [2]: numpy.__version__
 Out[2]: '1.0.2.dev3540'

 In [3]: a = numpy.array([[1.0,2],[3,4]])

 In [4]: numpy.linalg.qr(a)
  ** On entry to DGEQRF parameter number  2 had an illegal value
 sage[~]>  # dumped back at system prompt

 }}}

 On my 2.4-using, 32-bit desktop, this code runs just fine.

 A quick grep exercise in the sources shows this as the probable source: in
 numpy/linalg/dlapack_lite.c, this code is the one that seems to matter
 (around line 4920):

 {{{
     /* Function Body */
     *info = 0;
     nb = ilaenv_(&c__1, "DGEQRF", " ", m, n, &c_n1, &c_n1, (ftnlen)6,
 (ftnlen)
             1);
     lwkopt = *n * nb;
     work[1] = (doublereal) lwkopt;
     lquery = *lwork == -1;
     if (*m < 0) {
         *info = -1;
     } else if (*n < 0) {
         *info = -2;
     } else if (*lda < max(1,*m)) {
         *info = -4;
     } else if ((*lwork < max(1,*n) && ! lquery)) {
         *info = -7;
     }
     if (*info != 0) {
         i__1 = -(*info);
         xerbla_("DGEQRF", &i__1);
         return 0;
     } else if (lquery) {
         return 0;
     }
 }}}
 I'm not sure why *n should have come out negative while *m is fine in this
 case though.

-- 
Ticket URL: <http://projects.scipy.org/scipy/numpy/ticket/446>
NumPy <http://projects.scipy.org/scipy/numpy>
The fundamental package needed for scientific computing with Python.