[Numpy-discussion] Failure building scipy.special.lambertw
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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Import error in builds of 7726
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. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Import error in builds of 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 things up when switching > between branches in my experience, so that's something to check for as > well. By the way, I tried building 1.4rc1 and the same thing happens. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal for matrix_rank function in numpy
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
Rank of the array is the number of SVD singular values of the
array that are greater than `tol`.
Parameters
--
M : array-like
array of <=2 dimensions
tol : {None, float}
threshold below which SVD values are considered zero. If `tol`
is None, and `S` is an array with singular values for `M`, and
`eps` is the epsilon value for datatype of `S`, then `tol` set
to ``S.max() * eps``.
Examples
>>> matrix_rank(np.eye(4)) # Full rank matrix
4
>>> I=np.eye(4); I[-1,-1] = 0. # rank deficient matrix
>>> matrix_rank(I)
3
>>> matrix_rank(np.zeros((4,4))) # All zeros - zero rank
0
>>> matrix_rank(np.ones((4,))) # 1 dimension - rank 1 unless all 0
1
>>> matrix_rank(np.zeros((4,)))
0
>>> matrix_rank([1]) # accepts array-like
1
Notes
-
Golub and van Loan [1]_ define "numerical rank deficiency" as using
tol=eps*S[0] (where S[0] is the maximum singular value and thus the
2-norm of the matrix). This is one definition of rank deficiency,
and the one we use here. When floating point roundoff is the main
concern, then "numerical rank deficiency" is a reasonable choice. In
some cases you may prefer other definitions. The most useful measure
of the tolerance depends on the operations you intend to use on your
matrix. For example, if your data come from uncertain measurements
with uncertainties greater than floating point epsilon, choosing a
tolerance near that uncertainty may be preferable. The tolerance
may be absolute if the uncertainties are absolute rather than
relative.
References
--
.. [1] G. H. Golub and C. F. Van Loan, _Matrix Computations_.
Baltimore: Johns Hopkins University Press, 1996.
'''
M = np.asarray(M)
if M.ndim > 2:
raise TypeError('array should have 2 or fewer dimensions')
if M.ndim < 2:
return int(not np.all(M==0))
S = npl.svd(M, compute_uv=False)
if tol is None:
tol = S.max() * np.finfo(S.dtype).eps
return np.sum(S > tol)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal for matrix_rank function in numpy
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 simple... > > I've appended an implementation with some doctests in the hope that it > will be acceptable, I think you need a real example of a nontrivial numerically rank-deficient matrix. Note that c_[eye(4), eye(4)] is actually a full-rank matrix. A matrix is full rank if its numerical rank is equal to min(rows, cols) not max(rows, cols). Taking I=eye(4); I[-1,-1] = 0.0 should be a sufficient example. > Robert - I hope you don't mind me quoting you in the notes. I certainly. However, you do not need to cite me; I'm in the authors list already. On the other hand, you probably shouldn't copy-and-paste anything I write on the mailing list to use in a docstring. On the mailing list, I am answering a particular question and use a different voice than is appropriate for a docstring. Also, a full citation of Golub and Van Loan would be appropriate: .. [1] G. H. Golub and C. F. Van Loan, _Matrix Computations_. Baltimore: Johns Hopkins University Press, 1996. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal for matrix_rank function in numpy
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 view this is still the same numpy namespace. An example of the potential problems is just using an incorrect import statement somewhere: from numpy import rank instead of from numpy.linalg import rank For a package you control, you should really prevent this type of user mistake. > 2. Is there a commitment to keeping both np.rank and np.ndim? > (I.e., can np.rank never be deprecated?) > I do not see that is practical because of the number of releases to actually remove a function. Also the current rank function has existed for a very long time in Numerical Python (as it is present in Numeric). So it could be confusing for a user to think that the function just has been moved rather than being a different function. > If the answers are both 'yes', > then perhaps linalg.rank2d is a possible shorter name. > > Alan Isaac > ___ > 0 Actually I do interpret rank in terms of linear algebra definition, but obviously other people have other meanings. I Bruce ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal for matrix_rank function in numpy
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., can np.rank never be deprecated?) If the answers are both 'yes', then perhaps linalg.rank2d is a possible shorter name. Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal for matrix_rank function in numpy
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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal for matrix_rank function in numpy
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 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 hope that it
>> will be acceptable,
>>
>> Robert - I hope you don't mind me quoting you in the notes.
>>
>> Thanks a lot,
>>
>> Matthew
>>
>>
>> def matrix_rank(M, tol=None):
>> ''' Return rank of matrix using SVD method
>>
>> Rank of the array is the number of SVD singular values of the
>> array that are greater than `tol`.
>>
>> Parameters
>> --
>> M : array-like
>> array of<=2 dimensions
>> tol : {None, float}
>> threshold below which SVD values are considered zero. If `tol`
>> is None, and `S` is an array with singular values for `M`, and
>> `eps` is the epsilon value for datatype of `S`, then `tol` set
>> to ``S.max() * eps``.
>>
>> Examples
>>
>> >>> matrix_rank(np.eye(4)) # Full rank matrix
>> 4
>> >>> matrix_rank(np.c_[np.eye(4),np.eye(4)]) # Rank deficient matrix
>> 4
>> >>> matrix_rank(np.zeros((4,4))) # All zeros - zero rank
>> 0
>> >>> matrix_rank(np.ones((4,))) # 1 dimension - rank 1 unless all 0
>> 1
>> >>> matrix_rank(np.zeros((4,)))
>> 0
>> >>> matrix_rank([1]) # accepts array-like
>> 1
>>
>> Notes
>> -
>> Golub and van Loan define "numerical rank deficiency" as using
>> tol=eps*S[0] (note that S[0] is the maximum singular value and thus
>> the 2-norm of the matrix). There really is not one definition, much
>> like there isn't a single definition of the norm of a matrix. For
>> example, if your data come from uncertain measurements with
>> uncertainties greater than floating point epsilon, choosing a
>> tolerance of about the uncertainty is probably a better idea (the
>> tolerance may be absolute if the uncertainties are absolute rather
>> than relative, even). When floating point roundoff is your concern,
>> then "numerical rank deficiency" is a better concept, but exactly
>> what the relevant measure of the tolerance is depends on the
>> operations you intend to do with your matrix. [RK, numpy mailing
>> list]
>>
>> References
>> --
>> Matrix Computations by Golub and van Loan
>> '''
>> M = np.asarray(M)
>> if M.ndim> 2:
>> raise TypeError('array should have 2 or fewer dimensions')
>> if M.ndim< 2:
>> return int(not np.all(M==0))
>> S = npl.svd(M, compute_uv=False)
>> if tol is None:
>> tol = S.max() * np.finfo(S.dtype).eps
>> return np.sum(S> tol)
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
> This was missing from numpy compared to matlab and gauss.
>
> If we put it in linalg next to np.linalg.cond, then we could shorten
> the name to `rank`, since the meaning of np.linalg.rank should be
> pretty obvious.
>
> Josef
> ___
>
+1 for the function but we can not shorten the name because of existing
numpy.rank() function.
Bruce
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] fromfile can segfault if data is corrupted
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 > exception rather than a crash). > > It's a simple fix to propagate the "array too large" exception before > trying to dereference the NULL array pointer (ret) in PyArray_FromFile (see > attached patch). But my question is: is this an appropriate fix for 1.4 (it > seems pretty straightforward), or should I only make this to the trunk? > > David can weigh in here, but I think you should backport it. It's a bugfix, small, and there is going to be another rc. On the other hand, Travis should stop backporting new functionality. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] fromfile can segfault if data is corrupted
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 "array too large" exception before
trying to dereference the NULL array pointer (ret) in PyArray_FromFile
(see attached patch). But my question is: is this an appropriate fix
for 1.4 (it seems pretty straightforward), or should I only make this to
the trunk?
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
Index: ctors.c
===
--- ctors.c (revision 7992)
+++ ctors.c (working copy)
@@ -3042,6 +3055,10 @@
(next_element) fromfile_next_element,
(skip_separator) fromfile_skip_separator, NULL);
}
+if (ret == NULL) {
+Py_DECREF(dtype);
+return NULL;
+}
if (((intp) nread) < num) {
/* Realloc memory for smaller number of elements */
const size_t nsize = NPY_MAX(nread,1)*ret->descr->elsize;
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal for matrix_rank function in numpy
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 simple...
>
> I've appended an implementation with some doctests in the hope that it
> will be acceptable,
>
> Robert - I hope you don't mind me quoting you in the notes.
>
> Thanks a lot,
>
> Matthew
>
>
> def matrix_rank(M, tol=None):
> ''' Return rank of matrix using SVD method
>
> Rank of the array is the number of SVD singular values of the
> array that are greater than `tol`.
>
> Parameters
> --
> M : array-like
> array of <=2 dimensions
> tol : {None, float}
> threshold below which SVD values are considered zero. If `tol`
> is None, and `S` is an array with singular values for `M`, and
> `eps` is the epsilon value for datatype of `S`, then `tol` set
> to ``S.max() * eps``.
>
> Examples
>
> >>> matrix_rank(np.eye(4)) # Full rank matrix
> 4
> >>> matrix_rank(np.c_[np.eye(4),np.eye(4)]) # Rank deficient matrix
> 4
> >>> matrix_rank(np.zeros((4,4))) # All zeros - zero rank
> 0
> >>> matrix_rank(np.ones((4,))) # 1 dimension - rank 1 unless all 0
> 1
> >>> matrix_rank(np.zeros((4,)))
> 0
> >>> matrix_rank([1]) # accepts array-like
> 1
>
> Notes
> -
> Golub and van Loan define "numerical rank deficiency" as using
> tol=eps*S[0] (note that S[0] is the maximum singular value and thus
> the 2-norm of the matrix). There really is not one definition, much
> like there isn't a single definition of the norm of a matrix. For
> example, if your data come from uncertain measurements with
> uncertainties greater than floating point epsilon, choosing a
> tolerance of about the uncertainty is probably a better idea (the
> tolerance may be absolute if the uncertainties are absolute rather
> than relative, even). When floating point roundoff is your concern,
> then "numerical rank deficiency" is a better concept, but exactly
> what the relevant measure of the tolerance is depends on the
> operations you intend to do with your matrix. [RK, numpy mailing
> list]
>
> References
> --
> Matrix Computations by Golub and van Loan
> '''
> M = np.asarray(M)
> if M.ndim > 2:
> raise TypeError('array should have 2 or fewer dimensions')
> if M.ndim < 2:
> return int(not np.all(M==0))
> S = npl.svd(M, compute_uv=False)
> if tol is None:
> tol = S.max() * np.finfo(S.dtype).eps
> return np.sum(S > tol)
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
This was missing from numpy compared to matlab and gauss.
If we put it in linalg next to np.linalg.cond, then we could shorten
the name to `rank`, since the meaning of np.linalg.rank should be
pretty obvious.
Josef
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] test_multiarray.TestIO.test_ascii segmentation fault with Python2.7
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 macro for that reason. Actually, we have already have a separate NumpyOS_ascii_strtod function that should be used instead of PyOS_ascii_strtod (which, historically, has not satisfier our requirements). So I believe PyOS_ascii_strtod is used in only a single location in Numpy. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Proposal for matrix_rank function in numpy
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 hope that it
will be acceptable,
Robert - I hope you don't mind me quoting you in the notes.
Thanks a lot,
Matthew
def matrix_rank(M, tol=None):
''' Return rank of matrix using SVD method
Rank of the array is the number of SVD singular values of the
array that are greater than `tol`.
Parameters
--
M : array-like
array of <=2 dimensions
tol : {None, float}
threshold below which SVD values are considered zero. If `tol`
is None, and `S` is an array with singular values for `M`, and
`eps` is the epsilon value for datatype of `S`, then `tol` set
to ``S.max() * eps``.
Examples
>>> matrix_rank(np.eye(4)) # Full rank matrix
4
>>> matrix_rank(np.c_[np.eye(4),np.eye(4)]) # Rank deficient matrix
4
>>> matrix_rank(np.zeros((4,4))) # All zeros - zero rank
0
>>> matrix_rank(np.ones((4,))) # 1 dimension - rank 1 unless all 0
1
>>> matrix_rank(np.zeros((4,)))
0
>>> matrix_rank([1]) # accepts array-like
1
Notes
-
Golub and van Loan define "numerical rank deficiency" as using
tol=eps*S[0] (note that S[0] is the maximum singular value and thus
the 2-norm of the matrix). There really is not one definition, much
like there isn't a single definition of the norm of a matrix. For
example, if your data come from uncertain measurements with
uncertainties greater than floating point epsilon, choosing a
tolerance of about the uncertainty is probably a better idea (the
tolerance may be absolute if the uncertainties are absolute rather
than relative, even). When floating point roundoff is your concern,
then "numerical rank deficiency" is a better concept, but exactly
what the relevant measure of the tolerance is depends on the
operations you intend to do with your matrix. [RK, numpy mailing
list]
References
--
Matrix Computations by Golub and van Loan
'''
M = np.asarray(M)
if M.ndim > 2:
raise TypeError('array should have 2 or fewer dimensions')
if M.ndim < 2:
return int(not np.all(M==0))
S = npl.svd(M, compute_uv=False)
if tol is None:
tol = S.max() * np.finfo(S.dtype).eps
return np.sum(S > tol)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] test_multiarray.TestIO.test_ascii segmentation fault with Python2.7
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 > > 449 PyFrameObject *f = PyThreadState_GET()->frame; (gdb) bt > > #0 setup_context (registry=, module= > optimized out>, lineno=, filename= > out>, stack_level=) > > at Python/_warnings.c:449 > > #1 do_warn (registry=, module= > out>, lineno=, filename=, > > stack_level=) > > at Python/_warnings.c:593 > > #2 0x00493c81 in PyErr_WarnEx (category=0x760720, text= > optimized out>, stack_level=1) at Python/_warnings.c:719 #3 > > 0x004c8e94 in PyOS_ascii_strtod (nptr=0x77f08914 "1 , 2 , 3 > > , 4", endptr=0x7fffdb28) at Python/pystrtod.c:282 #4 > > 0x72954151 in NumPyOS_ascii_strtod (s=0x77f08914 "1 , 2 , 3 > > , 4", endptr=0x7fffdb28) at numpy/core/src/multiarray/numpyos.c:527 > > Looks like it's trying to raise a deprecation warning after > PyArray_FromString has released GIL. So that was the reason why it caused > a segfault also in 3.1. > > PyOS_ascii_strtod was deprecated in 2.7 and in 3.1. Apparently, we now > *must* do something like > > #if PY_VERSION_HEX >= 0x0206 >return PyOS_string_to_double(s, endptr, NULL); > #else >return PyOS_ascii_strtod(s, endptr); > #endif > > everywhere the function is used. > > It also seems that this needs to be backported to Numpy 1.4.x... > > (Note to self: this is also the origin of the crashes in scipy/ > lambertw... GIL must be reacquired before raising any warnings.) > > 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 macro for that reason. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] test_multiarray.TestIO.test_ascii segmentation fault with Python2.7
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 setup_context (registry=, module= optimized out>, lineno=, filename= out>, stack_level=) > at Python/_warnings.c:449 > #1 do_warn (registry=, module= out>, lineno=, filename=, > stack_level=) > at Python/_warnings.c:593 > #2 0x00493c81 in PyErr_WarnEx (category=0x760720, text= optimized out>, stack_level=1) at Python/_warnings.c:719 #3 > 0x004c8e94 in PyOS_ascii_strtod (nptr=0x77f08914 "1 , 2 , 3 > , 4", endptr=0x7fffdb28) at Python/pystrtod.c:282 #4 > 0x72954151 in NumPyOS_ascii_strtod (s=0x77f08914 "1 , 2 , 3 > , 4", endptr=0x7fffdb28) at numpy/core/src/multiarray/numpyos.c:527 Looks like it's trying to raise a deprecation warning after PyArray_FromString has released GIL. So that was the reason why it caused a segfault also in 3.1. PyOS_ascii_strtod was deprecated in 2.7 and in 3.1. Apparently, we now *must* do something like #if PY_VERSION_HEX >= 0x0206 return PyOS_string_to_double(s, endptr, NULL); #else return PyOS_ascii_strtod(s, endptr); #endif everywhere the function is used. It also seems that this needs to be backported to Numpy 1.4.x... (Note to self: this is also the origin of the crashes in scipy/ lambertw... GIL must be reacquired before raising any warnings.) -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] test_multiarray.TestIO.test_ascii segmentation fault with Python2.7
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 find to the test because asbytes appears to be
new in SVN.
Anyhow, numpy 1.4.0rc1 works with Python 2.6 but not Python 2.7:
$ python2.6
Python 2.6.1 (r261:532, May 7 2009, 11:38:00)
[GCC 4.3.2 20081105 (Red Hat 4.3.2-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> np.__version__
'1.4.0rc1'
>>> np.fromstring('1,2,3,4',sep=',')
array([ 1., 2., 3., 4.])
>>>
$ python2.7
Python 2.7a1 (r27a1:76674, Dec 14 2009, 13:46:01)
[GCC 4.4.1 20090725 (Red Hat 4.4.1-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> np.__version__
'1.4.0rc1'
>>> np.fromstring('1,2,3,4',sep=',')
Segmentation fault
$ gdb --args python
GNU gdb (GDB) Fedora (6.8.50.20090302-39.fc11)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
Re: [Numpy-discussion] test_multiarray.TestIO.test_ascii segmentation fault with Python2.7
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',
>> numpy.test crashes with a segmentation fault with the test for:
>> test_multiarray.TestIO.test_ascii
>>
>> If I understand the test correctly:
>> $ python
>> Python 2.7a1 (r27a1:76674, Dec 14 2009, 13:46:01) [GCC 4.4.1 20090725
>> (Red Hat 4.4.1-2)] on linux2 Type "help", "copyright", "credits" or
>> "license" for more information.
>> >>> import numpy as np
>> >>> from numpy.compat import asbytes, getexception
>> >>> np.fromstring(asbytes('1 , 2 , 3 , 4'),sep=',')
>> Segmentation fault
>>
> Please run it under gdb to obtain a backtrace.
>
> $ gdb --args python
> ...
> (gdb) run
> ...
> (gdb) bt
> ...
>
>
Thanks for that!
It also made remember that numpy is being built with Atlas 3.8.3.
$ gdb --args python
GNU gdb (GDB) Fedora (6.8.50.20090302-39.fc11)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
Re: [Numpy-discussion] test_multiarray.TestIO.test_ascii segmentation fault with Python2.7
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:
> test_multiarray.TestIO.test_ascii
>
> If I understand the test correctly:
> $ python
> Python 2.7a1 (r27a1:76674, Dec 14 2009, 13:46:01) [GCC 4.4.1 20090725
> (Red Hat 4.4.1-2)] on linux2 Type "help", "copyright", "credits" or
> "license" for more information.
> >>> import numpy as np
> >>> from numpy.compat import asbytes, getexception
> >>> np.fromstring(asbytes('1 , 2 , 3 , 4'),sep=',')
> Segmentation fault
Please run it under gdb to obtain a backtrace.
$ gdb --args python
...
(gdb) run
...
(gdb) bt
...
> This code works under Python2.6 and numpy '1.5.0.dev8011'.
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.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] no ordinary Bessel functions?
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.random.vonmises
> Draw samples from a von Mises distribution.
>
> I assume that there is an ordinary (unmodified) Bessel function in NumPy,
> but have not been able to figure out how to access it. Also, I need to
> operate sometimes on scalars, and sometimes on arrays. For operations on
> scalars, are the NumPy Bessel functions significantly slower than the SciPy
> Bessel functions?
I am afraid this is one of the historical warts in numpy. The proper
place for special functions is in scipy.special, which does indeed
have various flavours of Bessel functions.
Anne
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] test_multiarray.TestIO.test_ascii segmentation fault with Python2.7
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 correctly:
$ python
Python 2.7a1 (r27a1:76674, Dec 14 2009, 13:46:01)
[GCC 4.4.1 20090725 (Red Hat 4.4.1-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> from numpy.compat import asbytes, getexception
>>> np.fromstring(asbytes('1 , 2 , 3 , 4'),sep=',')
Segmentation fault
This code works under Python2.6 and numpy '1.5.0.dev8011'.
Bruce
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Slicing slower than matrix multiplication?
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 only the initialization, but it definitely does make for nicer code.) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] small doc error in numpy.random.randn
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 >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Slicing slower than matrix multiplication?
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 is somewhat difficult. Some tools that I've seen to work (on Linux): - Valgrind (+ KCacheGrind) Together with its cache profiler, this can give useful information on what is the slow part, and on which lines most of the time is spent. - Oprofile Nice sample-based profiler, but requires root. - Qprof (32-bit only) Good for quick sample-based profiling on function level. Easy to use. - Sprof "The" way to profile dynamically linked libraries on Linux. Function-level, and slightly obscure to use. So if someone wants to spend time on this, those are the tools I'd recommend :) -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] small doc error in numpy.random.randn
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@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] small doc error in numpy.random.randn
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
Re: [Numpy-discussion] doctest improvements patch (and possible regressions)
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-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
