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
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
On Wed, Dec 16, 2009 at 10:56 AM, Skipper Seabold jsseab...@gmail.com 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
On Fri, Dec 18, 2009 at 8:21 PM, Fernando Perez fperez@gmail.comwrote:
On Wed, Dec 16, 2009 at 10:56 AM, Skipper Seabold jsseab...@gmail.com
wrote:
Presumably the doctests should be turned into
actual tests (noting Robert's comment) to make it more likely that it
gets in
Just
On Fri, Dec 18, 2009 at 10:21 PM, Fernando Perez fperez@gmail.com wrote:
On Wed, Dec 16, 2009 at 10:56 AM, Skipper Seabold jsseab...@gmail.com 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:
On Fri, Dec 18, 2009 at 21:21, Fernando Perez fperez@gmail.com wrote:
On Wed, Dec 16, 2009 at 10:56 AM, Skipper Seabold jsseab...@gmail.com 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
On Fri, Dec 18, 2009 at 8:10 PM, Robert Kern robert.k...@gmail.com 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
On Tue, Dec 15, 2009 at 3:16 PM, Matthew Brett matthew.br...@gmail.com 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,
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 earlier version
On Wed, Dec 16, 2009 at 2:13 PM, Matthew Brett matthew.br...@gmail.com 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
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
Hi,
On Wed, Dec 16, 2009 at 2:16 PM, Gael Varoquaux
gael.varoqu...@normalesup.org 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,
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
On Tue, Dec 15, 2009 at 12:01 PM, Matthew Brett matthew.br...@gmail.com 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
On 12/15/2009 11:12 AM, josef.p...@gmail.com wrote:
On Tue, Dec 15, 2009 at 12:01 PM, Matthew Brettmatthew.br...@gmail.com
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
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 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.,
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?
In my
On Tue, Dec 15, 2009 at 11:01, Matthew Brett matthew.br...@gmail.com 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
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
20 matches
Mail list logo
