[SciPy-dev] scipy.linalg.qr deprecation warning
Tiziano Zito
opossumnano@gmail....
Thu Nov 27 09:51:11 CST 2008
> If so, would it make sense for 0.7 to change the scipy.linalg.qr signature to:
> def qr(a,overwrite_a=0,lwork=None,econ=None,mode='full'):
> where
> mode : {'full', 'qr' 'r', 'economic'}
> This would allow code written for scipy 0.8 to run on scipy 0.7;
> while, letting code written for scipy 0.6 to run on 0.7.
+1
> Another issue with doing this is that it appears that the current
> implementation of qr in scipy will let you do the following:
> >>> q, r = sp.linalg.qr(a, econ=True)
> >>> r2 = sp.linalg.qr(a, econ=True, mode='r')
> To do this we could do something like
> mode : {'full', 'r', 'economic', 'economic-full'}
> so that
> >>> q, r = sp.linalg.qr(a, mode='economic-full')
> >>> r2 = sp.linalg.qr(a, mode='economic')
>
> This raises the question whether it makes sense to return both q and r
> when using economy mode. If so, should we change the qr
> implementation in numpy as well? Currently, in numpy when
> mode='economy' qr returns A2:
> 444 mode = 'economic'
> 445 A2 : double or complex array, shape (M, N)
> 446 The diagonal and the upper triangle of A2 contains R,
> 447 while the rest of the matrix is undefined.
>
> Are there any references that we should mention in the docstring,
> which would be able to explain economy mode and the trade-offs
> regarding whether q is returned as well as r?
I think "economy" mode is the term that is used in matlab's qr
function. Personally I'm not sure I understand why is economy mode
at all important.
> Also if we want to change the call signatures to be the same should
> the new scipy sig be:
> def qr(a,mode='full',overwrite_a=0,lwork=None):
> That way we could add (...overwrite_a=0,lwork=None) to numpy 1.3 so
> that np.linalg.qr sig would be:
> def qr(a,mode='full',overwrite_a=0,lwork=None):
>
> NumPy uses 'zgeqrf' or 'dgeqrf', while scipy uses 'orgqr' or 'ungqr'.
> Does anyone know if it makes sense for the numpy and scipy
> implementations to use different lapack functions? Or is it just
> historical artifact? If it is merely historic, which functions should
> both implementations use?
If I understood the issue correctly:
NumPY:
- 'zgeqrf' or 'dgeqrf' are used to get 'r' and then
'zungqr' or 'dorgqr' are used to get 'q'. The latter happens only
if mode='full'. The only difference between mode='economic' and
mode='r' is a call to fastCopyAndTranspose (there is even a
comment in the code: "economic mode. Isn't actually economic.",
i.e. 'economic' mode is a fake).
SciPy:
- the same routines as in NumPy are used and but 'econ' and 'mode'
are disjoint (as in matlab).
I think that the SciPy behaviour is more consistent (as in SciPy
ticket #800) and that NumPy's 'qr' should be changed to match SciPy
signature (without the overwrite_a and lwork arguments).
> Another issue is that scipy has an older implementation of qr called
> qr_old. Can we just remove it? Or do we need to deprecate it first?
+1 to just remove it.
To summarize my views:
> 1. removing sp.linalg.qr_old
+1
> 2. whether economy mode should optionally return qr or r
+1
> 3. if economy mode can optionally return qr, how do we specify this option
have two different arguments: mode={'r', 'qr'} and econ={True, False}
> 4. what lapack functions should we use and should numpy/scipy use the
> same lapack functions
Both use the same lapack functions, so no problem here.
> 5. can scipy's qr eventually just call numpy's
-1
SciPy will always have overwrite_a and lwork (it's calling the
f2py generated interface when present), whereas NumPy uses lapack_lite
(where there is no overwrite_X argument).
> 6. should we handle mode='full' and mode='economy' in scipy 0.7
-1 (see above)
> 7. should we update sp.linalg.qr's docstring using np.linalg.qr's
-1 (see above)
ciao,
tiziano
More information about the Scipy-dev
mailing list