On Thu, Mar 18, 2010 at 7:26 PM, Christopher Barker
wrote:
> josef.p...@gmail.com wrote:
>>> I'm facing this at the moment: not a big deal, but I'm using histogram2d
>>> on some data. I just realized that it may have some NaNs in it, and I
>>> have no idea how those are being handled.
>
>> histogr
josef.p...@gmail.com wrote:
>> I'm facing this at the moment: not a big deal, but I'm using histogram2d
>> on some data. I just realized that it may have some NaNs in it, and I
>> have no idea how those are being handled.
> histogram2d handles neither masked arrays nor arrays with nans
> correctly
On Thu, Mar 18, 2010 at 5:19 PM, Davide Cittaro
wrote:
> Hi all,
> Is there a fast numpy way to find the peak boundaries in a (looong, millions
> of points) smoothed signal? I've found some approaches, like this:
>
> z = data[1:-1]
> l = data[:-2]
> r = data[2:]
> f = np.greater(z, l)
> f *= np.g
On Thu, Mar 18, 2010 at 5:12 PM, Eric Firing wrote:
> Ryan May wrote:
>> On Thu, Mar 18, 2010 at 2:46 PM, Christopher Barker
>> wrote:
>>> Gael Varoquaux wrote:
On Thu, Mar 18, 2010 at 12:12:10PM -0700, Christopher Barker wrote:
> sure -- that's kind of my point -- if EVERY numpy array w
2010/3/18 Frank Horowitz :
> I'm working on a piece of optimisation code where it turns out to be
> mathematically convenient to have a matrix where a few pre-chosen elements
> must be computed at evaluation time for the dot product (i.e. matrix
> multiplication) of a matrix with a vector.
The
Hi all,
Is there a fast numpy way to find the peak boundaries in a (looong, millions of
points) smoothed signal? I've found some approaches, like this:
z = data[1:-1]
l = data[:-2]
r = data[2:]
f = np.greater(z, l)
f *= np.greater(z, r)
boundaries = np.nonzero(f)
but it is too sensitive... it d
Ryan May wrote:
> On Thu, Mar 18, 2010 at 2:46 PM, Christopher Barker
> wrote:
>> Gael Varoquaux wrote:
>>> On Thu, Mar 18, 2010 at 12:12:10PM -0700, Christopher Barker wrote:
sure -- that's kind of my point -- if EVERY numpy array were
(potentially) masked, then folks would write code t
On Thu, Mar 18, 2010 at 3:46 PM, Christopher Barker
wrote:
> Gael Varoquaux wrote:
>> On Thu, Mar 18, 2010 at 12:12:10PM -0700, Christopher Barker wrote:
>>> sure -- that's kind of my point -- if EVERY numpy array were
>>> (potentially) masked, then folks would write code to deal with them
>>> app
On Thu, Mar 18, 2010 at 2:46 PM, Christopher Barker
wrote:
> Gael Varoquaux wrote:
>> On Thu, Mar 18, 2010 at 12:12:10PM -0700, Christopher Barker wrote:
>>> sure -- that's kind of my point -- if EVERY numpy array were
>>> (potentially) masked, then folks would write code to deal with them
>>> app
Gael Varoquaux wrote:
> On Thu, Mar 18, 2010 at 12:12:10PM -0700, Christopher Barker wrote:
>> sure -- that's kind of my point -- if EVERY numpy array were
>> (potentially) masked, then folks would write code to deal with them
>> appropriately.
>
> That's pretty much saying: "I have a complicate
On Thu, Mar 18, 2010 at 3:19 PM, Gael Varoquaux
wrote:
> On Thu, Mar 18, 2010 at 12:12:10PM -0700, Christopher Barker wrote:
>> sure -- that's kind of my point -- if EVERY numpy array were
>> (potentially) masked, then folks would write code to deal with them
>> appropriately.
>
> That's pretty mu
On Thu, Mar 18, 2010 at 12:12:10PM -0700, Christopher Barker wrote:
> sure -- that's kind of my point -- if EVERY numpy array were
> (potentially) masked, then folks would write code to deal with them
> appropriately.
That's pretty much saying: "I have a complicated problem and I want every
one
josef.p...@gmail.com wrote:
> On Wed, Mar 17, 2010 at 3:12 PM, Christopher Barker
>> Given all the limitations of NaN, having a masked
>> array is a better way to go, but I'd love it if they were "just there",
>> and therefore EVERY numpy function and package built on numpy would
>> handle them gr
Hi,
Can I get someone to look at: http://projects.scipy.org/numpy/ticket/1435
Basically, numpy.gradient() uses numpy.zeros() to create an output
array. This breaks the use of any ndarray subclasses, like masked
arrays, since the function will only return
ndarrays. I've attached a patch that fix
A Thursday 18 March 2010 16:26:09 Anne Archibald escrigué:
> Speak for your own CPUs :).
>
> But seriously, congratulations on the wide publication of the article;
> it's an important issue we often don't think enough about. I'm just a
> little snarky because this exact issue came up for us recent
Hello,
Please tolerate my impatience for being the first announcing the new
discussion platform :) and my cross-posting over the lists.
The new site is beating at ask.scipy.org . David Warde-Farley is moving the
questions from the old-site at advice.mechanicalkern.com (announced at
SciPy09 by Rob
http://carshowcolombia.com/John.html
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mar 18, 2010, at 11:03 AM, Bruce Southey wrote:
> On 03/17/2010 04:20 PM, Pierre GM wrote:
>> On Mar 17, 2010, at 11:09 AM, Bruce Southey wrote:
>>
>>> On 03/17/2010 01:07 AM, Pierre GM wrote:
>>>
All,
As you're probably aware, the current test suite for numpy.ma raises some
na
On Mar 17, 2010, at 9:16 PM, Charles R Harris wrote:
>
>
> On Wed, Mar 17, 2010 at 7:39 PM, Darren Dale wrote:
> On Wed, Mar 17, 2010 at 8:22 PM, Charles R Harris
> wrote:
> >
> > What bothers me here is the opposing desire to separate ufuncs from their
> > ndarray dependency, having them opera
On 03/17/2010 04:20 PM, Pierre GM wrote:
> On Mar 17, 2010, at 11:09 AM, Bruce Southey wrote:
>
>> On 03/17/2010 01:07 AM, Pierre GM wrote:
>>
>>> All,
>>> As you're probably aware, the current test suite for numpy.ma raises some
>>> nagging warnings such as "invalid value in ...". These
On Mar 17, 2010, at 5:43 PM, Charles R Harris wrote:
>
>
>
> On Wed, Mar 17, 2010 at 3:13 PM, Darren Dale wrote:
> On Wed, Mar 17, 2010 at 4:48 PM, Pierre GM wrote:
> > On Mar 17, 2010, at 8:19 AM, Darren Dale wrote:
> >>
> >> I started thinking about a third method called __input_prepare__ th
On Thu, Mar 18, 2010 at 08:33, Martin Raspaud wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello,
>
> I work on a 64bit machine with 64bits enable fedora on it.
>
> I just discovered that numpy.int on the python part are 64bits ints, while
> npy_int in the C api are 32bits ints.
N
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dag Sverre Seljebotn skrev:
> Martin Raspaud wrote:
> Hello,
>
> I work on a 64bit machine with 64bits enable fedora on it.
>
> I just discovered that numpy.int on the python part are 64bits ints, while
> npy_int in the C api are 32bits ints.
>
>
On 18 March 2010 09:57, Francesc Alted wrote:
> Hi,
>
> Konrad Hinsen has just told me that my article "Why Modern CPUs Are Starving
> and What Can Be Done About It", which has just released on the March/April
> issue of "Computing in Science and Engineering", also made into this month's
> free-ac
On Mar 17, 2010, at 3:18 PM, josef.p...@gmail.com wrote:
> On Wed, Mar 17, 2010 at 3:12 PM, Christopher Barker
> wrote:
>>
>> One of the things I liked about MATLAB was that NaNs were well handled
>> almost all the time. Given all the limitations of NaN, having a masked
>> array is a better way t
On Mar 17, 2010, at 11:09 AM, Bruce Southey wrote:
> On 03/17/2010 01:07 AM, Pierre GM wrote:
>> All,
>> As you're probably aware, the current test suite for numpy.ma raises some
>> nagging warnings such as "invalid value in ...". These warnings are only
>> issued when a standard numpy ufunc (eg.
Martin Raspaud wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello,
>
> I work on a 64bit machine with 64bits enable fedora on it.
>
> I just discovered that numpy.int on the python part are 64bits ints, while
> npy_int in the C api are 32bits ints.
>
np.intc
Dag Sverre
> I can
Hi,
Konrad Hinsen has just told me that my article "Why Modern CPUs Are Starving
and What Can Be Done About It", which has just released on the March/April
issue of "Computing in Science and Engineering", also made into this month's
free-access selection on IEEE's ComputingNow portal:
http://w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I work on a 64bit machine with 64bits enable fedora on it.
I just discovered that numpy.int on the python part are 64bits ints, while
npy_int in the C api are 32bits ints.
I can live with it, but it seems to be different on 32bit machines, he
On Wed, Mar 17, 2010 at 10:16 PM, Charles R Harris
wrote:
>
>
> On Wed, Mar 17, 2010 at 7:39 PM, Darren Dale wrote:
>>
>> On Wed, Mar 17, 2010 at 8:22 PM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Wed, Mar 17, 2010 at 5:26 PM, Darren Dale wrote:
>> >>
>> >> On Wed, Mar 17, 2010 at 5:43 PM, C
On Thu, Mar 18, 2010 at 09:56:21AM +0100, Sebastian Haase wrote:
> How would people feel about unifying the function vs. the method behavior ?
> One could add an addition option like
> `repeat` or `fillZero`.
You mean fill_zero...
Sorry, my linter went off. :)
Gaël
__
On Wed, Mar 17, 2010 at 10:56 PM, Charles R Harris
wrote:
>
>
> On Wed, Mar 17, 2010 at 8:42 AM, Alan G Isaac wrote:
>>
>> On 3/17/2010 10:16 AM, josef.p...@gmail.com wrote:
>> > numpy.resize(a, new_shape)
>> > Return a new array with the specified shape.
>> >
>> > If the new array is larger than
A Wednesday 17 March 2010 22:56:20 Charles R Harris escrigué:
> On Wed, Mar 17, 2010 at 8:42 AM, Alan G Isaac wrote:
> > On 3/17/2010 10:16 AM, josef.p...@gmail.com wrote:
> > > numpy.resize(a, new_shape)
> > > Return a new array with the specified shape.
> > >
> > > If the new array is larger tha
33 matches
Mail list logo
