On So, 2015-04-05 at 14:13 +0200, Sebastian Berg wrote:
> On So, 2015-04-05 at 00:45 -0700, Jaime Fernández del Río wrote:
> > On Fri, Apr 3, 2015 at 10:59 AM, Jaime Fernández del Río
>
> >
> >
> > A PR it is, #5749 to be precise. I think it has all the bells and
> > whistles: integers, boolean
On So, 2015-04-05 at 00:45 -0700, Jaime Fernández del Río wrote:
> On Fri, Apr 3, 2015 at 10:59 AM, Jaime Fernández del Río
>
>
> A PR it is, #5749 to be precise. I think it has all the bells and
> whistles: integers, boolean and integer 1-D arrays, slices, ellipsis,
> and even newaxis, both fo
On Sat, Apr 4, 2015 at 10:38 PM, Nathaniel Smith wrote:
>
> On Apr 4, 2015 4:12 AM, "Todd" wrote:
> >
> >
> > On Apr 4, 2015 10:54 AM, "Nathaniel Smith" wrote:
> > >
> > > Core python broke backcompat on a regular basis throughout the python
> > > 2 series, and almost certainly will again -- the
On Fri, Apr 3, 2015 at 10:59 AM, Jaime Fernández del Río <
jaime.f...@gmail.com> wrote:
> I have an all-Pyhton implementation of an OrthogonalIndexer class, loosely
> based on Stephan's code plus some axis remapping, that provides all the
> needed functionality for getting and setting with orthogo
On Apr 4, 2015 4:12 AM, "Todd" wrote:
>
>
> On Apr 4, 2015 10:54 AM, "Nathaniel Smith" wrote:
> >
> > Core python broke backcompat on a regular basis throughout the python
> > 2 series, and almost certainly will again -- the bar to doing so is
> > *very* high, and they use elaborate mechanisms to
On Sat, Apr 4, 2015 at 11:38 AM, Nathaniel Smith wrote:
> On Sat, Apr 4, 2015 at 2:15 AM, Robert Kern wrote:
> > On Sat, Apr 4, 2015 at 9:54 AM, Nathaniel Smith wrote:
> >>
> >> On Sat, Apr 4, 2015 at 12:17 AM, Ralf Gommers
> >> wrote:
> >> >
> >> > On Sat, Apr 4, 2015 at 1:54 AM, Nathaniel Sm
On Sat, Apr 4, 2015 at 1:11 PM, Todd wrote:
> There was no break as large as this. In fact I would say this is even a
> larger change than any individual change we saw in the python 2 to 3
> switch.
>
Well, the impact of what Python3 did to everyone's string handling code
caused so much work tha
On Apr 4, 2015 10:54 AM, "Nathaniel Smith" wrote:
>
> On Sat, Apr 4, 2015 at 12:17 AM, Ralf Gommers
wrote:
> >
> >
> > On Sat, Apr 4, 2015 at 1:54 AM, Nathaniel Smith wrote:
> >>
> >>
> >> But, the real problem here is that we have two different array duck
> >> types that force everyone to write
On Sat, Apr 4, 2015 at 2:15 AM, Robert Kern wrote:
> On Sat, Apr 4, 2015 at 9:54 AM, Nathaniel Smith wrote:
>>
>> On Sat, Apr 4, 2015 at 12:17 AM, Ralf Gommers
>> wrote:
>> >
>> > On Sat, Apr 4, 2015 at 1:54 AM, Nathaniel Smith wrote:
>
>> >> So I'd be very happy to see worked out proposals for
On Sat, Apr 4, 2015 at 9:54 AM, Nathaniel Smith wrote:
>
> On Sat, Apr 4, 2015 at 12:17 AM, Ralf Gommers
wrote:
> >
> > On Sat, Apr 4, 2015 at 1:54 AM, Nathaniel Smith wrote:
> >> So I'd be very happy to see worked out proposals for any or
> >> all of these approaches. It strikes me as really p
On Sat, Apr 4, 2015 at 12:17 AM, Ralf Gommers wrote:
>
>
> On Sat, Apr 4, 2015 at 1:54 AM, Nathaniel Smith wrote:
>>
>>
>> But, the real problem here is that we have two different array duck
>> types that force everyone to write their code twice. This is a
>> terrible state of affairs! (And exact
On Sat, Apr 4, 2015 at 1:54 AM, Nathaniel Smith wrote:
>
> But, the real problem here is that we have two different array duck
> types that force everyone to write their code twice. This is a
> terrible state of affairs! (And exactly analogous to the problems
> caused by np.ndarray disagreeing wi
On Fri, Apr 3, 2015 at 4:54 PM, Nathaniel Smith wrote:
> Unfortunately, AFAICT this means our only options here are to have
> some kind of backcompat break in numpy, some kind of backcompat break
> in pandas, or to do nothing and continue indefinitely with the status
> quo where the same indexing
On Apr 1, 2015 2:17 AM, "R Hattersley" wrote:
>
> There are two different interpretations in common use of how to handle
> multi-valued (array/sequence) indexes. The numpy style is to consider all
> multi-valued indices together which allows arbitrary points to be extracted.
> The orthogonal st
On 2015/04/03 7:59 AM, Jaime Fernández del Río wrote:
> I have an all-Pyhton implementation of an OrthogonalIndexer class,
> loosely based on Stephan's code plus some axis remapping, that provides
> all the needed functionality for getting and setting with orthogonal
> indices.
Excellent!
>
> Wou
On Fri, Apr 3, 2015 at 10:59 AM, Jaime Fernández del Río <
jaime.f...@gmail.com> wrote:
> I have an all-Pyhton implementation of an OrthogonalIndexer class, loosely
> based on Stephan's code plus some axis remapping, that provides all the
> needed functionality for getting and setting with orthogo
I have an all-Pyhton implementation of an OrthogonalIndexer class, loosely
based on Stephan's code plus some axis remapping, that provides all the
needed functionality for getting and setting with orthogonal indices.
Would those interested rather see it as a gist to play around with, or as a
PR ad
03.04.2015, 04:09, josef.p...@gmail.com kirjoitti:
[clip]
> I think numpy indexing is not too difficult and follows a consistent
> pattern, and I completely avoid mixing slices and index arrays with
> ndim > 2.
>
> I think it should be DOA, except as a discussion topic for numpy 3000.
If you chan
On Thu, Apr 2, 2015 at 11:30 PM, Nathaniel Smith wrote:
> On Thu, Apr 2, 2015 at 6:35 PM, wrote:
>> (I thought about this because I was looking at accessing off-diagonal
>> elements, m2[np.arange(4), np.arange(4) + 1] )
>
> Psst: np.diagonal(m2, offset=1)
It was just an example (banded or toep
On Thu, Apr 2, 2015 at 6:35 PM, wrote:
> (I thought about this because I was looking at accessing off-diagonal
> elements, m2[np.arange(4), np.arange(4) + 1] )
Psst: np.diagonal(m2, offset=1)
--
Nathaniel J. Smith -- http://vorpus.org
___
NumPy-Discu
Hi,
On Thu, Apr 2, 2015 at 8:20 PM, Jaime Fernández del Río
wrote:
> On Thu, Apr 2, 2015 at 7:30 PM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> On Thu, Apr 2, 2015 at 6:09 PM, wrote:
>> > On Thu, Apr 2, 2015 at 8:02 PM, Eric Firing wrote:
>> >> On 2015/04/02 1:14 PM, Hanno Klemm wrote:
>> >>> Wel
On Thu, Apr 2, 2015 at 7:30 PM, Matthew Brett
wrote:
> Hi,
>
> On Thu, Apr 2, 2015 at 6:09 PM, wrote:
> > On Thu, Apr 2, 2015 at 8:02 PM, Eric Firing wrote:
> >> On 2015/04/02 1:14 PM, Hanno Klemm wrote:
> >>> Well, I have written quite a bit of code that relies on fancy
> >>> indexing, and I
On Thu, Apr 2, 2015 at 10:30 PM, Matthew Brett wrote:
> Hi,
>
> On Thu, Apr 2, 2015 at 6:09 PM, wrote:
>> On Thu, Apr 2, 2015 at 8:02 PM, Eric Firing wrote:
>>> On 2015/04/02 1:14 PM, Hanno Klemm wrote:
Well, I have written quite a bit of code that relies on fancy
indexing, and I thin
Hi,
On Thu, Apr 2, 2015 at 6:09 PM, wrote:
> On Thu, Apr 2, 2015 at 8:02 PM, Eric Firing wrote:
>> On 2015/04/02 1:14 PM, Hanno Klemm wrote:
>>> Well, I have written quite a bit of code that relies on fancy
>>> indexing, and I think the question, if the behaviour of the []
>>> operator should b
On Thu, Apr 2, 2015 at 9:09 PM, wrote:
> On Thu, Apr 2, 2015 at 8:02 PM, Eric Firing wrote:
>> On 2015/04/02 1:14 PM, Hanno Klemm wrote:
>>> Well, I have written quite a bit of code that relies on fancy
>>> indexing, and I think the question, if the behaviour of the []
>>> operator should be cha
On Thu, Apr 2, 2015 at 8:02 PM, Eric Firing wrote:
> On 2015/04/02 1:14 PM, Hanno Klemm wrote:
>> Well, I have written quite a bit of code that relies on fancy
>> indexing, and I think the question, if the behaviour of the []
>> operator should be changed has sailed with numpy now at version 1.9.
On 2015/04/02 1:14 PM, Hanno Klemm wrote:
> Well, I have written quite a bit of code that relies on fancy
> indexing, and I think the question, if the behaviour of the []
> operator should be changed has sailed with numpy now at version 1.9.
> Given the amount packages that rely on numpy, changing
> On 03 Apr 2015, at 00:04, Colin J. Williams wrote:
>
>
>
> On 02-Apr-15 4:35 PM, Eric Firing wrote:
>> On 2015/04/02 10:22 AM, josef.p...@gmail.com wrote:
>>> Swapping the axis when slices are mixed with fancy indexing was a
>>> design mistake, IMO. But not fancy indexing itself.
>> I'm not
On 02-Apr-15 4:35 PM, Eric Firing wrote:
> On 2015/04/02 10:22 AM, josef.p...@gmail.com wrote:
>> Swapping the axis when slices are mixed with fancy indexing was a
>> design mistake, IMO. But not fancy indexing itself.
> I'm not saying there should be no fancy indexing capability; I am saying
> t
On 2015/04/02 10:22 AM, josef.p...@gmail.com wrote:
> Swapping the axis when slices are mixed with fancy indexing was a
> design mistake, IMO. But not fancy indexing itself.
I'm not saying there should be no fancy indexing capability; I am saying
that it should be available through a function or
On Thu, Apr 2, 2015 at 2:03 PM, Eric Firing wrote:
> On 2015/04/02 4:15 AM, Jaime Fernández del Río wrote:
>> We probably need more traction on the "should this be done?" discussion
>> than on the "can this be done?" one, the need for a reordering of the
>> axes swings me slightly in favor, but I
The distinction that boolean indexing has over the other 2 methods of
indexing is that it can guarantee that it references a position at most
once. Slicing and scalar indexes are also this way, hence why these methods
allow for in-place assignments. I don't see boolean indexing as an
extension of o
On Thu, Apr 2, 2015 at 11:03 AM, Eric Firing wrote:
> Fancy indexing is a horrible design mistake--a case of cleverness run
> amok. As you can read in the Numpy documentation, it is hard to
> explain, hard to understand, hard to remember.
Well put!
I also failed to correct predict your exampl
On 2015/04/02 4:15 AM, Jaime Fernández del Río wrote:
> We probably need more traction on the "should this be done?" discussion
> than on the "can this be done?" one, the need for a reordering of the
> axes swings me slightly in favor, but I mostly don't see it yet.
As a long-time user of numpy, a
On Thu, Apr 2, 2015 at 1:29 AM, Stephan Hoyer wrote:
> On Wed, Apr 1, 2015 at 7:06 AM, Jaime Fernández del Río <
> jaime.f...@gmail.com> wrote:
>
>> Is there any other package implementing non-orthogonal indexing aside
>> from numpy?
>>
>
> I think we can safely say that NumPy's implementation of
On Do, 2015-04-02 at 01:29 -0700, Stephan Hoyer wrote:
> On Wed, Apr 1, 2015 at 7:06 AM, Jaime Fernández del Río
> wrote:
> Is there any other package implementing non-orthogonal
> indexing aside from numpy?
>
>
> I think we can safely say that NumPy's implementation of broadcast
On Wed, Apr 1, 2015 at 7:06 AM, Jaime Fernández del Río <
jaime.f...@gmail.com> wrote:
> Is there any other package implementing non-orthogonal indexing aside from
> numpy?
>
I think we can safely say that NumPy's implementation of broadcasting
indexing is unique :).
The issue is that many other
On Wed, Apr 1, 2015 at 2:17 AM, R Hattersley wrote:
> There are two different interpretations in common use of how to handle
> multi-valued (array/sequence) indexes. The numpy style is to consider all
> multi-valued indices together which allows arbitrary points to be
> extracted. The orthogonal
There are two different interpretations in common use of how to handle
multi-valued (array/sequence) indexes. The numpy style is to consider all
multi-valued indices together which allows arbitrary points to be
extracted. The orthogonal style (e.g. as provided by netcdf4-python) is to
consider each
39 matches
Mail list logo
