Hi,
> I'm happy to write the doctests as tests. My feeling is there is no
> objection to this function at the moment, so it would be reasonable,
> unless I hear otherwise, to commit to SVN.
Committed - with tests in tests_linalg.py - in revision 8029
Cheers,
Matthew
__
On Fri, Dec 18, 2009 at 8:10 PM, Robert Kern wrote:
> My policy and rationale, which I believe is reflected in the docstring
> standard, is that examples in the docstrings should put pedagogical
> concerns above all others. In my experience, a properly robust doctest
> sacrifices the readability,
On Fri, Dec 18, 2009 at 21:21, Fernando Perez wrote:
> On Wed, Dec 16, 2009 at 10:56 AM, Skipper Seabold wrote:
>> Presumably the doctests should be turned into
>> actual tests (noting Robert's comment) to make it more likely that it
>> gets in
>
> Just curious: is there a policy against pure doc
On Fri, Dec 18, 2009 at 10:21 PM, Fernando Perez wrote:
> On Wed, Dec 16, 2009 at 10:56 AM, Skipper Seabold wrote:
>> Presumably the doctests should be turned into
>> actual tests (noting Robert's comment) to make it more likely that it
>> gets in
>
> Just curious: is there a policy against pure
On Fri, Dec 18, 2009 at 8:21 PM, Fernando Perez wrote:
> On Wed, Dec 16, 2009 at 10:56 AM, Skipper Seabold
> wrote:
> > Presumably the doctests should be turned into
> > actual tests (noting Robert's comment) to make it more likely that it
> > gets in
>
> Just curious: is there a policy against p
On Wed, Dec 16, 2009 at 10:56 AM, Skipper Seabold wrote:
> Presumably the doctests should be turned into
> actual tests (noting Robert's comment) to make it more likely that it
> gets in
Just curious: is there a policy against pure doctests in numpy? I've
always found that doctests and 'real test
Hi Gael,
On 16-Dec-09, at 2:16 PM, Gael Varoquaux wrote:
> I was under the impression that we should
> direct users who have linalg problems to scipy, as it can do much
> more.
I agree about pushing users in that direction, but I think that's
mostly a consequence of all the wrapped Fortran
Hi,
On Wed, Dec 16, 2009 at 2:16 PM, Gael Varoquaux
wrote:
> On Wed, Dec 16, 2009 at 02:13:08PM -0500, Matthew Brett wrote:
>> I'm happy to write the doctests as tests. My feeling is there is no
>> objection to this function at the moment, so it would be reasonable,
>> unless I hear otherwise,
On Wed, Dec 16, 2009 at 02:13:08PM -0500, Matthew Brett wrote:
> I'm happy to write the doctests as tests. My feeling is there is no
> objection to this function at the moment, so it would be reasonable,
> unless I hear otherwise, to commit to SVN.
I have one small comment: I am really happy to
On Wed, Dec 16, 2009 at 2:13 PM, Matthew Brett wrote:
> Hi,
>
>>> Is it reasonable to summarize that, to avoid confusion, we keep
>>> 'matrix_rank' as the name?
>>>
>>> I've edited as Robert suggested, attempting to adopt a more suitable
>>> tone in the docstring...
>
>> What comes next when someo
Hi,
>> Is it reasonable to summarize that, to avoid confusion, we keep
>> 'matrix_rank' as the name?
>>
>> I've edited as Robert suggested, attempting to adopt a more suitable
>> tone in the docstring...
> What comes next when someone offers up a useful function like this?
> We are using an earli
On Tue, Dec 15, 2009 at 3:16 PM, Matthew Brett wrote:
> Hi,
>
> Is it reasonable to summarize that, to avoid confusion, we keep
> 'matrix_rank' as the name?
>
> I've edited as Robert suggested, attempting to adopt a more suitable
> tone in the docstring...
>
> Thanks a lot,
>
> Matthew
>
>
What c
Hi,
Is it reasonable to summarize that, to avoid confusion, we keep
'matrix_rank' as the name?
I've edited as Robert suggested, attempting to adopt a more suitable
tone in the docstring...
Thanks a lot,
Matthew
def matrix_rank(M, tol=None):
''' Return rank of matrix using SVD method
On Tue, Dec 15, 2009 at 11:01, Matthew Brett wrote:
> Hi,
>
> Following on from the occasional discussion on the list, can I propose
> a small matrix_rank function for inclusion in numpy/linalg?
>
> I suggest it because it seems rather a basic need for linear algebra,
> and it's very small and sim
On 12/15/2009 12:47 PM, Alan G Isaac wrote:
> On 12/15/2009 1:39 PM, Bruce Southey wrote:
>
>> +1 for the function but we can not shorten the name because of existing
>> numpy.rank() function.
>>
> 1. Is it a rule that there cannot be a name duplication
> in this different namespace?
>
On 12/15/2009 1:39 PM, Bruce Southey wrote:
> +1 for the function but we can not shorten the name because of existing
> numpy.rank() function.
1. Is it a rule that there cannot be a name duplication
in this different namespace?
2. Is there a commitment to keeping both np.rank and np.ndim?
(I.e., c
Hi,
> +1 for the function but we can not shorten the name because of existing
> numpy.rank() function.
I don't feel strongly about the name, but I imagine you could do
from numpy.linalg import rank as matrix_rank
if you weren't using the numpy.linalg namespace already...
Best,
Matthew
___
On 12/15/2009 11:12 AM, josef.p...@gmail.com wrote:
> On Tue, Dec 15, 2009 at 12:01 PM, Matthew Brett
> wrote:
>
>> Hi,
>>
>> Following on from the occasional discussion on the list, can I propose
>> a small matrix_rank function for inclusion in numpy/linalg?
>>
>> I suggest it because it see
On Tue, Dec 15, 2009 at 12:01 PM, Matthew Brett wrote:
> Hi,
>
> Following on from the occasional discussion on the list, can I propose
> a small matrix_rank function for inclusion in numpy/linalg?
>
> I suggest it because it seems rather a basic need for linear algebra,
> and it's very small and
Hi,
Following on from the occasional discussion on the list, can I propose
a small matrix_rank function for inclusion in numpy/linalg?
I suggest it because it seems rather a basic need for linear algebra,
and it's very small and simple...
I've appended an implementation with some doctests in the
20 matches
Mail list logo
