[SciPy-dev] scipy.linalg.qr deprecation warning
Jarrod Millman
millman@berkeley....
Thu Nov 27 04:16:33 CST 2008
On Wed, Nov 26, 2008 at 8:27 PM, David Cournapeau <cournape@gmail.com> wrote:
> the ticket cannot be closed: I am the one who added the warning, but
> the change indicated in the ticket has not been done yet; it will have
> to wait for 0.8; the deprecation is only the first step.
Thanks for the clarification, I hadn't looked at what was happening
very closely. After looking more closely, there are several things I
would like to clarify. I am assuming that we want to unify the
calling convention and semantics of qr function in numpy and scipy.
Ideally, I think it would be best if we could move toward having only
one implementation.
To start with here is the current numpy.linalg.qr signature:
def qr(a, mode='full'):
where
mode : {'full', 'r', 'economic'}
Determines what information is to be returned. 'full' is the default.
Economic mode is slightly faster if only R is needed.
Here is the currrent scipy.linalg.qr signature:
def qr(a,overwrite_a=0,lwork=None,econ=False,mode='qr'):
where
econ : boolean
Whether to compute the economy-size QR decomposition, making shapes
of Q and R (M, K) and (K, N) instead of (M,M) and (M,N). K=min(M,N)
mode : {'qr', 'r'}
Determines what information is to be returned: either both Q and R
or only R.
At first glance, it seems like we should simply change the
scipy.linalg.qr signature to:
def qr(a,overwrite_a=0,lwork=None,mode='full'):
where
mode : {'full', 'r', 'economic'}
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.
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?
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?
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?
Regardless of what is decided, I would like to make sure we agree on a
plan and document it in the scipy 0.7 release notes. I also want to
make sure we address:
1. removing sp.linalg.qr_old
2. whether economy mode should optionally return qr or r
3. if economy mode can optionally return qr, how do we specify this option
4. what lapack functions should we use and should numpy/scipy use the
same lapack functions
5. can scipy's qr eventually just call numpy's
6. should we handle mode='full' and mode='economy' in scipy 0.7
7. should we update sp.linalg.qr's docstring using np.linalg.qr's
Thanks,
--
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
More information about the Scipy-dev
mailing list