Hi,
On Mon, Mar 5, 2012 at 8:04 PM, Mark Wiebe 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,
> bugs like this
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 a
Hi,
This is following the discussion on bug
http://projects.scipy.org/numpy/ticket/2017
Essentially, there is a discrepency between the actual type of the
flags member in the dtype C structure (char) and how it is declared in
the descriptor table (T_INT). The problem is that we are damned if we
f
I'm not sure if it's been re-hashed again or not, but this is the sort of error
that showed up all the time while debugging NumPy on Sparc hard-ware. The
problem is that memory has to be aligned before calculations take place.
With this kind of dtype, field 'f2' will be aligned on a 2-byte
On Tue, Jan 17, 2012 at 9:28 AM, Robert Kern wrote:
> On Tue, Jan 17, 2012 at 05:11, Andreas Kloeckner
> wrote:
>> Hi Robert,
>>
>> On Fri, 30 Dec 2011 20:05:14 +, Robert Kern
>> wrote:
>>> On Fri, Dec 30, 2011 at 18:57, Andreas Kloeckner
>>> wrote:
>>> > Hi Robert,
>>> >
>>> > On Tue, 27
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)], d
Hi,
On Mon, Mar 5, 2012 at 11:11 AM, Matthew Brett wrote:
> Hi,
>
> On Sun, Mar 4, 2012 at 11:53 PM, Mark Wiebe wrote:
>> On Sun, Mar 4, 2012 at 10:34 PM, Matthew Brett
>> wrote:
>>>
>>>
>>> > $ export NPY_SEPARATE_COMPILATION=1
>>>
>>> Thanks, that did it:
>>>
>>> 9194b3af704df71aa9b1ff2f53f1
On Mon, Mar 5, 2012 at 12:12 PM, Keith Goodman wrote:
> On Mon, Mar 5, 2012 at 12:06 PM, Neal Becker 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.wrapa
On Mon, Mar 5, 2012 at 12:06 PM, Neal Becker 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 allequal(np.ndarray[np.float64_t, ndim=1] a):
c
Keith Goodman wrote:
> On Mon, Mar 5, 2012 at 11:52 AM, Benjamin Root 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 sp
> 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.
On Mon, Mar 5, 2012 at 11:52 AM, Benjamin Root 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 allclose:
I
On Mon, Mar 5, 2012 at 1:44 PM, Keith Goodman wrote:
> On Mon, Mar 5, 2012 at 11:36 AM, 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()
>
On Mon, Mar 5, 2012 at 11:36 AM, 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] timeit a.min() == a.max
On Mon, Mar 5, 2012 at 2:33 PM, Olivier Delalleau wrote:
> Le 5 mars 2012 14:29, Keith Goodman a écrit :
>
>> On Mon, Mar 5, 2012 at 11:24 AM, Neal Becker wrote:
>> > Keith Goodman wrote:
>> >
>> >> On Mon, Mar 5, 2012 at 11:14 AM, Neal Becker
>> >> wrote:
>> >>> What is a simple, efficient way
Le 5 mars 2012 14:29, Keith Goodman a écrit :
> On Mon, Mar 5, 2012 at 11:24 AM, Neal Becker wrote:
> > Keith Goodman wrote:
> >
> >> On Mon, Mar 5, 2012 at 11:14 AM, Neal Becker
> wrote:
> >>> What is a simple, efficient way to determine if all elements in an
> array (in
> >>> my case, 1D) are
On Mon, Mar 5, 2012 at 1:29 PM, Keith Goodman 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()) < epsilon
is a
On Mon, Mar 5, 2012 at 11:24 AM, Neal Becker wrote:
> Keith Goodman wrote:
>
>> On Mon, Mar 5, 2012 at 11:14 AM, Neal Becker 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
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 wrote:
>> What is a simple, efficient way to determine if all elements in an array (in
>> my
>> case, 1D) are equ
Keith Goodman wrote:
> On Mon, Mar 5, 2012 at 11:14 AM, Neal Becker 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)
On Mon, Mar 5, 2012 at 11:14 AM, Neal Becker 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# All equal
I[3]
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
Hi,
On Sun, Mar 4, 2012 at 11:53 PM, Mark Wiebe wrote:
> On Sun, Mar 4, 2012 at 10:34 PM, Matthew Brett
> wrote:
>>
>>
>> > $ export NPY_SEPARATE_COMPILATION=1
>>
>> Thanks, that did it:
>>
>> 9194b3af704df71aa9b1ff2f53f169848d0f9dc7 is the first bad commit
>>
>> Let me know if I can debug furt
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 fou
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" wrote:
> Dear all,
>
> Sorry this is not the good place to ask but I think there must be someone
> who has done this be
On 5 March 2012 15:27, Chao YUE 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 ipython or by r
thanks. I am using ubuntu (for my local computer) and on our server we have
only ipython or shell... but I think I can try your suggestion on my own
computer.
Chao
2012/3/5
> On Mon, Mar 5, 2012 at 10:27 AM, Chao YUE wrote:
> > Dear all,
> >
> > Sorry this is not the good place to ask but I th
On Mon, Mar 5, 2012 at 10:27 AM, Chao YUE 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 can be done ei
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 can be done either in ipython or by running the python script in a
shell scri
On Sun, Mar 4, 2012 at 2:18 PM, Luis Pedro Coelho wrote:
> On Saturday, March 03, 2012 04:38:53 PM David Cournapeau wrote:
>> I don't think the code is comparable either - some of the stuff done
>> in the C code is done in the C++ code your are calling. The C code
>> could be significantly improve
On Mon, Mar 5, 2012 at 1:20 AM, Travis Oliphant 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 be changed to
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 (only
>
> 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 fil
On Sun, Mar 4, 2012 at 10:34 PM, Matthew Brett wrote:
>
> > $ 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, and I've traced the
34 matches
Mail list logo
