Is this behavior of masked arrays intended, or is it a bug?
This part works as I would expected:
import numpy as np
a=np.ma.fix_invalid(np.array([np.nan,-1,0,1]))
b=np.ma.fix_invalid(np.array([np.nan,-1,0,1]))
idx=(a==b)
print(a[idx][3])
# 1.0
Note that a[idx] has shape (4,).
But if I change t
Hi All,
Below is some array behaviour which i think is odd
>>> a=arange(10)
>>> a
array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
>>> b=nonzero(a<0)
>>> b
(array([], dtype=int32),)
>>> if not b[0]:
... print 'b[0] is false'
...
b[0] is false
Above case the b[0] is empty so it is fine it is considered fa
On Thu, Apr 1, 2010 at 8:16 PM, Charles R Harris
wrote:
>
>
> On Thu, Apr 1, 2010 at 7:59 PM, David Cournapeau wrote:
>
>> Anne Archibald wrote:
>>
>> >
>> > First I guess we should check which systems don't have log1p
>>
>> This is already done - we do use the system log1p on linux (but note
>> t
On Thu, Apr 1, 2010 at 7:59 PM, David Cournapeau wrote:
> Anne Archibald wrote:
>
> >
> > First I guess we should check which systems don't have log1p
>
> This is already done - we do use the system log1p on linux (but note
> that log2_1p is not standard AFAIK). I would guess few systems outside
>
Anne Archibald wrote:
>
> First I guess we should check which systems don't have log1p
This is already done - we do use the system log1p on linux (but note
that log2_1p is not standard AFAIK). I would guess few systems outside
windows don't have log1p, given that msun has an implementation,
D
On Thu, Apr 1, 2010 at 3:51 PM, Anne Archibald wrote:
> On 1 April 2010 13:38, Charles R Harris wrote:
> >
> >
> > On Thu, Apr 1, 2010 at 8:37 AM, Charles R Harris <
> charlesr.har...@gmail.com>
> > wrote:
> >>
> >>
> >> On Thu, Apr 1, 2010 at 12:46 AM, Anne Archibald
> >> wrote:
> >>>
> >>> On
>>> np.version.version
'1.4.0'
>>> c = np.polynomial.chebyshev.Chebyshev(1)
>>> c.deriv(1.0)
Chebyshev([ 0.], [-1., 1.])
>>> c.integ(1.0)
Traceback (most recent call last):
File "", line 1, in
File "", line 441, in integ
File "C:\Python26\lib\site-packages\numpy\polynomial\chebyshev.py", li
Thanks Didrik!
On Thu, Apr 1, 2010 at 1:21 AM, Didrik Pinte wrote:
> On Wed, 2010-03-31 at 23:13 -0700, Vishal Rana wrote:
> > Hi,
> >
> >
> > A calculation which goes like this...
> >
> >
> > n = 5
> > a = np.arange(1000)
> > b = np.arange(n - 1, 1000)
> >
> >
> > l = []
> > for i in range(b.s
On 1 April 2010 13:38, Charles R Harris wrote:
>
>
> On Thu, Apr 1, 2010 at 8:37 AM, Charles R Harris
> wrote:
>>
>>
>> On Thu, Apr 1, 2010 at 12:46 AM, Anne Archibald
>> wrote:
>>>
>>> On 1 April 2010 02:24, Charles R Harris
>>> wrote:
>>> >
>>> >
>>> > On Thu, Apr 1, 2010 at 12:04 AM, Anne Ar
On 1 April 2010 14:30, M Trumpis wrote:
> Hi all,
>
> disclaimer: pardon my vast ignorance on the subject of ufuncs, that
> will explain the naivety of the following questions
>
> This morning I was looking at this line of code, which was running
> quite slow for me and making me think
>
> data_ha
2010/4/1 Shailendra :
> Hi All,
> I want to make a function which should be like this [...]
We had a thread some time ago, very long and with lots of working
code, which seems to me related to this:
Thread title: "Iterative Matrix Multiplication" (do a search under
"Bug Reports" on numpy.scipy.or
On Thu, Apr 1, 2010 at 11:53 AM, Warren Weckesser
wrote:
> M Trumpis wrote:
>> Hi all,
>>
>>
>>
>> And a last mini question, it doesn't appear that any() is doing short
>> circuit evaluation. It runs in appx the same time whether an array is
>> sparsely nonzero, fully zero, or fully nonzero.
>>
>
M Trumpis wrote:
> Hi all,
>
>
>
> And a last mini question, it doesn't appear that any() is doing short
> circuit evaluation. It runs in appx the same time whether an array is
> sparsely nonzero, fully zero, or fully nonzero.
>
>
That's not what I see. Here's an example that shows the a line
to, 2010-04-01 kello 11:30 -0700, M Trumpis kirjoitti:
[clip]
> Actually I realized later that the main slow-down comes from the fact
> that my array was strided in fortran order (ascending strides). But
> from the point of view of a ufunc that is operating independently at
> each value, why would
Hi all,
disclaimer: pardon my vast ignorance on the subject of ufuncs, that
will explain the naivety of the following questions
This morning I was looking at this line of code, which was running
quite slow for me and making me think
data_has_nan = numpy.isnan(data_array).any()
I knew that the a
On Thu, Apr 1, 2010 at 8:37 AM, Charles R Harris
wrote:
>
>
> On Thu, Apr 1, 2010 at 12:46 AM, Anne Archibald > wrote:
>
>> On 1 April 2010 02:24, Charles R Harris
>> wrote:
>> >
>> >
>> > On Thu, Apr 1, 2010 at 12:04 AM, Anne Archibald <
>> peridot.face...@gmail.com>
>> > wrote:
>> >>
>> >> On
Thanks Robert.
I ended up letting Python handle the memory management. In my C-extension I
just call Py_INCREF to prevent Python from deallocating it while I'm using
it. I then call Py_DECREF once I'm done with it.
Jeremy
___
NumPy-Discussion mailing l
On Thu, Apr 1, 2010 at 12:46 AM, Anne Archibald
wrote:
> On 1 April 2010 02:24, Charles R Harris wrote:
> >
> >
> > On Thu, Apr 1, 2010 at 12:04 AM, Anne Archibald <
> peridot.face...@gmail.com>
> > wrote:
> >>
> >> On 1 April 2010 01:59, Charles R Harris
> wrote:
> >> >
> >> >
> >> > On Wed, Ma
On Thu, Apr 1, 2010 at 3:52 AM, David Cournapeau wrote:
> Anne Archibald wrote:
> > On 1 April 2010 03:15, David Cournapeau wrote:
> >> Anne Archibald wrote:
> >>
> >>> Particularly given the comments in the boost source code, I'm leery of
> >>> this fix; who knows what an optimizing compiler wil
Oops.
Wrongly timed.
> t= np.array(timeit.repeat(perf, repeat= rep, number= 1))/ rep
should be
t= np.array(timeit.repeat(perf, repeat= rep, number= 1))
eat
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org
Shailendra gmail.com> writes:
>
> Hi All,
> I want to make a function which should be like this
>
> cordinates1=(x1,y1) # x1 and y1 are x-cord and y-cord of a large
> number of points
> cordinates2=(x2,y2) # similar to condinates1
> indices1,indices2= match_cordinates(cordinates1,cordinates2)
>
Anne Archibald wrote:
> On 1 April 2010 03:15, David Cournapeau wrote:
>> Anne Archibald wrote:
>>
>>> Particularly given the comments in the boost source code, I'm leery of
>>> this fix; who knows what an optimizing compiler will do with it?
>> But the current code *is* wrong: it is not true that
Shailendra gmail.com> writes:
>
> Hi All,
> I want to make a function which should be like this
>
> cordinates1=(x1,y1) # x1 and y1 are x-cord and y-cord of a large
> number of points
> cordinates2=(x2,y2) # similar to condinates1
> indices1,indices2= match_cordinates(cordinates1,cordinates2)
On 1 April 2010 03:15, David Cournapeau wrote:
> Anne Archibald wrote:
>
>>
>> Particularly given the comments in the boost source code, I'm leery of
>> this fix; who knows what an optimizing compiler will do with it?
>
> But the current code *is* wrong: it is not true that u == 1 implies u -
> 1
On Wed, 2010-03-31 at 23:13 -0700, Vishal Rana wrote:
> Hi,
>
>
> A calculation which goes like this...
>
>
> n = 5
> a = np.arange(1000)
> b = np.arange(n - 1, 1000)
>
>
> l = []
> for i in range(b.size):
> # Absolute difference of n a elements and nth b element
> x = np.abs(a[i:i +
Anne Archibald wrote:
>
> Particularly given the comments in the boost source code, I'm leery of
> this fix; who knows what an optimizing compiler will do with it?
But the current code *is* wrong: it is not true that u == 1 implies u -
1 == 0 (and that (u-1) != 0 -> u != 1), because the spacing
26 matches
Mail list logo
