Building a current checkout of scipy on OSX 10.6 fails when trying
to compile scipy.special.lambertw, giving the message:
Warning: No configuration returned, assuming unavailable.
The full failure is here:
http://img.skitch.com/20091216-d4b8ueqh27g4fqwebu3e3wgfkq.jpg
Chris gmail.com> writes:
>
> By the way, I tried building 1.4rc1 and the same thing happens.
>
... however, I was am able to get a usable build from r7542. Not sure
how much more recent I can go before failures occurred. Somewhere
between 7543 and 7726.
__
David Cournapeau gmail.com> writes:
>
> Ok, so the undefined functions all indicate that the most recently
> implemented ones are not included. I really cannot see any other
> explanation that having a discrepancy between the source tree, build
> tree and installation. Sometimes, svn screw thing
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 11:20 AM, Michael Droettboom wrote:
> I just discovered a bug in fromfile where it can segfault if the file data
> is corrupted in such a way that the array size is insanely large. (It was a
> byte-swapping problem in my own code, but it would be preferable to get an
> exc
I just discovered a bug in fromfile where it can segfault if the file
data is corrupted in such a way that the array size is insanely large.
(It was a byte-swapping problem in my own code, but it would be
preferable to get an exception rather than a crash).
It's a simple fix to propagate the
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
Tue, 15 Dec 2009 09:59:39 -0700, Charles R Harris wrote:
> Would it be appropriate to put macros for all these in config.h or some
> other common spot? Having all the python version dependencies in one
> spot might make it easier to keep current. I've been thinking of moving
> the numpy deprecation
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
On Tue, Dec 15, 2009 at 9:51 AM, Pauli Virtanen
> wrote:
> Tue, 15 Dec 2009 10:36:03 -0600, Bruce Southey wrote:
> [clip]
> > Program received signal SIGSEGV, Segmentation fault. setup_context
> > (registry=, module=,
> > lineno=, filename=,
> > stack_level=)
> > at Python/_warnings.c:449
>
Tue, 15 Dec 2009 10:36:03 -0600, Bruce Southey wrote:
[clip]
> Program received signal SIGSEGV, Segmentation fault. setup_context
> (registry=, module=,
> lineno=, filename=,
> stack_level=)
> at Python/_warnings.c:449
> 449 PyFrameObject *f = PyThreadState_GET()->frame; (gdb) bt
> #0
On 12/15/2009 10:07 AM, Pauli Virtanen wrote:
[snip]
> Please also test the 1.4.x branch
>
> http://svn.scipy.org/svn/numpy/branches/1.4.x
>
> Does it fail too on Python 2.7? There are very few code changes since
> 1.4.x on the path that the test exercises.
>
>
This took a little time fi
On 12/15/2009 10:07 AM, Pauli Virtanen wrote:
> Hi,
>
> Tue, 15 Dec 2009 09:30:08 -0600, Bruce Southey wrote:
>
>> After installing Python2.7, a patched nose
>> (http://bitbucket.org/kumar303/nose-2_7_fixes/ because
>> unittest._TextTestResult has been removed) and numpy '1.5.0.dev8011',
>> num
Hi,
Tue, 15 Dec 2009 09:30:08 -0600, Bruce Southey wrote:
> After installing Python2.7, a patched nose
> (http://bitbucket.org/kumar303/nose-2_7_fixes/ because
> unittest._TextTestResult has been removed) and numpy '1.5.0.dev8011',
> numpy.test crashes with a segmentation fault with the test for:
2009/12/14 Dr. Phillip M. Feldman :
>
> When I issue the command
>
> np.lookfor('bessel')
>
> I get the following:
>
> Search results for 'bessel'
> ---
> numpy.i0
> Modified Bessel function of the first kind, order 0.
> numpy.kaiser
> Return the Kaiser window.
> numpy
Hi,
After installing Python2.7, a patched nose
(http://bitbucket.org/kumar303/nose-2_7_fixes/ because
unittest._TextTestResult has been removed) and numpy '1.5.0.dev8011',
numpy.test crashes with a segmentation fault with the test for:
test_multiarray.TestIO.test_ascii
If I understand the test
Charles R Harris wrote:
> Sort of, it's actually (Xi.T*S).T, now that I think of it... I'll see if
> that is any faster. And if there is a neater way of doing it I'd love to
> hear about it.
>
> Xi*S[:,newaxis]
Thanks! (Obviously doesn't matter much in terms of performance, as it's
o
Fixed in the Wiki.
DG
On Tue, Dec 15, 2009 at 1:36 AM, David Goldsmith
wrote:
> Indeed it should, thanks!
>
> DG
>
> On Tue, Dec 15, 2009 at 1:26 AM, Nadav Horesh wrote:
>>
>> The 2nd line of the doc string
>>
>> randn([d1, ..., dn])
>>
>> should be
>> randn(d1, ..., dn)
>>
>> Nadav
>> _
Mon, 14 Dec 2009 17:09:13 +0100, Francesc Alted wrote:
[clip]
> which makes numpy 5x slower than matlab. Hmm, I definitely think that
> numpy could do better here :-/
It could be useful to track down what exactly is slow, by profiling the
actual C code. Unfortunately, profiling shared libraries
Indeed it should, thanks!
DG
On Tue, Dec 15, 2009 at 1:26 AM, Nadav Horesh wrote:
>
> The 2nd line of the doc string
>
> randn([d1, ..., dn])
>
> should be
> randn(d1, ..., dn)
>
> Nadav
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@s
The 2nd line of the doc string
randn([d1, ..., dn])
should be
randn(d1, ..., dn)
Nadav
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sat, Dec 12, 2009 at 11:27 PM, Paul Ivanov wrote:
> So far, no one has voiced objections, so should I go ahead and check
> this in?
>
+1 from me, at least.
I don't see how there could be a downside to fixing a ton of tests :)
Cheers,
f
___
NumPy-D
27 matches
Mail list logo
