[SciPy-dev] scipy.linalg.qr deprecation warning

[Tiziano Zito]

> 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