Hello all,
I have netcdf files that contain hourly rainfall data. Each netcdf file
includes one months worth of hours and I have 10 years worth of data. I
would like to calculate the sum of each month and then the mean of these
summed months across all of the years.
I have no problem firstly
Sounds (marginally) useful; although elementary row/column operations are
in practice usually better implemented directly by indexing rather than in
an operator form. Though I can see a use for the latter.
My suggestion: its not a common enough operation to deserve a 4 letter
acronym (assuming
Hi,
Le 22/03/2014 19:13, Nathaniel Smith a écrit :
After 88 emails we don't have a conclusion in the other thread (see
[1] for background). But we have to come to some conclusion or another
if we want @ to exist :-). So I'll summarize where the discussion
stands and let's see if we can find
I'm wondering if `sort` intentially does not accept a `key`
or if this is just a missing feature? (I suppose that if
the `order` argument is specified it would have to accept
a sequence of keys ...)
Thanks,
Alan Isaac
___
NumPy-Discussion mailing list
On Mon, Mar 24, 2014 at 11:32 AM, Alan G Isaac alan.is...@gmail.com wrote:
I'm wondering if `sort` intentionally does not accept a `key`
or if this is just a missing feature?
It would be very inefficient to call a key function on every element
compared during the sort. See np.argsort and
On Mon, Mar 24, 2014 at 11:32 AM, Alan G Isaac wrote:
I'm wondering if `sort` intentionally does not accept
a `key`
or if this is just a missing feature?
On 3/24/2014 11:47 AM, Alexander Belopolsky wrote:
It would be very inefficient to call a key function on
every element
On Mon, Mar 24, 2014 at 12:08 PM, Alan G Isaac alan.is...@gmail.com wrote:
On Mon, Mar 24, 2014 at 11:32 AM, Alan G Isaac wrote:
I'm wondering if `sort` intentionally does not accept
a `key`
or if this is just a missing feature?
On 3/24/2014 11:47 AM, Alexander Belopolsky wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Eelco Hoogendoorn:
Sounds (marginally) useful; although elementary row/column
operations are in practice usually better implemented directly by
indexing rather than in an operator form. Though I can see a use
for the latter.
My suggestion:
On Mon, Mar 24, 2014 at 12:08 PM, Alan G Isaac
what is the preferred idiom for a descending sort?
On 3/24/2014 12:13 PM, josef.p...@gmail.com wrote:
adding [::-1] just creates a new view, pretty low cost.
I meant when you need to sort on a key (another vector).
Currently I'm just reversing
On Mon, Mar 24, 2014 at 11:05 AM, Alan G Isaac alan.is...@gmail.com wrote:
On Mon, Mar 24, 2014 at 12:08 PM, Alan G Isaac
what is the preferred idiom for a descending sort?
On 3/24/2014 12:13 PM, josef.p...@gmail.com wrote:
adding [::-1] just creates a new view, pretty low cost.
I
On 3/24/2014 1:41 PM, Charles R Harris wrote:
For float types you would need to use the negative.
Yes, that's all I could come up with.
So ... shd `sort` have a `reverse` option,
like Python's builtin?
Alan
___
NumPy-Discussion mailing list
On Mon, Mar 24, 2014 at 11:57 AM, Alan G Isaac alan.is...@gmail.com wrote:
On 3/24/2014 1:41 PM, Charles R Harris wrote:
For float types you would need to use the negative.
Yes, that's all I could come up with.
So ... shd `sort` have a `reverse` option,
like Python's builtin?
Well, it
Le 22/03/2014 19:13, Nathaniel Smith a écrit :
Hi all,
After 88 emails we don't have a conclusion in the other thread (see
[1] for background). But we have to come to some conclusion or another
if we want @ to exist :-). So I'll summarize where the discussion
stands and let's see if we can
Hi All,
The suggestion has been made the we drop Python 3.2 support in numpy 1.9
and scipy 0.15. The advantage, from my point of view, to supporting Python
= 3.3 is that the u'unicode' syntax is supported in 3.3 and this makes it
easier to maintain compatibility with Python 2.6 and 2.7. However,
Hi all,
Just a short update, now that the deadline for submitting GSoC proposals
has passed. We received four proposals:
1. Leo Mao, Numpy: Vector Math Library Integration
2. Janani Padmanbhan, SciPy/NumPy- enhancements in scipy.special (hyp2f1,
sph_harm)
3. Ankit Agrawal, SciPy : Discrete
On 25.03.2014 00:28, Charles R Harris wrote:
Hi All,
The suggestion has been made the we drop Python 3.2 support in numpy 1.9
and scipy 0.15. The advantage, from my point of view, to supporting
Python = 3.3 is that the u'unicode' syntax is supported in 3.3 and this
makes it easier to
On Tue, Mar 25, 2014 at 12:37 AM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
On 25.03.2014 00:28, Charles R Harris wrote:
Hi All,
The suggestion has been made the we drop Python 3.2 support in numpy 1.9
and scipy 0.15. The advantage, from my point of view, to supporting
Python
On Sat, Mar 22, 2014 at 6:13 PM, Nathaniel Smith n...@pobox.com wrote:
After 88 emails we don't have a conclusion in the other thread (see
[1] for background). But we have to come to some conclusion or another
if we want @ to exist :-). So I'll summarize where the discussion
stands and let's
On Mon, Mar 24, 2014 at 5:56 PM, Nathaniel Smith n...@pobox.com wrote:
On Sat, Mar 22, 2014 at 6:13 PM, Nathaniel Smith n...@pobox.com wrote:
After 88 emails we don't have a conclusion in the other thread (see
[1] for background). But we have to come to some conclusion or another
if we
On Mon, Mar 24, 2014 at 5:34 PM, Ralf Gommers ralf.gomm...@gmail.comwrote:
Hi all,
Just a short update, now that the deadline for submitting GSoC proposals
has passed. We received four proposals:
1. Leo Mao, Numpy: Vector Math Library Integration
2. Janani Padmanbhan, SciPy/NumPy-
On Mon, Mar 24, 2014 at 11:58 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Mon, Mar 24, 2014 at 5:56 PM, Nathaniel Smith n...@pobox.com wrote:
On Sat, Mar 22, 2014 at 6:13 PM, Nathaniel Smith n...@pobox.com wrote:
After 88 emails we don't have a conclusion in the other thread (see
21 matches
Mail list logo
