[Numpy-discussion] Dealing with the mode argument in qr.

Ralf Gommers ralf.gommers@gmail....
Wed Feb 6 13:17:02 CST 2013


On Wed, Feb 6, 2013 at 3:44 PM, Benjamin Root <ben.root@ou.edu> wrote:

>
>
> On Tue, Feb 5, 2013 at 4:23 PM, Charles R Harris <
> charlesr.harris@gmail.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.

Ralf



> Thoughts?
>>
>> Chuck
>>
>>
> 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.
>
> Cheers!
> Ben Root
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20130206/3d576086/attachment.html 


More information about the NumPy-Discussion mailing list