scipy.linalg.qr deprecation warning
Hi guys, when using scipy.linalg.qr without specifying any keyword argument the user gets the following warning: DeprecationWarning: qr econ argument will be removed after scipy 0.7. The economy transform will then be available through the mode='economic' argument. While I appreciate the idea of warning users of future API changes, I think emitting a warning even if the function has been called without specifying the "econ" argument is a bit too much. The user may not even know what "econ" stands for. What about setting "econ=None" by default and - if the user specified "econ" explicitly, emit the warning and set econ according to user preference - if the user did not specify "econ", set it to the current default, i.e. False ? If no one objects, I will do the needed changes myself tomorrow. tiziano
On Wed, 26 Nov 2008 14:34:43 +0100 Tiziano Zito <opossumnano@gmail.com> wrote:
Hi guys,
when using scipy.linalg.qr without specifying any keyword argument the user gets the following warning:
DeprecationWarning: qr econ argument will be removed after scipy 0.7. The economy transform will then be available through the mode='economic' argument.
While I appreciate the idea of warning users of future API changes, I think emitting a warning even if the function has been called without specifying the "econ" argument is a bit too much. The user may not even know what "econ" stands for. What about setting "econ=None" by default and
- if the user specified "econ" explicitly, emit the warning and set econ according to user preference - if the user did not specify "econ", set it to the current default, i.e. False
?
If no one objects, I will do the needed changes myself tomorrow.
tiziano
In that context http://projects.scipy.org/scipy/scipy/ticket/243 might be of interest. Nils
On Wed, Nov 26, 2008 at 6:08 AM, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
On Wed, 26 Nov 2008 14:34:43 +0100 Tiziano Zito <opossumnano@gmail.com> wrote:
What about setting "econ=None" by default and
- if the user specified "econ" explicitly, emit the warning and set econ according to user preference - if the user did not specify "econ", set it to the current default, i.e. False
+1 Please go ahead and make the change.
Could you also update and close this ticket? Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/
On Thu, Nov 27, 2008 at 12:46 PM, Jarrod Millman <millman@berkeley.edu> wrote:
On Wed, Nov 26, 2008 at 6:08 AM, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
On Wed, 26 Nov 2008 14:34:43 +0100 Tiziano Zito <opossumnano@gmail.com> wrote:
What about setting "econ=None" by default and
- if the user specified "econ" explicitly, emit the warning and set econ according to user preference - if the user did not specify "econ", set it to the current default, i.e. False
+1 Please go ahead and make the change.
Could you also update and close this ticket?
Hi Jarrod, 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. David
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/
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
participants (4)
-
David Cournapeau -
Jarrod Millman -
Nils Wagner -
Tiziano Zito