[Numpy-tickets] [NumPy] #609: numpy/linalg/lapack_litemodule.c:lapack_lite_zgeqrf int vs. long
NumPy
numpy-tickets@scipy....
Thu Nov 8 08:24:00 CST 2007
#609: numpy/linalg/lapack_litemodule.c:lapack_lite_zgeqrf int vs. long
--------------------------+-------------------------------------------------
Reporter: kjetijor | Owner: somebody
Type: defect | Status: new
Priority: normal | Milestone: 1.0.5
Component: numpy.linalg | Version: none
Severity: normal | Keywords:
--------------------------+-------------------------------------------------
When building numpy 1.0.4 (and for that matter 1.0.3.1, 1.0.2 and svn-
trunk) on x86_64 some of my users had trouble with numpy.linalg.qr for
matrices containing complex numbers.
After a little bit of testing and digging I ended up doing the following,
in changeset:3850 and changeset:3851 parsing of arguments to zgeqrf was
changed to take integer-values instead of long-values, however in the
return-statement for Py_BuildValue it's still using long-values which
seems to break on my x86_64 boxes with various pythons and various
distros. (Example would be CentOS 5, x86_64 and Python 2.4.3)
numpy.linalg.qr(numpy.array([[1.0j,2],[3,4]])) will raise LinAlgError with
"numpy.linalg.linalg.LinAlgError: zgeqrf returns 18038862643"
What I ended up doing was changing the return-statement for
numpy/linalg/lapack_litemodule.c:lapack_lite_zgeqrf
return Py_BuildValue("{s:i,s:i,s:i,s:i,s:i,s:i}", .....) instead of
return Py_BuildValue("{s:l,s:l,s:l,s:l,s:l,s:l}", .....)
What also seemed to work were to leave the conversions as long's and cast
the values to/as long.
Given that I don't really know the inner workings of numpy all that well,
this may of course be badness, although apparently it seemed to fix my
problem.
--
Ticket URL: <http://scipy.org/scipy/numpy/ticket/609>
NumPy <http://projects.scipy.org/scipy/numpy>
The fundamental package needed for scientific computing with Python.
More information about the Numpy-tickets
mailing list