On Mon, Mar 24, 2014 at 11:58 PM, Charles R Harris
wrote:
> On Mon, Mar 24, 2014 at 5:56 PM, Nathaniel Smith wrote:
>>
>> On Sat, Mar 22, 2014 at 6:13 PM, Nathaniel Smith wrote:
>> > After 88 emails we don't have a conclusion in the other thread (see
>> > [1] for background). But we have to come
On Mon, Mar 24, 2014 at 5:34 PM, Ralf Gommers wrote:
> 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
On Mon, Mar 24, 2014 at 5:56 PM, Nathaniel Smith wrote:
> On Sat, Mar 22, 2014 at 6:13 PM, Nathaniel Smith 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
On Sat, Mar 22, 2014 at 6:13 PM, Nathaniel Smith 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 see if we ca
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 supportin
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
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
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,
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
On Mon, Mar 24, 2014 at 11:57 AM, Alan G Isaac 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 would double
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
NumPy-Di
On Mon, Mar 24, 2014 at 11:05 AM, Alan G Isaac 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 meant when
> 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 revers
-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 sugges
On Mon, Mar 24, 2014 at 12:08 PM, Alan G Isaac 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:
>> It
> 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 elem
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?
>
It would be very inefficient to call a key function on every element
compared during the sort. See np.argsort and np.lexsort for faste
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
Nu
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 fin
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 tho
20 matches
Mail list logo