On Sun, Mar 4, 2012 at 10:34 PM, Matthew Brett matthew.br...@gmail.comwrote:
snip
$ export NPY_SEPARATE_COMPILATION=1
Thanks, that did it:
9194b3af704df71aa9b1ff2f53f169848d0f9dc7 is the first bad commit
Let me know if I can debug further,
That commit was a rewrite of np.concatenate,
The place this is used inside of setup.py is here:
https://github.com/numpy/numpy/blob/master/numpy/core/setup.py#L14
I really dislike this build feature, it repeatedly trips me up. In my
opinion, the build should be changed to always do separate compilation, and
the single file mode
Hello,
In 2009 there was a thread in this mailing list concerning the access to
BLAS from C extension modules.
If I have properly understood the thread:
http://mail.scipy.org/pipermail/numpy-discussion/2009-November/046567.html
the answer by then was that those functions were not exposed
On Mon, Mar 5, 2012 at 1:20 AM, Travis Oliphant tra...@continuum.io wrote:
The place this is used inside of setup.py is here:
https://github.com/numpy/numpy/blob/master/numpy/core/setup.py#L14
I really dislike this build feature, it repeatedly trips me up. In my
opinion, the build should
On Mon, Mar 5, 2012 at 10:27 AM, Chao YUE chaoyue...@gmail.com wrote:
Dear all,
Sorry this is not the good place to ask but I think there must be someone
who has done this before.
Is there any way to see the execution of python script line by line as the
verbose model of shell script?
this
On 5 March 2012 15:27, Chao YUE chaoyue...@gmail.com wrote:
Sorry this is not the good place to ask but I think there must be someone
who has done this before.
Is there any way to see the execution of python script line by line as the
verbose model of shell script?
this can be done either in
Try the trace module in the standard library:
http://docs.python.org/library/trace.html
http://www.doughellmann.com/PyMOTW/trace/
- Nathaniel
On Mar 5, 2012 3:27 PM, Chao YUE chaoyue...@gmail.com wrote:
Dear all,
Sorry this is not the good place to ask but I think there must be someone
who
This is a followup to my post from January
(http://mail.scipy.org/pipermail/numpy-discussion/2012-January/059801.html)
and the panel discussion at PyData this weekend. As a few people have
suggested, a better approach than the MPI-broadcasted lookups is to
cache the locations of all the modules
Hi,
On Sun, Mar 4, 2012 at 11:53 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Sun, Mar 4, 2012 at 10:34 PM, Matthew Brett matthew.br...@gmail.com
wrote:
snip
$ export NPY_SEPARATE_COMPILATION=1
Thanks, that did it:
9194b3af704df71aa9b1ff2f53f169848d0f9dc7 is the first bad commit
Let me
What is a simple, efficient way to determine if all elements in an array (in my
case, 1D) are equal? How about close?
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Mar 5, 2012 at 11:14 AM, Neal Becker ndbeck...@gmail.com wrote:
What is a simple, efficient way to determine if all elements in an array (in
my
case, 1D) are equal? How about close?
For the exactly equal case, how about:
I[1] a = np.array([1,1,1,1])
I[2] np.unique(a).size
O[2] 1
Keith Goodman wrote:
On Mon, Mar 5, 2012 at 11:14 AM, Neal Becker ndbeck...@gmail.com wrote:
What is a simple, efficient way to determine if all elements in an array (in
my case, 1D) are equal? How about close?
For the exactly equal case, how about:
I[1] a = np.array([1,1,1,1])
I[2]
How about the following?
exact: numpy.all(a == a[0])
inexact: numpy.allclose(a, a[0])
On Mar 5, 2012, at 2:19 PM, Keith Goodman wrote:
On Mon, Mar 5, 2012 at 11:14 AM, Neal Becker ndbeck...@gmail.com wrote:
What is a simple, efficient way to determine if all elements in an array (in
my
On Mon, Mar 5, 2012 at 1:29 PM, Keith Goodman kwgood...@gmail.com wrote:
I[8] np.allclose(a, a[0])
O[8] False
I[9] a = np.ones(10)
I[10] np.allclose(a, a[0])
O[10] True
One disadvantage of using a[0] as a proxy is that the result depends on the
ordering of a
(a.max() - a.min())
Le 5 mars 2012 14:29, Keith Goodman kwgood...@gmail.com a écrit :
On Mon, Mar 5, 2012 at 11:24 AM, Neal Becker ndbeck...@gmail.com wrote:
Keith Goodman wrote:
On Mon, Mar 5, 2012 at 11:14 AM, Neal Becker ndbeck...@gmail.com
wrote:
What is a simple, efficient way to determine if all
On Mon, Mar 5, 2012 at 2:33 PM, Olivier Delalleau sh...@keba.be wrote:
Le 5 mars 2012 14:29, Keith Goodman kwgood...@gmail.com a écrit :
On Mon, Mar 5, 2012 at 11:24 AM, Neal Becker ndbeck...@gmail.com wrote:
Keith Goodman wrote:
On Mon, Mar 5, 2012 at 11:14 AM, Neal Becker
On Mon, Mar 5, 2012 at 11:36 AM, josef.p...@gmail.com wrote:
How about numpy.ptp, to follow this line? I would expect it's single
pass, but wouldn't short circuit compared to cython of Keith
I[1] a = np.ones(10)
I[2] timeit (a == a[0]).all()
1000 loops, best of 3: 203 us per loop
I[3]
On Mon, Mar 5, 2012 at 1:44 PM, Keith Goodman kwgood...@gmail.com wrote:
On Mon, Mar 5, 2012 at 11:36 AM, josef.p...@gmail.com wrote:
How about numpy.ptp, to follow this line? I would expect it's single
pass, but wouldn't short circuit compared to cython of Keith
I[1] a = np.ones(10)
On Mon, Mar 5, 2012 at 11:52 AM, Benjamin Root ben.r...@ou.edu wrote:
Another issue to watch out for is if the array is empty. Technically
speaking, that should be True, but some of the solutions offered so far
would fail in this case.
Good point.
For fun, here's the speed of a simple cython
Another issue to watch out for is if the array is empty. Technically
speaking, that should be True, but some of the solutions offered so far
would fail in this case.
Similarly, NaNs or Infs could cause problems: they should signal as
False, but several of the solutions would return True.
Keith Goodman wrote:
On Mon, Mar 5, 2012 at 11:52 AM, Benjamin Root ben.r...@ou.edu wrote:
Another issue to watch out for is if the array is empty. Technically
speaking, that should be True, but some of the solutions offered so far
would fail in this case.
Good point.
For fun, here's
On Mon, Mar 5, 2012 at 12:06 PM, Neal Becker ndbeck...@gmail.com wrote:
But doesn't this one fail on empty array?
Yes. I'm optimizing for fun, not for corner cases. This should work
for size zero and NaNs:
@cython.boundscheck(False)
@cython.wraparound(False)
def
On Mon, Mar 5, 2012 at 12:12 PM, Keith Goodman kwgood...@gmail.com wrote:
On Mon, Mar 5, 2012 at 12:06 PM, Neal Becker ndbeck...@gmail.com wrote:
But doesn't this one fail on empty array?
Yes. I'm optimizing for fun, not for corner cases. This should work
for size zero and NaNs:
Hi,
On Mon, Mar 5, 2012 at 11:11 AM, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Sun, Mar 4, 2012 at 11:53 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Sun, Mar 4, 2012 at 10:34 PM, Matthew Brett matthew.br...@gmail.com
wrote:
snip
$ export NPY_SEPARATE_COMPILATION=1
Thanks, that
And simplifying:
In [1]: import numpy as np
In [2]: control = np.array([(1, 2, 3), (0, 5, 6)], dtype=[('f0',
bool), ('f1', bool), ('f2', int)])
In [3]: control == control
Out[3]: array([ True, True], dtype=bool)
In [4]: from numpy import ma
In [5]: control = ma.array([(1, 2, 3), (0, 5, 6)],
On Tue, Jan 17, 2012 at 9:28 AM, Robert Kern robert.k...@gmail.com wrote:
On Tue, Jan 17, 2012 at 05:11, Andreas Kloeckner
li...@informa.tiker.net wrote:
Hi Robert,
On Fri, 30 Dec 2011 20:05:14 +, Robert Kern robert.k...@gmail.com
wrote:
On Fri, Dec 30, 2011 at 18:57, Andreas Kloeckner
I've pushed a bugfix to github, can you confirm that the crash goes away on
your test box? Thanks for tracking that down, the stack trace was very
helpful. Since x86 machines don't have as strict alignment requirements,
bugs like this one will generally remain undetected until someone tests on
an
Hi,
On Mon, Mar 5, 2012 at 8:04 PM, Mark Wiebe mwwi...@gmail.com wrote:
I've pushed a bugfix to github, can you confirm that the crash goes away on
your test box? Thanks for tracking that down, the stack trace was very
helpful. Since x86 machines don't have as strict alignment requirements,
28 matches
Mail list logo
