[Numpy-discussion] Dealing with the mode argument in qr.
Wed Feb 6 13:17:02 CST 2013
On Wed, Feb 6, 2013 at 3:44 PM, Benjamin Root <firstname.lastname@example.org> wrote:
> On Tue, Feb 5, 2013 at 4:23 PM, Charles R Harris <
> email@example.com> wrote:
>> Hi All,
>> This post is to bring the discussion of PR #2965<https://github.com/numpy/numpy/pull/2965>to the attention of the list. There are at least three issues in play here.
>> 1) The PR adds modes 'big' and 'thin' to the current modes 'full', 'r',
>> 'economic' for qr factorization. The problem is that the current 'full' is
>> actually 'thin' and 'big' should be 'full'. The solution here was to raise
>> a FutureWarning on use of 'full', alias it to 'thin' for the time being,
>> and at some distant time change 'full' to alias 'big'.
This is asking for problems, to gain some naming consistency. I can't tell
how confusing 'full' is now, but deprecating and removing would be better
than changing what it returns.
>> 2) The 'economic' mode serves little purpose. I propose to deprecate it
>> and add a 'qrf' mode instead, corresponding to scipy's 'raw' mode. We can't
>> use 'raw' itself as traditionally the mode may be specified using the first
>> letter only and that leads to a conflict with 'r'.
That's not a very good reason to not use "raw", since "raw" is a new option
and you therefore don't have to apply the rule that you can give only the
first letter to it.
>> 3) As suggested in 2, the use of single letter abbreviations can
>> constrain the options in choosing mode names and they are not as
>> informative as the full name. A possibility here is to deprecate the use of
>> the abbreviations in favor of the full names.
I'm not feeling very strongly about this, but we have to be careful about
deprecations. Possible future naming constraints on new modes is not a good
reason to deprecate. This one-letter option isn't even mentioned in the
docs it looks like. So why not leave that as is and ensure it keeps working
(add a unit test if needed)?
>> A longer term problem is the divergence between the numpy and scipy
>> versions of qr. The divergence is enough that I don't see any easy way to
>> come to a common interface, but that is something that would be desirable
>> if possible.
This would be a problem imho. But I don't see why you can't add "raw" to
numpy's qr. And if you add "big" and "thin" in numpy, you can add those
modes in scipy too.
> I would definitely be in favor of deprecating abbreviations.
> And while we are on the topic of mode names,
> scipy.ndimage.filters.percentile_filter() has modes of 'mirror' and
> 'reflect', and I don't see any documentation stating if they are the same,
> or what are different about them. I just came across this yesterday.
> Ben Root
> NumPy-Discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion